Fritzbox 7590 - Bootloader defekt nach Flashversuch?

[mik0r]

Hallo,

ich habe versucht, ein Freetz-Image (trunk) mittels des Freetz beiliegenden recover-eva Skripts zu flashen.

Das hat leider nicht funktioniert, schon bei der Ausführung gab es viele Fehlermeldungen weil die GETENV Kommandos wohl grösstenteils keine Werte lieferten:

perl recover-eva -f 7590_06.92-freetz-devel-14604M.de.image
Looking for Fritz!Box ooooooooooooooooooooO. found!
ADAM2 version 0.18.1 at 192.168.178.1 (192.168.178.1)
Use of uninitialized value in split at recover-eva line 254.
Use of uninitialized value in split at recover-eva line 254.
Use of uninitialized value in split at recover-eva line 255.
Use of uninitialized value in split at recover-eva line 256.
Use of uninitialized value in split at recover-eva line 257.
Use of uninitialized value $mtd0[1] in hex at recover-eva line 258.
Use of uninitialized value $mtd0[0] in hex at recover-eva line 258.
Use of uninitialized value $mtd1[1] in hex at recover-eva line 259.
Use of uninitialized value $mtd1[0] in hex at recover-eva line 259.
Use of uninitialized value $mtd2[1] in hex at recover-eva line 260.
Use of uninitialized value $mtd2[0] in hex at recover-eva line 260.
Use of uninitialized value $mtd3[1] in hex at recover-eva line 261.
Use of uninitialized value $mtd3[0] in hex at recover-eva line 261.
Use of uninitialized value $mtd4[1] in hex at recover-eva line 262.
Use of uninitialized value $mtd4[0] in hex at recover-eva line 262.
Use of uninitialized value $pid in concatenation (.) or string at recover-eva line 264.
Product ID:
Use of uninitialized value $hwrev in concatenation (.) or string at recover-eva line 265.
Hardware Revision:
Use of uninitialized value $ulrev in concatenation (.) or string at recover-eva line 266.
Urlader  Revision:
Use of uninitialized value $fwrev in concatenation (.) or string at recover-eva line 267.
Firmware Revision:
MTD0: 0 bytes
MTD1: 0 bytes
MTD2: 0 bytes
MTD3: 0 bytes
MTD4: 0 bytes
./var/tmp/kernel.image
./var/tmp/filesystem.image
recover.tmp/var/tmp/filesystem.image: removed checksum
Negative repeat count does nothing at recover-eva line 398.
CRC32: B8697CE6
Flashing recover.tmp/var/tmp/filesystem.image to mtd0 ...########################################################################################################################################################################################################################################################################################################################################################################################################################################################################
FAILED: 426 Data connection closed

recover.tmp/var/tmp/kernel.image: removed checksum
Negative repeat count does nothing at recover-eva line 398.
CRC32: 6E97EBAE
Flashing recover.tmp/var/tmp/kernel.image to mtd1 ...FAILED: 425 can't open data connection

Der Kardinalfehler war wohl, im Anschluss die Fritzbox neu zu starten. Nun leuchtet nur noch die Power-LED dauerhaft, eine Netzwerk-Verbindung kommt nicht mehr zustande (also auch kein Zugriff auf den Bootloader mehr).

Ich verstehe nicht, wie der Bootloader hier in Mitleidenschaft gezogen werden konnte - meines Wissens liegt dieser in einem separaten Flashbereich, der bei der obigen Aktion gar nicht angefasst hätte werden sollen.

Gibt es noch Hoffnung für diese Fritzbox? Hat jemand eine Idee was hier passiert ist?

Würde mich über Infos sehr freuen!

 

[Shirocco88]

perl recover-eva -f 7590_06.92-freetz-devel-14604M.de.image

Bist Du sicher, dass "recover-eva" auch für NAND-Boxen wie FB7490, FB7590 geeignet ist;
das Tool wurde IMHO doch für NOR-Boxen wie FB7170, FB7270, FB7390 entwickelt.

Nach welcher Anleitung für die FB7590 bist Du vorgegangen ?
gerne Link beifügen, so dass dies nachvollziehbar wird.

