[Problem] FRITZ!Box 6591 Cable (HW233.8, LGI→Retail debranded): Bootloop ab Firmware > 8.03 — DPD/NP-CPU Initialisierung schlägt fehl

[neo.b]

Gerätedaten​

Merkmal	Wert
Produkt	FRITZ!Box 6591 Cable (Fritz_Box_HW233)
Hardware	HWRevision 233, HWSubRevision 8
Annex	Kabel
Bootloader	4711.0815 (Platzhalter-Anzeige)
Speicher	eMMC, 18 Partitionen (GPT), zusätzlich SPI-Flash (Descriptor/BIOS/ME/Platform Data)
Branding	Ursprünglich LGI, selbst auf Retail umgestellt (DMC=RTL=y, firmware_version=avm)
Laufende Firmware	161.08.03, Build 118553
Kernel (funktionierend)	Linux 5.15.153, Build 2024-12-05

Symptom​

Die Box bootet mit FRITZ!OS 8.03 stabil (Uptime mehrere Tage). Jede getestete Firmware > 8.03 (konkret 8.21 und 8.25) führt zu einem Bootloop. Die Box startet, mountet das Root-Dateisystem, aber die Init-Sequenz hängt und der AVM-Watchdog löst nach ~142s eine Kernel-Panic aus.

Wichtig: Auf Retail-Boxen (nicht debranded) funktionieren 8.21+ normal. Das Problem ist spezifisch für diese debranded Box.

Belegter Fehlerpfad (8.21-Panic-Log)​

FW: 08.21
Buildnumber: 126328
Bootloader: 4711.0815
Linux version 5.15.179
VFS: Mounted root (squashfs filesystem) readonly on device 179:3.
AVM_WATCHDOG: System Init Ueberwachung 120 Sekunden
Kernel panic - not syncing: avm_watchdog_reboot: init sequence hangs!

Der Kernel startet, das RootFS wird gemountet — der Abbruch erfolgt während der Systeminitialisierung nach dem Root-Mount.

Root Cause: DPD/NP-CPU Initialisierung​

Was ist dpd_netdev?​

dpd_netdev ("Data Pipe Driver for Network Device") ist der Treiber, der die Kommunikation zwischen der APP-CPU (Hauptprozessor, läuft Linux) und der NP-CPU (Network Processor, ARM/Puma7) über eine Hardware-Mailbox herstellt. Ohne diese Verbindung funktioniert kein Netzwerk.

Verhalten unter 8.03 (funktioniert)​

Aus dem Support-Dump (8.03, Kernel 5.15.153):

[   13.19s] [DPD ERROR] dpd_netdev_default_appcpu_params_init(4202): HW mailbox hwMbox_sendOpcode failed, peer is not ready.
[   14.22s] [DPD ERROR] ...
[   15.62s] [DPD ERROR] ... STATUS = 0xb (11)
[   15.63s] unload module: dpd_netdev
[   20.85s] loaded module: dpd_netdev 0x62641919-0x5900a27e

• 124 DPD-Errors von ~13s bis ~138s
• Modul wird bei ~15.63s entladen, bei ~20.85s neu geladen → Erfolg
• System läuft danach stabil (Uptime 2+ Tage)

Verhalten unter 8.21 (bootloop)​

Aus dem Panic-Log (8.21, Kernel 5.15.179):

• 123 DPD-Errors von ~14.86s bis ~142.75s
• Kein erfolgreiches loaded module: dpd_netdev
• Init-Watchdog aktiviert bei ~14.46s
• Softwatchdog-Reboot bei ~137.76s
• Panic bei ~142.88s: avm_watchdog_reboot: init sequence hangs!

Der stärkste belegte Unterschied: Unter 8.03 löst sich der DPD-Fehler nach Retries auf, unter 8.21 nie.

Fehlerdetails​

HW_MBOX_KERNEL_ERROR send Opcode to NP_CPU(0) - subject replied with internal error! STATUS = 0xb (11)
[DPD ERROR] dpd_netdev_default_appcpu_params_init(4202): HW mailbox hwMbox_sendOpcode failed, peer is not ready.

Die NP-CPU antwortet auf Mailbox-Anfragen, aber mit STATUS = 0xb (11) ("internal error") — sie lehnt die Initialisierung ab. Die APP-CPU sendet OpCodes, die die NP-CPU nicht verarbeitet.

