Fritzbox 7490 Bootloop

[oconnor]

Hallo,

ich habe hier eine defekte Fritzbox, die angeblich nach einem Firmware Update in eine Bootschleife geraten ist. Bootschleife ist wie folgt: alle LEDS blinken einmal auf 3x blinkt Power, Power leuchtet für ca. 15 Sekunden. Power blinkt 3x, 3 Sekunden Pause, Power blinkt 2x, 3 Sekunden Pause, Power blinkt 2x, 5 Sekunden Pause und dann fängt die Bootschelife von vorne an alle LED's an ...

Folgendes habe ich probiert:
1. im adam2 änderen des linux_fs_start von 0 auf 1 und 1 auf 0 --> Bootschleife
2. mehrmaliges erfolgreiches ausführen von Fritzbox Recovery in den Versionen 7.1, 6.91, 6.85, 6.30 --> Bootschleife
3. Setzen von avm zu amve im adam2 -> Internationales Recovery --> Bootschleife
4. Mittels PeterPawn Skripten mtd3 und mtd4 geflashed nach der Anleitung --> Bootschleife

Jetzt gehen mir langsam die Ideen aus. Ich habe das Gefühl, dass das Problem nicht an einem Firmware Update lag, sondern an einem defekten Bauteil. Gibt es eine Möglichkeit ein Image (vielleicht freetz) zu erstellen, wo beispielsweise das Modem, WLAN oder die Telefonie nicht mit initialisiert werden? Wenn ja, kann mir jemand ein paar Links geben, leider sind die freetz Seiten alle down. Oder hat jemand ein entsprechendes Image? Und wie flashe ich das ganze mittels adam2?

 

[stoney]

Wie sind denn die Werte

firmware_info sowie firmware_version

im Environment.

Zuerst muss ein Recovery erfolgreich durchlaufen, vorher bringt es auch nichts sich mit freetz und dem dann nötigen flashen via Bootloader.

 

[Micha0815]

Zuerst muss ein Recovery erfolgreich durchlaufen, vorher bringt es auch nichts sich mit freetz und dem dann nötigen flashen via Bootloader

Bist Du Dir da sicher? Zeichnete nicht neulich in einem Thread hier ein defektes WLAN verantwortlich für eine Bootschleife, was durch Flashen eines entsprechenden Freetz-Images via Bootloader der FB zu einem 2ten Leben verhalf?
Laut TE ist der Bootloader wohl intakt.
LG
P.S.: Als Vorschlag? Bei entsprechendem Bootloader/Urlader, würde ich mal das Branding-Umsetzen versuchen, falls das vermeintliche FW-Update in Richtung "Internationalisierung" ging.

 

[stoney]

Das war doch das Modem oder?
Bei der 7390 ist es ja bekannt (selbst schon zig Mal gemacht), dass ein Telefoniebauteil kaputt geht (waren imo mehrer welche kaputt gehen können und deshalb die Box beim booten hindert).

Aber es geht ja primär darum, überhaupt eine FW auf die Box zu bekommen..

Allerdings sehe ich grade, dass ich zu flüchtig gelesen habe. Recovery läuft ja erfolgreich durch....

Allerdings wären diese Werte trotzdem interessant, diese könnten ein erfolgreiches booten verhindern, vorallem bei der Beschreibung der "Lichterorgel"

 

[oconnor]

Ich bin noch auf Arbeit, kann aber heute Abend die Environment variablen vom auslesen durch das PeterPan Tool anonymisiert hier posten. Das Fritzrecovery sagt jedes mal erfolgreich. Kann das Log später dann auch noch posten.

Laut TE ist der Bootloader wohl intakt.

Ja auf dem adam2 habe ich jedenfalls Zugriff

P.S.: Als Vorschlag? Bei entsprechendem Bootloader/Urlader, würde ich mal das Branding-Umsetzen versuchen, falls das vermeintliche FW-Update in Richtung "Internationalisierung" ging.

