FRITZ!Box 7590 hängt im EVA Bootloader

[NDiIPP]

Einen NAND Dump würde ich wahrscheinlich noch hinbekommen.

Das ist gut. Zumindest wenn man den NAND überhaupt noch auslesen kann. Da könnte man also einen neuen (passenden) NAND-Flash verbauen, den man zuvor mit dem Dump des alten beschrieben hat.

Von JTAG habe ich bisher keine Ahnung.

Das ist egal, das JTAG-Interface dürfte aufgrund mangelnder (öffentlich zugänglicher) Kenntnisse i.V.m. dem verwendeten SoC wohl sowieso kaum hilfreich sein.

 

[HansTodi]

Ratet Mal, was gestern gekommen ist, nachdem ich diese Woche eine Sendungsnummer für die Rücksendung von AVM erhalten habe...

Ja genau, eine neue FRITZ!Box mit Netzteil. Ist anscheinend ohne Probleme durch gegangen, obwohl die Stellen schon deutlich sichtbar waren, weshalb ich auch nicht erwartet hätte dass es klappt.

Auf dem Lieferschein im Karton steht Austausch im Rahmen der Kulanz. Somit anscheinend auch keine (versteckten) Kosten. Ansonsten war auch nichts dabei.

Bin auf jeden Fall positiv vom Support überrascht, aber auch verwundert ob sie das Gerät überhaupt angeschaut haben.

 

[Domsk]

Ich bin mittlerweile auch etwas weiter gekommen.

Die ersten Zeilen der seriellen Ausgabe kommen direkt vom GRX550 Netzwerkprozessor. Dort werkelt wohl ein sogenanntes Mask ROM, das den Bootvorgang aus unterschiedlichen Quellen steuert. Danach müsste der Bootloader aus dem NAND übernehmen?

Nachdem ich das Board längere Zeit heruntergekühlt hatte konnte ich kurzzeitig bewirken, dass der Bootvorgang bis zum Kernel Panic weiterläuft. Nach ein Paar Durchläufen bleibt es allerdings wieder im Mask ROM stehen. Erwärmung und mechanischer Druck auf den Prozessor brachten keine Veränderung. Kalte Lötstellen würde ich also erstmal ausschließen.

Ich habe den NAND mittlerweile auch ausgelötet. Die serielle Ausgabe spuckt ohne NAND wiederholbar folgendes aus. Das Mask ROM scheint also soweit zu funktionieren. Es kann keinen NAND finden und springt in den UART-Modus.

ROM VER: 2.1.0
CFG 09
B
.
.
.
.
.
No valid image detected
No valid image detected
UART

Einen Dump habe ich nun auch erstellt. Ein zweiter Dump brachte die gleichen Ergebnisse, sodass der NAND zumindest richtig gelesen wurde. Falls es jemanden interessiert hier die BIN-Datei:

Fritzbox7590Dump1.bin

drive.google.com

Ich war etwas verwundert, dass es keinerlei Schwierigkeiten beim lesen des NAND gab. Ich hatte mich schon darauf vorbereitet ihn kühlen zu müssen um Daten lesen zu können. Ich weiß allerdings nicht wie plausibel die Daten im Dump sind. Ich weiß auch noch nicht was nun der nächste Schritt sein wird. Ich würde gerne die Ursache finden. Die SySS-Research NAND Dump Tools und Binwalk sind da Tools die häufiger erwähnt werden um den Dump zu zerpflücken. Vielleicht auch mal die ECC Status Register des NAND auslesen. Der Toshiba (bzw. mittlerweile Kioxia) TC58BVG2S0HTA00 ist aktuell nicht wirklich lieferbar (52 Wochen Lieferzeit, wahrscheinlich mit Mindestmenge). Da gibt es aber mit Sicherheit Alternativen.

Ich bin weiter offen für Vorschläge und Informationen. Vielleicht möchte sich jemand mit mehr Ahnung den Dump mal ansehen?