Flashing recover.tmp/var/tmp/filesystem.image to mtd0

ggf. wurde das "falsche" mtd-Device befüttert.

ich würde da "eva_to_memory" nehmen;
eva_to_memory 7590_06.92-freetz-devel-14604M.de.image.in-memory <fb_bootloader_ip>
Beispiel für FB7580:

peh@yourfritz:/tmp/yourfritz/yf/eva_tools$ eval $(sudo ./eva_discover INTERFACE=eth0 FROM=192.168.178.254 TO=192.168.178.1 BLIP=1 HOLD=0); echo "EVA_FOUND=$EVA_FOUND"; echo "EVA_IP=$EVA_IP"; [ "$EVA_FOUND" = "1" ] && ./eva_to_memory myimage.bin
EVA_FOUND=1
EVA_IP=192.168.178.1
Found AVM bootloader: AVM EVA Version 1.3229 0x0 0x46409
Found hardware revision: 225
Memory size is 0x08000000 (128 MB)
Memory size limited to 128 MB
Image size is 0x179d100 (23 MB)
Setting temporary memory size to: 0x06862f00
Setting temporary kernel args to: mtdram1=0x86862f00,0x88000000
Image uploaded to device.
peh@yourfritz:/tmp/yourfritz/yf/eva_tools$

Hinweis: damit man mit Freetz ein In-Memory-Image erhält, sollte man die entsprechende Option mittels "make menuconfig" setzen.
Kontrolle:

grep FREETZ_FWMOD_CREATE_IN_MEMORY_IMAGE .config

 

[stoney]

Hoffnung?
Wenn wirklich das Environment "defekt" sein sollte, könnten Dir erweiterte Supportdaten i.V.m. PeterPawn's YF/tffs/ die Box retten.

Vorher wäre ein Auslesen des Environments, um dieses sichten zu können, ob darin wirklich etwas nicht stimmt, kannst Du Dich wiederrum bei YF/eva_tools/ bedienen.

Ich bin leider im Thema Freetz mitten drin, allerdings solltest Du die belastbaren files hier einstellen.

Wie man dem HTD im Subforum Freetz (unterhalb von F!B Modifikationen) entnehmen kann, sollte #4 unbedingt beachtet werden

Freetz für Newbies, Was man wissen muß oder wissen sollte über Freetz

#4

 

[zoppa]

Hallo,

bei mir sieht es identisch aus. Habe auch versucht Freetz zu flashen.
Über die Serielle kommt nur noch:
no valid image found.
Offensichtlich ist der Bootloader zerstört.
Ich habe schon intensiv nach dem Thema EJTAG und Bootloader gesucht, aber leider nichts gefunden. Kann mir jemand Starthilfe geben?

 

[PeterPawn]

Das dürfte Neuland sein hier im IPPF, daß jemand über die JTAG-Schnittstelle auf den Bootloader einer GRX-Box will ... wobei ja irgendwo schon die Tatsache, daß da auf der Seriellen überhaupt noch etwas kommt, dagegen spricht, daß der Bootloader tatsächlich komplett überschrieben wurde.

Vielleicht packst Du ja doch mal das komplette Protokoll der Session dazu und läßt uns auch noch wissen, wie es überhaupt dazu kam ... sofern nicht tatsächlich nur diese eine Zeile in einer aktuellen Session auf der Console enthalten ist (auch dann wäre es schon noch wichtig zu wissen, wie Du das mit dem vermutlich zerstörten Bootloader geschafft hast).

Wobei so eine "fest verdrahtete Zeichenkette" mit dem Text "no valid image found" in irgendeinem ROM-Loader auch einigermaßen komisch wäre ... da benutzt man i.d.R. nur irgendwelche kryptischen Error-Codes, solange da wirklich nur "bare metal" aktiv ist.

Bei wirklich zerstörtem Bootloader kann ich Dir auch nicht mehr helfen ... wenn es aber tatsächlich nur "no valid image" sein sollte, weil in den Kernel-Partitionen und/oder in der UBIFS-Partition keine gültigen Daten stehen, dann wäre es vielleicht etwas anderes. Wobei mein Bootloader (auch wenn der von der 7580 ist) die gezeigte Zeichenkette gar nicht enthält ... eine weitere Merkwürdigkeit, weil m.W. die Loader fast identisch waren bei den GRX-Boxen.

