Image flashen mit Adam2

Code:
...
quote MEDIA FLSH
put mtd2.bin "mtd2[B]+[/B]"

Interessant. Sollte ich irgendwann mal wieder Zeit und Laune für die Box haben, könnte ich das mal per QEMU gefahrlos testen. Evtl. will das ja sonst noch jemand übernehmen.
 
MaxMuster wäre vielleicht einer der "üblichen Verdächtigen" dafür :) Ich hab mir auf sein Anraten auch mal QEMU installiert, habe es aber nicht starten können. Vielleicht versuch' ichs nochmal, hab jetzt eine neue Windows-Installation und mehr Speicher.

Andererseits, die Italiener haben das erfolgreich getestet, steht auch so in deren Wiki.

EDIT: inzwischen ( seit 21.03.2008 ) haben sie es wieder gelöscht

Gruß,
Telefonicus
 
Zuletzt bearbeitet:
... als "üblicher Verdächtiger" vermute ich, dass das mit qemu wohl nicht klappen wird. Die Netzwerkemulation bei einer 7170 hat bislang bei mir noch nicht geklappt, aber auch bei einer "alten" Box wage ich zu bezweifeln, dass ich den Adam/EVA-FTP-Server damit "gepackt" bekomme.
Da müsste sich wohl doch jemand erbamen, der zur Not ein EJTAG Interface hat?!?

Jörg
 
Ja, stimmt, an den FTP-Port kommt man vor dem Booten und Netzwerk-Setup nicht heran, erst danach, aber das ist dann ja nicht mehr EVA. Man kann QEMU zwar schon so starten, daß Änderungen im Flash übernommen werden, man könnte also normal von der Shell aus den Bootloader überschreiben. Aber die Simulation via EVA-FTP auf diese Weise würde nicht klappen, höchstens die serielle Konsole könnte man benutzen, aber das geht ja bisher auch. Wobei ich es ziemlich einfach finde, das von der Shell aus zu machen. Der unschöne Weg über TFFS und EVA-FTP ist also sowieso nicht notwendig.
 
Warum kann QEMU den Bootloader nicht emulieren?

Gruß,
Telefonicus
 
QEMU kann den Bootloader ausführen, sonst könnte es die Box gar nicht starten.

Das, was Alexander schreibt, klingt so, als würde aber die Netzwerk-Emulation nicht mit dem Bootloader funktionieren. Wobei ich auch mit gebooteter Box noch keine funktionierende Netzwerk-Emulation geschafft habe.
 
Ich meinte die Nebenfunktion Eva-FTP, also das Pseudo-FTP, das mit Linux noch nichts zu tun hat. Sorry dass ich mich da unklar ausgedrückt habe.
 
Ralf hat Recht. Zumindest sind meine QEMU-Kenntnisse nicht gut genug, um definitiv zu sagen, ob es irgendwie gehen könnte oder nicht. Die Netzwerk-Emulation funktioniert aber erst nach dem Booten, wenn der emulierte Adapter initialisiert wurde mit den richtigen Adressen. Das funktioniert einigermaßen mit Boxen ohne Bridge (z.B. Fritz!Box WLAN), aber definitiv nicht mit 7170 & Co., weil es für die Bridge noch keine Emulation gibt und momentan wohl auch niemand daran arbeitet(?) bei QEMU.
 
Hallo,
alle paar Wochen wurmt mich die halbkaputt gefläschte 7170 v1 mit Kernel Panic Reboot Loop, die den Beschwerdebriefen auf meinem Schreibtisch Gewicht verleiht, so sehr, dass ich sie mir mal wieder vornehme, in der Hoffnung, doch noch eine Möglichkeit zu finden, mtd2 mit Bordmitteln zu überschreiben. Was das Recovery-Programm per Eva-FTP macht, nämlich den Bootloader mit sich selbst zu überschreiben, müsste doch auch zu Fuß möglich sein. Leider hat das, was die italienischen Freunde herausgefunden haben (put -z mtd2.bin "mtd2+"), bei mir nicht geklappt, jedenfalls nicht mit NCftp. Es muss da wohl noch ein Zauberwort geben, das Eva dazu bewegt, diesen Befehl auszuführen - vielleicht sollte ich es mal mit einem Apfel versuchen :)