Ich weiß leider nicht was vorher mit der Box passiert ist. Ein setzen von avm zu amve im adam2 hatte ich auch schon probiert und ein Internationales Recovery durchgeführt --> Bootschleife

PS:Super das man hier so schnelle Antworten bekommt.

 

[Micha0815]

2. Mittels PeterPan Skripten mtd3 und mtd4 geflashed nach der Anleitung --> Bootschleife

Diesen Punkt solltest Du imho nochmals erläutern? Falls recht im Link gelesen behandelt dies eine FB6490 die aus adam2-Sicht so darauf schaut

mtd0    0x0,0x4000000        Filesystem ARM
mtd1    0x4000000,0x4800000    Kernel ARM
mtd2    0xa0000,0xc0000        Urlader
mtd3    0xc0000,0x100000    Environment
mtd4    0x100000,0x140000    Environment
mtd5    0x140000,0x1e0000    DOCSIS
mtd6    0x4800000,0x8800000    Filesystem ATOM
mtd7    0x8800000,0x9000000    Kernel ATOM
mtd8    0x0,0x80000        cefdk
mtd9    0x80000,0x90000        cefdk_config
mtd10    0x90000,0xa0000        GPT_Backup
mtd11    0x9000000,0xd000000    Filesystem ARM (reserved)
mtd12    0xd000000,0xd800000    Kernel ARM (reserverd)

Bei einer 7490 schaut adam2 m.W. so

mtd0: 00400000 00020000 "kernel"
mtd1: 03000000 00020000 "filesystem"
mtd2: 00400000 00020000 "reserved-kernel"
mtd3: 03000000 00020000 "reserved-filesystem"
mtd4: 00200000 00020000 "config"
mtd5: 19600000 00020000 "nand-filesystem"
mtd6: 00040000 00001000 "urlader"
mtd7: 00060000 00001000 "tffs (1)"
mtd8: 00060000 00001000 "tffs (2)"