Aber auch dann, wenn man da vielleicht noch etwas machen könnte, solltest Du Dich zunächst mal damit vertraut machen, wie die Installation des FRITZ!OS über den Bootloader einer 7590 wirklich läuft (und die für Freetz ist da nicht anders) - danach sehen wir dann weiter.

 

[PeterPawn]

Ich habe mal eine korrigierte/abgewandelte Version von "recover-eva" als Pull-Request für Freetz bereitgestellt: https://github.com/Freetz/freetz/pull/29

Mit dieser Version kann man sich bei einer HWRevision ab 185 (das ist die 7490) die Box auch nicht mehr unabsichtlich bricken (weil sie schlicht bei jedem Wert >= 185 die Mitarbeit verweigert) - außerdem funktioniert jetzt das Auslesen von Environment-Variablen wieder halbwegs in diesem Skript auch mit Perl 5 und Net::FTP/Net::Cmd in Version 3.05. Die Implementierung ist nicht wirklich schön (dazu hätte man den Fehler in der Interpretation der Server-Antworten suchen müssen, anstatt die Antworten einfach auf anderem Weg auszuwerten), aber sie funktioniert zumindest für die "üblichen" Antworten "200" und "501" (wenn der Name nicht vorhanden ist oder die Variable nicht gesetzt ist).

 

[NDiIPP]

Wie verhält sich das geänderte Script eigentlich wenn als HWRevision Werte wie beispielsweise F (Fritzbox SL), G (die erste Fritzbox), 94.1.0.0 (7170v1), 94.1.1.0 (7170v2) oder 102.1.1.0 (W900v) ausgegeben werden?

Ansonsten hier mal eine kleine Aufschlüsselung mit welchen HWRevisions Werten das Skript die Arbeit vermutlich aufnehmen dürfte und mit welchen besser nicht:

• bis 156 oder bis 156.* > TRUE
• = 157 oder = 157.* > FALSE (6360, NOR aber DualBoot, bin mir hier nicht sicher)
• von 158 bis 174 oder von 158.* bis 174.* > TRUE
• von 175 bis 177 oder von 175.* bis 177.* > FALSE (3370 mit NAND, 6320v1 Cable mit NOR aber DualBoot und 6840 lte mit NAND)
• von 178 bis 181 oder von 178.* bis 181.* > TRUE
• = 182 oder = 182.* > FALSE (6320v2, NOR aber DualBoot, bin mir hier nicht sicher)
• von 183 bis 184 oder von 183.* bis 184.* > TRUE
• von 185 bis 187 oder von 185.* bis 187.* > FALSE (7490 mit NAND und 6340 Cable)
• von 188 bis 190 oder von 188.* bis 190.* > TRUE (7330 SL und 7312 mit NOR)
• von 191 bis 195 oder von 191.* bis 195.* > FALSE
• = 196 oder = 196.* > TRUE (7360v2 mit NOR)
• von 197 bis 218 oder von 197.* bis 218.* > FALSE
• = 219 oder = 219.* > TRUE (4020)
• von 220 bis 226 oder von 220.* bis 226.* > FALSE
• = 227 oder = 227.* > TRUE (4040)
• ab 228 oder ab 228.* > FALSE

Diese Aufschlüsselung gilt aber auch nur unter der Voraussetzung die Ursache des Problem liegt überhaupt im Unterschied ob es sich um ein DualBoot Modell handelt oder nicht. Andererseits ist das Script für die DualBoot Modelle wohl sowieso nicht geeignet und daher sollte das Script beim Erkennen einer solchen Box die Arbeit verweigern.

 

[PeterPawn]

Mir ging es eher darum, die durch falsche Verwendung des Skripts zerstörten Boxen zu vermeiden ... wenn das am Ende in "overblocking" mündet, weil es auch jenseits der 185 noch Modelle gibt, wo die Installation über den Bootloader (genauer über MTD0 + MTD1, also nicht mit einem "hidden root-filesystem") erfolgen könnte, ist das in meinen Augen allemal besser, als ein zerstörter Bootloader (siehe auch der Commit-Text im Branch):