Kriegaex hat mir mal ein Spezialrezept gemixt, das es ermöglichen soll, eine in ASCII umcodierte Bootloader-Datei nach Start der netzlosen Linux-Shell über die serielle Konsole zu übertragen:
Code:
Erzeugen der ASCII-Datei im PC
[B]cat urlader.image | uuencode -m - > urlader.base64[/B]

Mittels der seriellen Konsole die Linux-Shell starten
[B]setenv kernel_args init=/bin/sh
go[/B]

Text in eine Variable einfügen
[B]urlader="[/B] ...Textzeilen einfügen, Folgezeilen mit[COLOR=RED] > [/COLOR]am Anfang... [B]"[/B]

Vollständigkeit prüfen
[B]echo "$urlader" | uudecode | wc -c[/B] sollte 65536 anzeigen

Den Inhalt der Variablen [I]urlader[/I] decodieren und nach /dev/mtdblock3 fläschen
[B]echo "$urlader" | uudecode > /dev/mtdblock3[/B]

Ich habe das nicht ausprobiert, weil ich die Box, um die es damals ging, auf andere Weise retten konnte. Aber mir ist eine andere Idee gekommen: Was wäre, wenn ich mit Eva-FTP den Bootloader nach, sagen wir, mtd4 schreibe (also nach /dev/mtdblock5) und ihn dann mit der netzlosen Linux-Schell nach mtd2 umkopiere?

Leider hat die Fritzbox kein man cat. Kann mir mal jemand mit der Syntax behilflich sein?

cat /dev/mtdblock5 /dev/mtdblock3 wird wohl so nicht gehen, die Blöcke sind ja unterschiedlich groß. Wie kann ich erreichen, dass nur die ersten 64kB von /dev/mtdblock5 kopiert werden? Muss ich evtl. erst Verzeichnisse auf die Blockdevices mounten und Dateien anlegen? Im obigen Beispiel wird allerdings munter nach /dev/mtdblock3 geschrieben, wenn auch nicht mit cat.

Sorry für meine Linux-Ignoranz. Kann mir bitte mal jemand helfen?

Gruß,
Telefonicus

.
 
Zuletzt bearbeitet:
Da steht doch im Kommentar deutlich, daß der cat-Befehl auf dem PC durchzuführen ist, um erst mal eine UU-kodierte Version des Urladers zu erstellen. Auf der Box brauchst Du doch nur echo und uudecode. Und wenn Du zu irgendeinem Unix-Befehl eine Manual-Seite (Manpage) anzeigen lassen möchtest, die bei Dir im Linux nicht existiert, gib doch einfach ein Google so etwas wie "man cat" ein.
 
Hallo Alexander!
Sorry, ich wollte jetzt nicht dein Rezept nachkochen (obwohl ich den Ansatz im Prinzip für genial halte, er ist aber auch aufwändig wegen der vielen Zeilen), sondern etwas ganz anderes probieren. Klar kann ich selber gugeln, aber ich wollte ja auch mal hören, ob das überhaupt gehen kann, oder ob ich erst was mounten muss. Und wenn nicht mit cat, womit evtl. sonst?

.
 
Hi,

sofern das mit /dev/mtdblock5 nach /dev/mtdblock3 gehen sollte, könntest du das mit "dd" versuchen (nur aus dem Kopf, ohne Gewähr):

Code:
dd if=/dev/mtdblock5 bs=1024 count=64 of=/dev/mtdblock3
das sollte 64 mal 1k vom if (/dev/mtdblock5) nach of (/dev/mtdblock3) kopieren...

Jörg
 
Hallo Jörg,
danke für den Tipp! ich habe vorsichtshalber erst mal versucht /dev/mtdblock5 nach /dev/mtdblock4 zu kopieren.
Code:
# dd if=/dev/mtdblock5 bs=1024 count=64 of=/dev/mtdblock4
64+0 records in
64+0 records out
Leider hat es nicht funktioniert, in mtd3, also in /dev/mtdblock4 ist immer noch der alte Inhalt. Hast du eine Idee, was ich noch probieren könnte?
 