auf die mtd`s

Was mit welchem Skript Du auslesen ggfs. flashen/löschen wolltest, solltest Du vielleicht erläutern.
LG

 

[Insti]

ich habe hier eine defekte Fritzbox, die angeblich nach einem Firmware Update in eine Bootschleife geraten ist.

Bei manchen Ebay Auktionen ist genau das zu lesen, weil man dadurch einen höheren Preis erzielt als wenn man schreibt was wirklich passiert ist, nähmlich das die Box nach einem Sturm wahrscheinlich einen Blitzschaden hat. Hatte schon einige 7490 mit Blitzschaden und selbe Symptome.

 

[avm_7170]

Zeichnete nicht neulich in einem Thread hier ein defektes WLAN verantwortlich für eine Bootschleife, was durch Flashen eines entsprechenden Freetz-Images via Bootloader der FB zu einem 2ten Leben verhalf?

@Micha0815:

kannst du mal den Link zu diesem Thread angeben

@Insti:

und konntest du die Boxen mit einem Blitzschlag wieder zum Leben erwecken ?

 

[Insti]

@Insti:
und konntest du die Boxen mit einem Blitzschlag wieder zum Leben erwecken ?

Beim aufsprühen von Kältespray auf den Lantiq Chip haben manche wieder durchgebootet bis zum nächsten reboot wo die wieder im loop bleiben.

 

[oconnor]

HWRevision            185
HWSubRevision         6
ProductID             Fritz_Box_HW185
SerialNumber          0000000000000000
annex                 B
autoload              yes
bootloaderVersion     1.1964
bootserport           tty0
cpufrequency          500000000
crash                 [0]597dc82a,5ad829d3,1[1]0,0,0[2]0,0,0[3]0,0,0
firstfreeaddress      0x81116240
firmware_info         113.06.93
firmware_version      avm
flashsize             nor_size=0MB sflash_size=1024KB nand_size=512MB
linux_fs_start        0
maca                  5C:49:79:XX:XX:XX
macb                  5C:49:79:XX:XX:XX
macwlan               5C:49:79:XX:XX:XX
macwlan2              5C:49:79:XX:XX:XX
macdsl                5C:49:79:XX:XX:XX
memsize               0x10000000
modetty0              38400,n,8,1,hw
modetty1              38400,n,8,1,hw
mtd0                  0x400000,0x3400000
mtd1                  0x0,0x400000
mtd2                  0x0,0x40000
mtd3                  0x40000,0xA0000
mtd4                  0xA0000,0x100000
mtd5                  0x0,0x200000
my_ipaddress          192.168.178.1
prompt                Eva_AVM
ptest                
req_fullrate_freq     250000000
sysfrequency          250000000
tr069_passphrase      vJLExpXXXXXX
tr069_serial          00040E-5C4979XXXXXX
urlader-version       2964
usb_board_mac         5C:49:79:XX:XX:XX
usb_device_id         0x0000
usb_device_name       USB DSL Device
usb_manufacturer_name  AVM
usb_revision_id       0x0000
usb_rndis_mac         5C:49:79:XX:XX:XX
wlan_key              XXXXXXXXXXXXXXXXX

So sehen die environment Variablen aus. Ich bin genau nach der Anleitung gegangen 6490. Mist hätte ich hier etwas anderes machen sollen?

 

[stoney]

Natürlich, denn eine 6490 ist KEINE 7490, auch wenn das Geäuse fast identisch ist

Du hättest eva_to_memory aus den YF-Scripten nehmen sollen (vorher mit image2ram ein passendes Image erzeugen) wie das geht? > Installation von Inhouse-Versionen ab Version 07.08

Edit ging davon aus, dass versucht wurde das Firmwareimage nach mtd3+4 zu schreiben.

 

[NDiIPP]

Ich bin genau nach der Anleitung gegangen 6490. Mist hätte ich hier etwas anderes machen sollen?

Jein. Die Anleitung (TFFS-Image mit "build_tffs_image" erstellen und mit "eva_store_tffs" hochladen) ist prinzipiell auch für die 7490 (und weitere Fritzboxen) geeignet. Und bei der 7490 liegen die beiden TFFS auch in mtd3+4 (so wie bei der 6490), aus Sicht des Bootloader. Also prinzipiell hast du erst einmal nichts falsch gemacht ("eva_to_memory" und "image2ram" hätten hier auch nicht funktioniert wenn man ein neues TFFS-Image erstellen und hochladen möchte), zumindest wenn du dabei keine Fehler gemacht hast bei der Umsetzung der verlinkten Anleitung.

Aber dennoch hättest du dir das sparen können denn das Recovery-Tool von AVM (was ja bei deiner Box funktioniert) macht das bereits (also TFFS-Image aus dem Environment und Counter erstellen und in mtd3+4 hochladen). Für die 6490 gibt es halt nur kein offiziell erhältliches Recovery-Tool weshalb man das Erstellen und Hochladen eines neuen TFFS-Images eben manuell machen muss (wenn man das machen möchte), für die 7490 steht aber ein Recovery-Tool zur Verfügung.


Bei deiner 7490 scheint halt eine Hardwarekomponente defekt zu sein (kann nicht initialisiert werden). Das könnte bspw. einer der beiden WLAN-Chips sein oder einer der 4 Ethernet-PHYs (2 davon sind im SoC integriert (LAN1+2) und 2 weitere (LAN3+4) davon separat auf dem PCB) oder auch der FPGA.
Mit einer unmodifizierten Firmware wird die Box also wohl nicht mehr laufen. Mit einer modifizierten Firmware, wo die betroffene Hardwarekomponente bei der Initialisierung ausgenommen wird, könnte man sie wieder zum Leben erwecken (wobei dann natürlich die Funktion der deaktivierten defekten Hardwarekomponente nicht mehr zur Verfügung steht).

 

[PeterPawn]

Mist hätte ich hier etwas anderes machen sollen?

Nein, das Environment paßt schon so für eine 7490, weil der zweite Teil in #6 die MTDs aus der Sicht des laufenden Systems zeigt und nicht aus der Sicht des Bootloaders.

Wenn man das alles so zusammenzählt beim Booten, ist es wohl für den Piglet-Treiber schon fast etwas zu spät als Ursache ... aber damit würde ich erst einmal anfangen, weil häufig ein Schaden am Xilinx-Chip (wo dann die POTS-, ISDN- und DECT-Unterstützung nicht initialisiert werden kann, die Ursache ist.

Andererseits weist der Wechsel im Blinkrhytmus der Power-LED eigentlich darauf hin, daß da schon das DSL-Modem aktiviert wurde und jetzt auf der Suche nach Synchronisation ist ... das wäre (aus Computersicht) lange nach dem Laden des Piglet-Treibers und eher in der Gegend, wo dann Ethernet-Ports und WLAN initialisiert werden. Bei neuerer Firmware wird auch das m.W. auf Erfolg überwacht (ohne defekten PHY ist das halt schwer zu verfolgen oder man müßte durch die Kernel-Quellen krauchen) und ein defekter PHY kann auch zu einer solchen Schleife führen ... ebenso aber auch ein Problem beim Aktivieren des WLANs.

EDIT: Wenn Du kannst und die Box wiederbeleben willst (ungeachtet des Aufwands), bestücke die serielle Schnittstelle und dann kann man anhand der Ursache der "kernel panic" (die hier wohl zum Reboot führt) eine Strategie entwickeln, wie man die originale Firmware anpassen müßte, damit die Box läuft - so man das überhaupt noch will, wenn z.B. das WLAN tatsächlich der Grund sein sollte.

EDIT2: Das wurde Dir aber vor ein paar Minuten schon geschrieben ... hatte ich nur noch nicht auf dem Schirm, als ich mit meiner Antwort begann.

 

[oconnor]

Danke für die Antworten. Dann habe ich ja doch nix falsch gemacht. Serial ranlöten ... "kernel panic" analysieren ... hmm das muss ich mir noch überlegen.

FRITZ!Box 7490 suchen an: 192.168.178.1
Eine Anlage gefunden! - Ermitteln der aktuellen Version.
Version erfolgreich ermittelt!
    Hardware:   FRITZ!Box 7490
    Urlader:   2964
    Firmware:   113.06.93
Flashbereich (mtd3)
    Lösche   Flashbereich (mtd3)
    Restauriere   Flashbereich (mtd3)
Flashbereich (mtd4)
    Lösche   Flashbereich (mtd4)
    Restauriere   Flashbereich (mtd4)
    Restauriere   Flashbereich (mtd1)
FRITZ!Box 7490 erfolgreich wiederhergestellt!
Die Wiederherstellung ist nach einem Neustart des Gerätes abgeschlossen.

Das sagt das Recovery. Warum wird da eigentlich nicht das mtd1 vor dem schreiben gelöscht?

Was bedeutet eigentlich die crash variable beim adam2

crash                 [0]597dc82a,5ad829d3,1[1]0,0,0[2]0,0,0[3]0,0,0

Kann man daraus irgendwas lesen?

@PeterPawn falls du die Skripte erstellt hast, großen Dank dafür, auch wenn sie leider mein Problem nicht gelöst haben.

 

[NDiIPP]

Das sagt das Recovery. Warum wird da eigentlich nicht das mtd1 vor dem schreiben gelöscht?

Weil die 7490 ein NAND-Modell ist, da läuft das etwas anders mit dem Flashen der Firmware (Kernel und Filesystem Image) über den Bootloader.
Auf mtd3+4 (TFFS) kann dagegen bei der 7490 über den Bootloader noch direkt geschrieben werden (das liegt bei der 7490 noch nicht im NAND-Flash).