Untersuchte und ausgeschlossene Ursachen​

1. Partition/Dateisystem-Integrität — NICHT die Ursache​

• Beide APP-Root-Dateisysteme (/dev/mmcblk0p3 und /dev/mmcblk0p9) lassen sich read-only mounten
• tar-Leseprüfung für beide mit Exitcode 0
• Der 8.21-Kernel mountet sein RootFS erfolgreich (VFS: Mounted root (squashfs) readonly on device 179:3)
• → Kein defektes RootFS

2. Environment/Platform-Data — Verdächtig, aber nicht allein erklärend​

• avm-prom: restore_finalization: Environment data corrupt! erscheint bei beiden Versionen (8.03 und 8.21)
• Bei 8.03: Warnung vorhanden, aber System bootet
• Bei 8.21: gleiche Warnung, aber System hängt
• → Die Warnung allein erklärt nicht den Bootloop

3. Bootloader (4711.0815) — Verdächtig​

• Anzeige 4711.0815 ist offensichtlich ein Platzhalter
• Backup-String bootloaderVersion1.3614 (aus mtd3_backup.bin, nicht verifiziert)
• Externer Thread auf Digital Eliteboard berichtet gleiche Diskrepanz
• → Unklar ob Bootloader-Version zur neueren Firmware passt

4. Bank-/Partitionszuordnung — Verdächtig​

• linux_fs_start = 0 im Environment
• Erfolgreicher 8.03-Boot: Root-Mount auf p9 (APP_CPU_ROOTFS1)
• Fehlgeschlagener 8.21-Boot: Root-Mount auf p3 (APP_CPU_ROOTFS0)
• Diskrepanz zwischen logischer Bankauswahl und physischer Partition
• → Möglicherweise falsche Partition wird unter neuerer Firmware verwendet

Firmware-Analyse (eigene Extraktion)​

Ich habe die offiziellen AVM-Images 8.03 und 8.25 heruntergeladen und extrahiert (uimg → unsquashfs):

Partitionen (beide Versionen identisch)​

Partition	Inhalt	Größe 8.03	Größe 8.25
p2	APP_CPU_KERNEL	9.0 MB	9.0 MB
p3	APP_CPU_ROOTFS	34.9 MB	36.7 MB
p8	NP_CPU_KERNEL (ARM)	3.1 MB	3.2 MB
p9	NP_CPU_ROOTFS (ARM)	9.9 MB	9.9 MB
p10	GWFS	20 KB	20 KB

Kernel-Versionen​

• 8.03: Linux 5.15.153 (Build 2024-12-05)
• 8.25: Linux 5.15.179 (Build 2026-03-03)

NP-CPU (ARM) RootFS​

• Branding-Dateien in beiden: default.language.lgi, default.Fritz_Box_HW233a/lgi, default.0.lgi
• Kein struktureller Unterschied in der Firmware-Architektur
• Boot-Skripte (puma_startup.sh, puma_setup.sh) unterscheiden sich nur in Details (Testmode, Build-Datum)
• NP-CPU-Kernel-Version konnte nicht aus dem ARM-Kernel extrahiert werden (komprimiert/verschlüsselt)

Schlussfolgerung aus Firmware-Analyse​

Die Firmware-Struktur ist zwischen 8.03 und 8.25 identisch. Der Unterschied liegt ausschließlich in der Software-Version (Kernel 5.15.153 vs 5.15.179) und der strengeren Validierung.

Meine Hypothese (unabhängig von der Fallakte)​

Die debranded Box hat inkonsistente Platform-Daten (TFFS/mtd3), die unter 8.03 toleriert werden, aber unter 8.21+ die NP-CPU-Initialisierung blockieren. Begründung:

1. Die Firmware-Struktur ist identisch — kein Hardware/Partition-Problem
2. Auf Retail-Boxen funktioniert 8.21+ — das Problem ist debranding-spezifisch
3. restore_finalization: Environment data corrupt! erscheint bei beiden Versionen, aber nur 8.03 toleriert es
4. Die NP-CPU antwortet mit STATUS = 0xb (11) — sie läuft, aber lehnt die APP-CPU-OpCodes ab
5. Die NP-CPU erhält ihre Konfiguration aus den Platform-Daten (mtd3/SPI-Flash)
6. Wenn diese Daten durch das Debranding inkonsistent sind, initialisiert die NP-CPU unter strengerer Validierung (8.21+) nicht → "peer is not ready"