Jetzt habe ich einfach einmal statt der mtdblocks die mtds genommen
Code:
# dd if=/dev/mtd4 bs=1024 count=64 of=/dev/mtd3
64+0 records in
64+0 records out
# exit
Call Trace:
 [<9402429c>] panic+0x34/0x198
 [<94032ae0>] do_sigaction+0x1d4/0x260
 [<94026ac0>] do_exit+0x84/0xad8
 [<94032e9c>] sys_rt_sigaction+0x78/0xd0
 [<9402754c>] do_group_exit+0x0/0x98
 [<9400d9c0>] stack_done+0x20/0x3c
 [<9400d9c0>] stack_done+0x20/0x3c

Kernel panic - not syncing: Attempted to kill init!
 <0>Rebooting in 5 seconds..
Berühmte letze Worte... danach ging gar nichts mehr. Successfully attempted to kill unit. Wohin mag dd geschrieben haben?

Morgen ist EJ-Tag.
 
Zuletzt bearbeitet:
Hat denn Niemand eine Erklärung, was passiert sein könnte (oder wenigstens ein paar Worte des Trostes und der Erbauung)?

Ein paar Auffälligkeiten bei der Partitionierung der netzlosen Shell:
Code:
Ohio flash memory: Swapping erase regions for broken CFI table.
number of CFI chips: 1
[mtd]: jffs2_size = 24 * 64KByte (0x180000 Bytes)
[ohio_find_hidden_filesystem]: super block found: bytes_used: 0x53ed35/5500213
[init_ohio_flash] find hidden filesystem size=0x6cad00 offset=0xb5300
[mtd] configure jffs2 partition
[mtd] fs_size=0x5f0000 max=0x180000 is=0x180000 max jffs2_size value 24
[mtd] ohio_flash_map: name=Ohio flash memory bankwidth=2 virt=0xb0000000 phys=0x10000000 size=0x800000
Creating 7 MTD partitions on "Ohio flash memory":
0x000b5300-0x00780000 : "filesystem"
        'nor-flash'
        'Bits can be cleared (flash)'
        'Has an erase function'
mtd: partition "filesystem" doesn't start on an erase block boundary -- force read-only
0x00010000-0x00780000 : "kernel"
        'nor-flash'
        'Bits can be cleared (flash)'
        'Has an erase function'
0x00000000-0x00010000 : "bootloader"
        'nor-flash'
        'Bits can be cleared (flash)'
        'Has an erase function'
0x00780000-0x007c0000 : "tffs (1)"
        'nor-flash'
        'Bits can be cleared (flash)'
        'Has an erase function'
0x007c0000-0x00800000 : "tffs (2)"
        'nor-flash'
        'Bits can be cleared (flash)'
        'Has an erase function'
0x00600000-0x00780000 : "jffs2"
        'nor-flash'
        'Bits can be cleared (flash)'
        'Has an erase function'
0x00010000-0x00600000 : "Kernel without jffs2"
        'nor-flash'
        'Bits can be cleared (flash)'
        'Has an erase function'
