Hi kbruns,
das würde bedeuten, dass der recovery-loader nur die erste Kennung auswertet, welche sonst aber auch irgendwie die Blöcke trennt, oder dass die dann eben nicht gelesen werden und alt bleiben? Da im ersten Block bei orig. FW das BIOS und der recovery-loader ist (der dann die Wunsch Kennung verträgt), müßte beim zweiten tftp Durchgang mit unmod. FW alles sauber sein.
Ich hab da mal folgendes zusammengestellt:
Code:
diverse:
000000-00403F BIOS ???
004040-00785F ??? (7504_recovery)
007860- wie upgrade.img
upgrade.img
Y - Y+4Fh "MGB100..."
Y+50h - X-1h Kernel
X - X+4Fh "MGB100..."
X+50h - END fs.img (gzip)
Pearl:
000000- "Queen..."
??? (34c4_recovery = 7504-BIOS)
003820- "Queen..."
- 25FD5E ???
Y - Y+4Fh "Queen..."
Y+50h - X-1h Kernel
X - ? "Queen..." (X=357EC7)
? - END ???
FW-Name Händler int. Kennung
CHD2WLANU Conceptronic LLM_RUS001
PE6643 Pearl Queen
MGB100 Micronica, Pearl
WAP-0007 LevelOne DDC_RUS001
WAPS-G SMC SMC_RUS001
WMU-6 OvisLink (AirLive) OVS_RUS001
FMW SafeCom SWSAPUR-5 Safeco_RPS001
bedeutet: die FW setzen sich aus Blöcken zusammen die nicht alle vorhanden sein müssen. BIOS und Recovery, sowie original Kernel und Filesystem haben kändlerspez. Kennung. Kernel und Filesystem (kann kompr. sein) müssen scheinbar zusammen sein und werden von allen Loadern akzeptiert.
Ob bei K+FS die Trennung über die Kennung geht oder über eine Längenangabe im Header ??? schließlich wird scheinbar MGB100 und Queen akzeptiert.
Ein Ändern nur der ersten Kennung reicht nicht für ein Flash über GUI. Ev. ist auch eine Checksum beteiligt...
schufti
P.S.: Ich wollte nicht den Inhalt des mtd (cat /dev/mtd) sondern die Partitionierung (cat /proc/mtd) Danke!