Ich habe mir jetzt zwei Protokolle angesehen, das mit
eva_to_memory und das vom Recovery-Programm. Daß die Serielle zur Verfügung steht, ist schon mal gut ... aber die Erwartungshaltung, daß sich durch die Benutzung anderer Programme etwas ändern würde, ist (fast) beleidigend (nicht zuuu ernst nehmen), denn es unterstellt ja, daß "Nachbauten" nicht genauso arbeiten würden, wie "das Original" von AVM (was es ja nur für Windows gibt und was noch deutlich mehr macht, als nur irgendeine Firmware - und dann nicht mal eine "beliebige" - zu installieren).
Aber ich drücke mal ein Auge zu (
) und versuche mal eine Erklärung für die jeweiligen Protokolle.
Jeder Startversuch, in dessen Protokoll diese Zeilen auftauchen:
Rich (BBCode):
[ 1.930000] [ifx_jffs2_parser_function] exit on mtd ram-filesystem
[ 1.990000] 2 find_squashfs partitions found on MTD device ram-filesystem
[ 1.990000] Creating 2 MTD partitions on "ram-filesystem":
[ 2.000000] 0x000000290d00-0x0000020c0d00 : "rootfs_ram"
[ 2.010000] 0x000000000000-0x000000290d00 : "kernel_ram"
[ 2.010000] mtd-ram mtd-ram: registered mtd device
ist einer, bei dem eine Firmware in den Hauptspeicher geladen und dort gestartet wurde. Das sind die (zusätzlichen) Zeilen, die man sieht, wenn der Filesystem-Scanner im Kernel die ins RAM geladenen Daten gefunden hat. Üblicherweise führt deren Vorhandensein jetzt dazu, daß über das Skript
/sbin/flash_update nichts weiter geschieht, als das System aus dem RAM in den Flash-Speicher zu schreiben - danach startet das System neu. Daher sind auch die "Soft-Reboots" beim jeweils ersten Start vollkommen normal. Beim nächsten Start gibt es dann die Daten im RAM nicht mehr und das System wird nun aus dem Flash-Speicher geladen. Damit sind auch Fehlernachrichten, die beim ersten Start NICHT aufgetreten sind, kein Zeichen dafür, daß danach schon alles gut gehen wird - das System wird nur bis zu einem gewissen Punkt initialisiert (praktisch eigentlich nur der Kernel, aus dem Dateisystem wird fast nichts genutzt außer dem erwähnten Skript und den darin aufgerufenen Programmen).
Beim zweiten Start sind in beiden Protokollen Fehler beim Lesen des SquashFS-Dateisystems zu sehen ... hier rächt es sich jetzt, wenn man alles durcheinander testet und dann letztlich doch vergißt, die Umstände, unter denen eine bestimmte Protokoll-Datei entstanden ist, hinreichend genau zu beschreiben.
Da kaum davon auszugehen ist, daß der gesamte NAND-Flash defekt ist und außerdem angenommen werden kann, daß die Daten im RAM noch korrekt waren, macht es deutlich mehr Sinn, die Vorgänge einmal mit dem Wert
0 für
linux_fs_start auszuführen und einmal mit dem Wert
1 - und dafür dann die jeweiligen Protokolle bereitzustellen (natürlich mit passender Kennzeichnung, welches wozu gehört). Dazu noch ein kleiner Tipp: Wenn man direkt nach der Nachricht:
[avm_debug] redirecting kernel-messages (/dev/debug) auf der seriellen Console einfach noch einmal die Enter-Taste drückt, wird in Folge des damit ausgeführten Starts einer Shell-Instanz auch die weitere Ausgabe der Kernel-Message auf der Console erfolgen - das vermeidet dann Pausen zwischen Sekunde 16 und irgendwelchen (viel) später doch wieder einsetzenden Ausgaben.
Wobei ich auch ziemlich verblüfft bin, daß/wenn eine (unmodifizierte) Firmware sich 708 Sekunden Zeit läßt, bevor der Watchdog, der den Start überwacht, zuschlägt (oder meinetwegen auch ein paar Sekunden weniger, weil der nicht gleich in der ersten Sekunde scharf gemacht wird) ... das sieht dann fast wieder danach aus (ist aber im Log durch die fehlenden Zeilen nicht zu erkennen), als ob ein Mounten (das ein Lesen der Verwaltungsstrukturen beinhaltet, aber kein komplettes Lesen ALLER Daten) noch möglich war und daher der Init-Watchdog regulär abgeschaltet wurde, bevor dann spätere Zugriffe doch noch zu einer "kernel panic" führen.
Ich würde jetzt erst einmal (systematisch und auch so "protokolliert" hier für Hilfewillige) testen, ob tatsächlich der gesamte Flash betroffen ist (manchmal hilft hier ja auch dessen Management mit, besonders bei Flash mit ONFI-Support, indem tatsächlich defekte Blöcke auch als solche markiert und durch "spare blocks" ersetzt werden), denn es werden ja einmal
mtdblock0 und
mtdblock1 benutzt und für
linux_fs_start 1 dann
mtdblock2 und
mtdblock3. Den beiden Protokollen, die ich mir angesehen habe (s.o.), zufolge, wurden beide mit
linux_fs_start 0 erstellt. Wenn dann tatsächlich beide Sets nicht funktionieren, kann/müßte man ggf. mit passenden Tools (mit einer selbst zusammengestellten Firmware) noch einmal versuchen, den NAND-Flash genauer anzusehen - ich kann mich an einen Fall hier erinnern (der liegt noch gar nicht sooo lange zurück, max. 2 Jahre würde ich sagen), wo sich auf einer Box (allerdings einer, die mit dem UBI-Layer arbeitete) auch partout kein System installieren ließ (auch nicht mit AVM's Recovery-Programm), weil sich die UBI-Strukturen nicht einrichten lassen wollten.
Da half es dann, den Flash mit passenden Kommandos zuvor noch einmal explizit zu löschen. Wobei das bei der 7490 eigentlich erfolgt, soweit ich mich erinnere (bei der 07.27 würde ich dafür aber die Hand auch nicht ins Feuer legen wollen und müßte erst noch einmal nachsehen) - aber anstelle weiterer Spekulationen (und etwas anderes können Überlegungen nicht sein, solange sie nicht auf Protokollen oder einer "Nachschau" basieren) sollte man das erst einmal Schritt für Schritt angehen und schauen, was beim anderen Partition-Set passiert. Zumindest die YAFFS2-Strukturen (das verwendete SquashFS-Image liegt ja erst innerhalb dieser Partition als Datei vor) passen ja anscheinend noch - auch die gehen eigentlich erst mal alle Blöcke durch (wobei es da auch noch einen Checkpoint-/Cache-Mechanismus gibt, der das Mounten beschleunigen soll) und dabei müßten Fehler auch schon auffallen, wenn es sich um "echte" Probleme des Flash-Speichers handelt.