partition_info[0]: name=filesystem offset=b5300 size=6cad00
partition_info[0]: 0xb00b5300: 0x73717368 0x6ce
partition_info[1]: name=kernel offset=10000 size=770000
partition_info[1]: 0xb0010000: 0xfeed1281 0xa51fb
partition_info[2]: name=bootloader offset=0 size=10000
partition_info[2]: 0xb0000000: 0x40809000 0x40809800
partition_info[3]: name=tffs (1) offset=780000 size=40000
partition_info[3]: 0xb0780000: 0x40001 0xfeffffff
partition_info[4]: name=tffs (2) offset=7c0000 size=40000
partition_info[4]: 0xb07c0000: 0x40809000 0x40809800
partition_info[5]: name=jffs2 offset=600000 size=180000
partition_info[5]: 0xb0600000: 0x20031985 0xc
partition_info[6]: name=Kernel without jffs2 offset=10000 size=5f0000
partition_info[6]: 0xb0010000: 0xfeed1281 0xa51fb
Beim "normalen" System (das allerdings auch nicht richtig läuft), sieht es so aus:
Code:
Ohio flash memory: Swapping erase regions for broken CFI table.
number of CFI chips: 1
cfi_cmdset_0002: Disabling erase-suspend-program due to code brokenness.
[mtd]: set to default: jffs2_size = 0x20 * 64KByte (0x200000 Bytes)
ohio_flash_map.virt 0xb0000000
ohio_ram_map.virt 0x00000000
[ohio_find_hidden_filesystem] start=0x10000 end=0x780000 size=0x770000
[ohio_find_hidden_filesystem]: super block found: bytes_used: 0x3fa682/4171394
[init_ohio_flash] find hidden filesystem size=0x6cdb00 offset=0xb2500
[mtd] configure jffs2 partition
[mtd] fs_size=0x4a0000 max=0x2d0000 is=0x200000 max jffs2_size value 45
[mtd] ohio_flash_map: name=Ohio flash memory bankwidth=2 virt=0xb0000000 phys=0x10000000 size=0x800000
partition_info[0]: name=filesystem offset=b2500 size=6cdb00
partition_info[1]: name=kernel offset=10000 size=770000
partition_info[2]: name=bootloader offset=0 size=10000
partition_info[3]: name=tffs (1) offset=780000 size=40000
partition_info[4]: name=tffs (2) offset=7c0000 size=40000
partition_info[5]: name=jffs2 offset=580000 size=200000
partition_info[6]: name=Kernel without jffs2 offset=10000 size=570000
Creating 7 MTD partitions on "Ohio flash memory":
0x000b2500-0x00780000 : "filesystem"
'nor-flash'
'Bits can be cleared (flash)'
'Has an erase function'
mtd: partition "filesystem" doesn't start on an erase block boundary -- force read-only
0x00010000-0x00780000 : "kernel"
'nor-flash'
'Bits can be cleared (flash)'
'Has an erase function'
0x00000000-0x00010000 : "bootloader"
'nor-flash'
'Bits can be cleared (flash)'
'Has an erase function'
'Virtual blocks not allowed'
0x00780000-0x007c0000 : "tffs (1)"
'nor-flash'
'Bits can be cleared (flash)'
'Has an erase function'
'Virtual blocks not allowed'
0x007c0000-0x00800000 : "tffs (2)"
'nor-flash'
'Bits can be cleared (flash)'
'Has an erase function'
'Virtual blocks not allowed'
0x00580000-0x00780000 : "jffs2"
'nor-flash'
'Bits can be cleared (flash)'
'Has an erase function'
'Virtual blocks not allowed'
0x00010000-0x00580000 : "Kernel without jffs2"
'nor-flash'
'Bits can be cleared (flash)'
'Has an erase function'
'Virtual blocks not allowed'
 
Zuletzt bearbeitet:
Schaut aus als wäre der Bootloader echt tot... Kann man evtl. mit JTAG wiederbeleben und ich wollte meinen selbstgebauten JTAG-Adapter auch mal testen...

Gruss Manuel
 
Schaut aus als wäre der Bootloader echt tot...
Bootet die Box denn noch? Wenn der Bootloader tot ist, dann wird der Kernel nicht mehr geladen.
Wo ist denn der Fehler? Ich kann in deinem Log keinen entdecken.

MfG Oliver
 
Bootet die Box denn noch?
Nein, natürlich nicht, die Box ist tot. Ich möchte nur wissen, wieso ich den Bootloader überschrieben hab. Ich wollte doch nur probieren, ob ich mit dd 64kB aus mtd4 nach mtd3 schreiben kann:

Code:
# dd if=/dev/mtd4 bs=1024 count=64 of=/dev/mtd3

Was ist da passiert?

.
 
Zuletzt bearbeitet:
Wenn die Box jetzt komplett tot ist, dann wirst du wohl den Bootloader überschrieben haben. Wie das kommt kann ich dir jedoch nicht sagen, da der ja in mtd2 liegen sollte.

MfG Oliver
 
Holen Sie sich 3CX - völlig kostenlos!
Verbinden Sie Ihr Team und Ihre Kunden Telefonie Livechat Videokonferenzen

Gehostet oder selbst-verwaltet. Für bis zu 10 Nutzer dauerhaft kostenlos. Keine Kreditkartendetails erforderlich. Ohne Risiko testen.

3CX
Für diese E-Mail-Adresse besteht bereits ein 3CX-Konto. Sie werden zum Kundenportal weitergeleitet, wo Sie sich anmelden oder Ihr Passwort zurücksetzen können, falls Sie dieses vergessen haben.