Edit:
Das ECC Status Register spuckt aus, dass alle Sektoren fehlerfrei sind:

1st sector ECC status:     |0|0|0|0|0|0|0|0| (0x00)
2nd sector ECC status:     |0|0|0|1|0|0|0|0| (0x10)
3rd sector ECC status:     |0|0|1|0|0|0|0|0| (0x20)
4th sector ECC status:     |0|0|1|1|0|0|0|0| (0x30)
5th sector ECC status:     |0|1|0|0|0|0|0|0| (0x40)
6th sector ECC status:     |0|1|0|1|0|0|0|0| (0x50)
7th sector ECC status:     |0|1|1|0|0|0|0|0| (0x60)
8th sector ECC status:     |0|1|1|1|0|0|0|0| (0x70)

Einen defekten NAND würde ich damit ausschließen. Wäre vielleicht noch möglich, dass jemand Mist in den NAND geschrieben hat.
Wenn ich das richtig verstehe, dann bringen mir die NAND Dump Tools nichts, da der TC58 eine integrierte Hardware ECC hat und beim auslesen keine ECC Codes mitschickt.

Binwalk erkennt folgendes im Dump:

DECIMAL       HEXADECIMAL     DESCRIPTION
--------------------------------------------------------------------------------
42004         0xA414          CRC32 polynomial table, big endian
312340        0x4C414         CRC32 polynomial table, big endian
540672        0x84000         uImage header, header size: 64 bytes, header CRC: 0x9986076E, created: 2017-03-10 09:48:33, image size: 186880 bytes, Data Address: 0x85000000, Entry Point: 0x85000000, data CRC: 0xDE42B67, OS: Linux, CPU: MIPS, image type: Firmware Image, compression type: gzip, image name: "urlader"
680384        0xA61C0         CRC32 polynomial table, big endian
690244        0xA8844         Copyright string: "Copyright 2005 AVM Date: %s Time: %s "
700928        0xAB200         JFFS2 filesystem, big endian
743428        0xB5804         Zlib compressed data, default compression
747652        0xB6884         Zlib compressed data, default compression
811008        0xC6000         uImage header, header size: 64 bytes, header CRC: 0x9986076E, created: 2017-03-10 09:48:33, image size: 186880 bytes, Data Address: 0x85000000, Entry Point: 0x85000000, data CRC: 0xDE42B67, OS: Linux, CPU: MIPS, image type: Firmware Image, compression type: gzip, image name: "urlader"
950720        0xE81C0         CRC32 polynomial table, big endian
960580        0xEA844         Copyright string: "Copyright 2005 AVM Date: %s Time: %s "
971264        0xED200         JFFS2 filesystem, big endian
1013764       0xF7804         Zlib compressed data, default compression
1017988       0xF8884         Zlib compressed data, default compression
8032804       0x7A9224        Nagra Constant_KEY IDEA_Key: 12345678 ABCD1234 12345678
22708224      0x15A8000       UBI erase count header, version: 1, EC: 0x7, VID header offset: 0x400, data offset: 0x1000

 

[chips]

Ich würde mal tippen, dass der SOC angeschossen ist durch Überspannung auf LAN-Ports
habe einige solche in den Fingern gehabt mit dem Fehlerbild (nur power led leuchtet, bootet nicht vom NAND-Flash)
eine einfache Prüfung dazu: Box ohne Strom, Widerstand messen von den 3 Spulen links vom Kühlkörper gegen Masse (Gehäuse der USB-Buchse daneben) + an die Spule, - an Masse
bei den 2 kleineren Spulen (da kommen 2 IO-Spannungen des SOCs her) sollte was im KOhm-Bereich zu messen sein,
bei der größeren Spule in der Mitte (da kommt die SOC-Core-Spannung her) ca 140 Ohm
Wenn der SOC angeschossen ist, sind die Werte viel kleiner - im Bereich 10-500 Ohm bei den 2 IO-Spannungen und <100 Ohm an der Core-Spannung
p.s. Das ist aber kein satter Schluss - die Wandler schaffen die höhere Last und schalten nicht ab
Weiterhin: die 0,75A sind auch zu hoch beim Boot-Beginn...- sollte eher 0,6A bei gesunder Box sein
auch das deutet auf defekten SOC hin
Gruß
Chips

 