Maybe, there are other models with a HWRevision above 185 using NOR or SPI flash again ... but it's better to protect users of the "mainstream devices" from their lack of knowledge and hit some "innocent victims" too much.

Ich habe sogar auf jeden Test der nachfolgenden Funktion im Skript (beim Flashen) komplett verzichtet (deshalb schrieb ich auch nicht, daß/ob das Skript jetzt tatsächlich wieder in voller Schönheit funktioniert - sondern von einem "quick hack" und daß das Auslesen mit GETENV wieder klappt), weil ich dazu erst mal eine passende Box suchen müßte ... entscheidend für mich war es, das Auslesen der Environment-Variablen wieder funktionstüchtig zu bekommen (damit man überhaupt "HWRevision" auswerten kann, denn (siehe #1 mit dem Protokoll eines solchen Versuchs) vorher gab es ja gar keine Werte mehr von "$ftp->getenv()") und die Zeile 281 einzubauen, damit jenseits der 185 garantiert nichts mehr geht.

Wenn davon auch irgendwelche uralten Modelle betroffen sein sollten und die tatsächlich noch irgendeine Relevanz haben sollten, dann muß man den Prozess des Parsens für diesen Wert eben entsprechend ausbauen ... was da alles (theoretisch) auftauchen könnte, kann man in der "rc.conf" bei AVM nachlesen. So rein aus der Ansicht würde ich sagen, daß erst mal gar nichts passiert ... ob die Warnung beim Versuch, eine nicht-numerische HWRevision mit 185 zu vergleichen, am Ende zum Abbruch führt oder nicht (bei den alten Modellen ist "nicht" dann auch kein wirklicher Beinbruch), hängt u.a. auch davon ab, mit welchen Optionen Perl aufgerufen wird.

Eine etwas ausgefeiltere Erkennung, ob eine Box nun "dualboot-fähig" ist oder nicht, kann (im Bootloader) praktisch nur auf die Auswertung von "flashsize" (auch hier nie mit "Gewißheit") gestützt werden, weil auch bei einem Dual-Boot-Modell die Variable "linux_fs_start" durchaus leer/nicht gesetzt sein kann, was dann mit "0" gleichzusetzen ist. Alternative wäre eine Liste von HWRevisionen, die vom Skript tatsächlich (bekanntermaßen) korrekt behandelt werden können ... auch das ist eine tiefgreifendere Änderung als die, welche ich vornehmen wollte (wie gesagt, war nur ein "quick hack" und ich hasse im Normalfall Perl), um die Verwender dieses Skripts beim falschen Modell vor sich selbst zu schützen.

 

[NDiIPP]

Mir ging es eher darum, die durch falsche Verwendung des Skripts zerstörten Boxen zu vermeiden ... wenn das am Ende in "overblocking" mündet, weil es auch jenseits der 185 noch Modelle gibt, wo die Installation über den Bootloader (genauer über MTD0 + MTD1, also nicht mit einem "hidden root-filesystem") erfolgen könnte, ist das in meinen Augen allemal besser, als ein zerstörter Bootloader (siehe auch der Commit-Text im Branch):

Dann vielleicht schon ab 175 (3370) sperren. Die 6360 mal ignoriert.

edit
Dass das von dir nur ein "quick hack" ist war mir bewusst deshalb wollte ich mir das auch nicht von dir wünschen. Aber falls ein anderer, der ursprüngliche Author oder er13 eine genauere Überprüfung einbauen möchte könnte er die Auflistung oben heranziehen.

 

[PeterPawn]

Wir sind gerade im GitHub (Link oben) am Diskutieren ...

 

[prisrak1]

bei meiner 7590 ist, HWRevision 226, HWSubRevision 4, ProductID tz_Box_HW226

die env habs bei der " firmware_info 154.07.19, firmware_version avm" ausgelesen.

 

[NDiIPP]

Hat mehrere modifizierte Images via in.memory und eva_tools gefressen

Und du hast die per EVA mtd0 vorgesetzt (was der TO wohl getan hatte)?