Die NP-CPU-Partitionen (p4, p5, p10, p11) wurden bei der Debranding-Prozedur möglicherweise nicht mit aktualisiert. Die APP-CPU unter 8.21+ prüft strenger, ob APP- und NP-CPU zur selben "Identität" gehören.

Offene Fragen für Experten​

1. Welche Platform-Daten validiert die NP-CPU unter 8.21+? Die restore_finalization-Warnung erscheint bei beiden Versionen, aber nur die neuere scheitert. Was genau wird strenger geprüft?
2. NP-CPU-Kernel-Version: Der ARM-Kernel (p8) konnte nicht extrahiert werden. Welche Version läuft auf der NP-CPU unter 8.03 vs 8.25?
3. Bootloader-NP-Initialisierung: Macht der Bootloader (4711.0815) NP-CPU-spezifische Initialisierung, die für neuere Firmware nötig ist?
4. Bank-Zuordnung: Warum bootet die Box mit linux_fs_start=0 auf p9 (APP_CPU_ROOTFS1) statt p3 (APP_CPU_ROOTFS0)? Ist das normal für diese Plattform?
5. TFFS-Bereinigung: Würde eine TFFS-Bereinigung (Environment zurücksetzen) das Problem lösen? Risiko: Box unbootbar.
6. Vergleich mit Retail-Box: Gibt es jemanden mit einer Retail-6591, der die NP-CPU-Partitionen (p4, p5, p10, p11) auslesen und mit dieser vergleichen kann?

 

[Karl.]

Ich hoffe ich habe es nicht überlesen, aber wie hattest Du aus einer lgi Box eine Retail Box gemacht?

 

[NDiIPP]

Meine Fragen dazu:

1. Wie @Karl. würde ich gerne genau wissen, wie diese Box ursprüngliche debrandet wurde. Nur indem man den Wert der Variable DMC geändert hat (also RTL=n auf RTL=y) oder auch indem der Bootloader manipuliert wurde (wie es eine Anleitung aus dem D"E"B beschreibt)?
2. Wurde bereits versucht (mit laufendem bzw. installiertem FRITZ!OS >=8.2x) die Einstellungen per >recovered=x< (über die Variable firmware_info) zurückzusetzen?

 

[neo.b]

Meine Fragen dazu:

1. Wie @Karl. würde ich gerne genau wissen, wie diese Box ursprüngliche debrandet wurde. Nur indem man den Wert der Variable DMC geändert hat (also RTL=n auf RTL=y) oder auch indem der Bootloader manipuliert wurde (wie es eine Anleitung aus dem D"E"B beschreibt)?
2. Wurde bereits versucht (mit laufendem bzw. installiertem FRITZ!OS >=8.2x) die Einstellungen per >recovered=x< (über die Variable firmware_info) zurückzusetzen?

Richtig, nach der Anleitung aus dem anderen Board inkl. Bootloader edit.
Box steht aktuell auf provider avm und rtl.y und neuestes freetz-ng auf 8.03 Basis läuft einwandfrei. Jegliches flashen einer höheren fw als 8.03, egal ob retail oder freetz, resultiert im Bootloop. Nach manuellem Bank Wechsel, bootet 8.03 wieder.

Punkt 2 habe ich nicht versucht.

 

[NDiIPP]

Wenn Pkt. 2 noch nicht probiert wurde, probieren. Falls das nicht hilft, es gibt hoffentlich noch ein Backup des originalen/unveränderten Bootloader. Falls ja, würde ich diesen vermutlich wieder flashen und damit probieren (vielleicht wird ja bei neueren Firmware-Versionen die Signatur des Bootloader überprüft).

BTW:
Es gibt eigentlich keinen Grund den Bootloader zu modifizieren, die üblichen Brandings werden von der originalen Firmware bereits unterstützt und wenn man sowieso modifizierte Firmware verwendet, kann man damit bei Bedarf den Wert aus dem Environment ignorieren.