[Domsk]

@chips damit liegst du goldrichtig.
Nachdem ich den Rechner und den LAN-Port gewechselt habe, konnte ich in den seltenen Momenten in denen die Box bis zum Kernel Panic durchgebootet ist tatsächlich mit dem Bootloader kommunizieren. Dabei kamen allerdings immer Meldungen wie "IP checksum error" oder ähnliches. Zudem war die Box danach nicht mehr ansprechbar. LAN1 war komplett tot.

Auch ein kurzer Einblick mit dem Logic Analyzer zeigte, dass die CPU ab einem gewissen Punkt einfach keinerlei Signale mehr sendet.

Die rechte der beiden kleinen Spulen hatte einen Widerstand von ca. 2 Ω. Die große Spule hatte um die 150 Ω. die 3,3 V Versorgung hatte zu GND einen Widerstand von ca. 8 Ω. Nachdem der Kühlkörper runter war hat man auch gespürt, dass der GRX550 recht schnell warm wird, was für eine CPU ohne Kühlkörper ja nicht unbedingt unüblich ist. Auch am Übertrager von LAN1 war ein erstaunlich geringer Widerstand messbar.
Nachdem ich alle Bauteile zwischen CPU und den LAN-Ports ausgelötet habe war der Widerstand weiterhin so gering. Nachdem ich die CPU ausgelötet habe haben sich die Widerstände normalisiert. Die CPU ist also tatsächlich hinüber.

Ich schätze, dass entweder die Versorgungsspannung so instabil/gering war, dass die CPU Fehler geschmissen hat oder sie hat sich wegen Überhitzung bis zum nächsten Reset aufgehängt/abgeschaltet. Danach war die Kerntemperatur so hoch, dass es nur noch für die ersten Zeilen der seriellen Ausgabe gereicht hat.

Aus Interesse habe ich dann den Die des Prozessors freigelegt und zwei beschädigte Stellen gefunden.


Oben ist noch eine Schutzschicht (vermutlich) aus Polyimid sichtbar. Die habe ich versucht runterzuläppen. Hier eine weitere beschädigte Stelle, die Die-Bezeichnung (Lantiq L1033 A2) und Bereiche die hübsch anzusehen sind:

[Edit Novize: Riesenbilder gemäß der Forumsregeln auf Vorschau verkleinert]

Überspannungsschaden trifft es hier denke ich ganz gut. In den ersten beiden Bildern sieht man, dass etwas vom Die abgeplatzt ist, die Leiterbahnen verbrannt sind und sich sogar die Schutzschicht zersetzt hat. Beim dritten Bild scheint sich eine Art Dampfblase gebildet zu haben.
Damit hab ich zwar viel neues gelernt, aber die Fritzbox ist leider ein Fall für die Tonne.
Danke für den Tipp @chips

 

[chips]

schöne Bilder - good job !
die niederohmigen 3,3V hatte ich vergessen, die gehen ja auch auf den SOC;
vermutlich werden die PHYs mit 3,3V VCC betrieben, normalerweise ist was von DC 1,2-1,8V an den LAN-Trafos zu messen;
leider ist da die 7590 extrem empfindlich an den LAN-Ports, im Gegensatz z.B. zu der 7490 - dessen SOC würde einiges wegstecken, was den 7590 SOC killt - habe schon 7490 gesehen mit deutlichen Überspannungsspuren an LAN1 oder 2, was der SOC überlebt hatte;
und wenns bei der 7490 zu heftig wird, gibts den Klassiker mit dem abgebrannten Transistor, der die 2,5V IO-Spannung liefert;
sieht man an dem Fehlerbild LED1/2 und 5 leuchten dauernd...