3490 - Recovery inkompatibel ?!

- Environment auslesen und Inhalt der "provider"-Variablen prüfen
- vollständigen Namen (und Quelle) des Recovery-Programms angeben (und zwar eines konkreten, wenn bei beiden oben stehenden Versionen die identische Fehlermeldung kommt, dann auch beide Programme benennen)
- anhand der Provider-Variablen die Herkunft klären (am besten das komplette Environment hier einstellen, MAC-Adressen meinetwegen verfremden)

Schau doch erst einmal im Bootloader-Environment (dazu per FTP mit dem Bootloader verbinden so wie z.B. auch >hier< beschrieben) z.B. bei den Variablen "firmware_version" und "provider" nach damit wir hier nicht so herum raten müssen.

Bei der Gelegenheit kannst du auch gleich mal nach der Variable "linux_fs_start" schauen (so wie in der verlinkten Anleitung beschrieben), vielleicht ist ja noch in der anderen Partition ein funktionsfähiges/passendes FritzOS vorhanden sodass ein Recovery u.U. gar nicht notwendig ist.

edit
Ach herrje, da war ich zu langsam...

DerDerDon schrieb:

zu 1 und 3 - wie komme ich am besten dran?

Zum Vergrößern anklicken....

S.h. Link in Beitrag #3.

Einmal in der FTP-Session noch ein "QUOTE UNSETENV firmware_info" absetzen ... das löscht den Inhalt der Variablen "firmware_info" und wenn die installierte Version dann startet, trägt sie ihre eigenen Versionsnummer dort wieder ein. Das ist zwar am Ende keine Änderung, aber anhand der Tatsache, ob das geschrieben wird oder nicht, kann man Rückschlüsse ziehen, wie weit die Box kommt. Nach der Schilderung in #1 ist das fast der komplette Bootvorgang, wenn da tatsächlich 2 Minuten vergehen. Da ist dann der Punkt "firmware_info" neu schreiben ziemlich weit vorne, aber man kriegt wenigstens einen Hinweis, daß dieser Punkt (/etc/init.d/S01-head) passiert wurde.

Wobei "ca. 2 Minuten" als Angabe nicht wirklich reicht ... etwas genauer und man kann mit anderen 3490 vergleichen, was zum Zeitpunkt des Reboots passieren sollte. Wobei die 3490 nicht so häufig hier vertreten ist und die "große Schwester" 7490 hat gerade beim Booten (bei der Initialisierung von ISDN und analoger Telefonie) schon etwas andere Abläufe.

Eine weitere Variable, die zu löschen wäre, ist "crash" im Environment. An einigen Stellen wird dort protokolliert (gerade in älterer Firmware), wenn das System "sich nicht mehr traut" an andere Stellen zu schreiben, weil die Panik so groß ist, daß man nicht einmal mehr sicher weiß, daß man nichts wichtiges im TFFS überschreibt. Zwar kann man den Inhalt (das sind Registerinhalte) der Variablen nur schwer interpretieren ohne passende Map-Files, aber schon die Tatsache, daß die Variable neu geschrieben wird, ist ein weiterer Fingerzeig (daß es zu einem Crash kam).

Ist die Box denn als funktionsfähig gekauft oder hat der Verkäufer die als defekt angeboten und Du dachtest Dir: "Das kriege ich schon hin."?

Das fehlende "linux_fs_start" i.V.m. der doch recht alten Firmware-Version deutet auf eine nicht ganz taufrische Box, die auch noch niemals ein Update erhalten hat, hin ... das ist schon ein klein wenig komisch. Der müßte man dann das letzte Update vor der 06.5x schon vorenthalten haben (wenn die installierte wirklich eine 06.23 ist) oder die war recht lange nirgendwo angeschlossen.

- - - Aktualisiert - - -

Ich fühle mich fast versucht zu schreiben, daß es jemand auch nicht anders verdient hat, wenn er (offenbar ohne eigenes Nachdenken, denn dann hättest Du selbst darauf kommen können) einem 10 Jahre alten Beitrag folgt, um einem viel jüngeren Gerät (die 3490 gibt es nicht einmal zwei Jahre) auf die Sprünge zu helfen.

Solltest Du irgendein iOS-Gerät Dein Eigen nennen, habe ich eine weitere schlechte Nachricht für Dich: Die Anleitungen zum Jailbreak für iOS 4 funktionieren bei aktuellen Geräten auch nicht mehr.

Wenn Du weiterhin Interesse daran haben solltest, das Gerät vielleicht doch noch einmal zum Leben zu erwecken, dann solltest Du demnächst bei solchen "Lesereisen" auch mal einen Blick auf das Datum werfen.

Ansonsten kann man eigentlich bei der 3490 aus dem Bootloader heraus den (NAND-)Flash gar nicht sinnvoll beschreiben lassen ... vielleicht schaffst Du es ja doch einmal, die Vorgehensweise detailliert(!) zu beschreiben, damit man mal eine Idee entwickeln kann, was da passiert ist.

Wenn die Box jedoch tatsächlich bereits als defekt verkauft wurde, ist wohl irgendetwas an der Hardware auch wirklich defekt und die Box stolpert im Verlauf des Bootvorgangs darüber. Das wäre dann von außen schlecht festzustellen, dann braucht es etwas Löterfahrung und ein serielles Kabel (mit Pegelwandler für 3.3V-TTL) für dem Zugang zur seriellen Schnittstelle.

- - - Aktualisiert - - -

Jetzt braucht es dann wirklich erst einmal das komplette Environment ... zum Auslesen kannst Du das "eva_get_environment" aus meinem YourFritz-Repository (Subdir eva_tools) benutzen (der Link zu einem parallel dazu liegenden Repo steht weiter oben).

DerDerDon schrieb:

ftp 169.254.173.1 funktioniert.

Zum Vergrößern anklicken....

Dafür wollte ich dich eigentlich schon beglückwünschen (wobei ich mich auch gerade Frage wie du auf "169.254.173.1" gekommen bist, eigentlich lautet die Standard-IP für den Bootloader 192.168.178.1, es sei denn im Bootloader-Environment ist tatsächlich was anderes als 192.168.178.1 als IP-Adresse für den Bootloader eingestellt aber alles im Bereich 169.254.0.0/16 gehört ja noch zum Zeroconf-Bereich, wusste gar nicht, dass man damit auch den Bootloader erreichen kann?), vor allem da du scheinbar auch den "richtigen" FTP-Server bzw. Gegenstelle (also den Bootloader) gefunden hast, das schafft nicht jeder Neuling gleich beim ersten mal.
Auch einige länger aktive IPPF-Mitglieder scheinen mitunter an dieser (eigentlich nicht schweren wenn man einmal weiß wie es funktioniert) Aufgabe schon zu scheitern.

Aber dann:

DerDerDon schrieb:

seufz.
[...]
put kernel.image “kernel.image mtd1“ gab Fehlermeldung
[...]
Jetzt gehen nicht mal mehr die LEDs an.

Zum Vergrößern anklicken....

Ja, seufz... Dieses Vorgehen haben wir dir hier nicht nahegelegt, es hat übrigens schon einen Grund,

DerDerDon schrieb:

RuKernel unterstützt ja leider keine 3490?

Zum Vergrößern anklicken....

dass das ruKernelTool die 3490 nicht unterstützt, das ruKernelTool macht nämlich auch nichts anderes als das was du da mit "put kernel.image ..." probiert hast (zusätzlich löscht es optional auch noch das TFFS) aber das funktioniert so bei den neueren NAND-Modellen wie der 3490 eben nicht. Ich kann nur hoffen, dass du mit dieser suboptimalen Aktion den Bootloader nicht überschrieben hast (aber das war ja mtd2 und nicht mtd1 aus Sicht des Bootloader oder Peter?), das wäre es dann nämlich tatsächlich gewesen für die 3490...


Ich habe irgendwie den Verdacht, dass da der Vorbesitzer der 3490 evtl. ebenfalls etwas planlos an der 3490 "herumgefummelt" hat (vielleicht auch noch vor dem ersten Firmwareupdate sodass eben noch nicht einmal die Variable linux_fs_start gesetzt wurde), vielleicht wollte er ja z.B. aus einer deutschen 3490 eine internationale 3490 machen und hat dazu lediglich die Variable "firmware_version" von avm auf avme oder sonst was abgeändert... Wenn so etwas z.B. der Fall gewesen sein sollte (deshalb hatte ich in #3 auch nach der Variable gefragt bevor man irgendwelche weiteren Aktionen empfiehlt) hätte es u.U. gereicht wieder die korrekte Branding-Variable zu setzen (z.B. avm anstatt avme), ganz ohne Recovery bzw. den Versuch die bestehende Firmware zu überschreiben.

Also wie Peter schon geschrieben hat, nun wäre tatsächlich erst einmal das gesamte Bootloader-Environment von Interesse bevor du noch irgendwas anderes unbedachtes/unüberlegtes mit der 3490 machst, vorausgesetzt natürlich du hast mit der Aktion vorhin den Bootloader nicht ins Jenseits befördert...

Ja, der Bootloader steht in MTD2 ... wobei ich mir bei der Definition der MTD-Grenzen im Environment (aus der 7490, müßte bei der 3490 aber ähnlich sein):
gar nicht mehr so sicher bin, ob da nicht tatsächlich der Bootloader (mtd2 liegt ja innerhalb von mtd1 nach der o.a. Definition) gelöscht wurde.

Das beschriebene "Hängen" beim "put"-Kommando hört sich nach dem Löschen des alten Inhalts (flash erase) bei der Ausführung des STOR an, bevor dann die FTP-Übertragung des neuen Inhalts auch wirklich startet ... wenn dabei abgebrochen wurde (auch wenn nicht, würde wohl kaum ein gepackter Linux-Kernel einen Bootloader ersetzen können), dann werden wohl die ersten 256 KB des SPI anstelle des Bootloaders nun nur noch lauter Einsen enthalten. Hier hilft dann nur noch JTAG - und man braucht natürlich erst einmal irgendetwas, was man ins SPI-Flash schreiben will.

Dann ist natürlich da auch kein Environment oder gar ein FTP-Server mehr ... da ich nie auf die Idee kommen würde, da einfach mal irgendwas zu schreiben, war es mir gar nicht so richtig bewußt, daß die MTD1-Definition die MTD2-Grenzen so überlappt, daß ein Löschen (im Rahmen eines STOR) dort tatsächlich den Bootloader killen kann. Das wäre bei MTD5 dann ja auch so.

DerDerDon schrieb:

Eigentlich habe ich nur gelesen - schreibend habe nichts anderes getan als
put kernel.image mtd1
und als das hing habe ich es abgebrochen. Vielleicht hätte ich mehr als 2-3 Minuten warten sollen.

Zum Vergrößern anklicken....

Das "put kernel.image mtd1" mündet dann aber in ein "STOR mtd1" auf der Box und da es sich dort (angeblich) um Flash-Speicher handelt, wird der eben vor dem Neuprogrammieren erst einmal gelöscht.

Das dauert schon mal ein wenig ... und das ist vermutlich auch die Pause, die Du bemerkt hast. Aber auch das Warten hätte nicht wirklich geholfen, denn "kernel.image" ist nun mal kein Bootloader-Code und ab Adresse 0 im SPI-Flash steht erst einmal der Bootloader.

Warum da MTD1 auch an Adresse 0x0 beginnt und somit ein Schreibversuch für diese Partition den Bootloader löschen könnte, weiß ich auch nicht ... ich hätte zumindest eine Plausibilitätsprüfung erwartet und die Größenangabe bei MTD1 (0x400000 = 4 MB) paßt eigentlich nicht zur Größe des tatsächlich installieren SPI-Flashs (steht auch in "flashsize" und sollte "1024KB" lauten).

Wenn da tatsächlich mit dem Löschen begonnen wurde, ist das zumindest etwas komisch in meinen Augen ... aber das ist ja auch kein GUI, wo der Benutzer tatsächlich zugreifen müßte und angesichts der Daten in der 7490 halte ich das Löschen des gesamten SPI tatsächlich für plausibel ... auch wenn ich gar nicht genau weiß, ob der Bootloader das tatsächlich so machen würde. Zwar kann der bekanntermaßen auch über den FTP-Service neu geschrieben werden, aber daß es wirklich in dieser Form "auf einen Schlag" geht, hätte ich so nicht unbedingt erwartet.

DerDerDon schrieb:

... irgendwas beim Update soll schiefgelaufen sein.

Zum Vergrößern anklicken....

Hmmm, die Geschichte des Verkäufers kann ich so irgendwie nicht richtig glauben/nachvollziehen... Das hätte ja das erste Firmware-Update sein müssen (da die Variable linux_fs_start noch fehlte) und während eines solchen Firmwareupdate werden ja erst einmal nur die beiden sekundären (bis dahin nicht benutzten) Partitionen beschrieben und erst wenn das erfolgreich abgeschlossen ist wird dann mit Hilfe der Variable linux_fs_start auf die neue Firmware bzw. die anderen Partitionen beim booten gewechselt.
Soweit kann es aber ganz offensichtlich noch nicht/nie gekommen sein, zudem würde die FritzBox, auch wenn was beim Update schiefgelaufen ist und somit die Variable "linux_fs_start" nicht angelegt wurde, in so einem Fall ganz normal weiterhin mit der alten Firmware starten und funktionieren.

Irgendwie finde ich da z.B. meine Variante aus Beitrag #8 etwas realistischer.

Und selbst wenn die Erklärung des Verkäufers richtig gewesen sein soll, warum wurde die FritzBox dann nicht reklamiert?

DerDerDon schrieb:

Eigentlich habe ich nur gelesen - schreibend habe nichts anderes getan als
put kernel.image mtd1

Zum Vergrößern anklicken....

Tja, und das war dann schon das Fatale wenn man mal annimmt, dass sich das so abgespielt hat wie in Beitrag #9 und #11 erläutert.*

DerDerDon schrieb:

Die IP 169.254.173.1 hatte übrigens die die Recovery angezeigt.

Zum Vergrößern anklicken....

Gerade mal probiert und dem Netzwerkadapter keine feste IPv4-Adresse gegeben, die Verbindung funktioniert tatsächlich mit beliebigen Adressen (aus dem Zeroconf-Bereich), der Bootloader der FritzBox reagiert auf alle Anfragen. Aber 169.254.173.1 (was das Recovery angezeigt hat) ist dann nur so etwas wie ein "Zufallswert". Das eigentlich in der Anleitung beschriebene Vorgehen wäre gewesen dem Netzwerkadapter des PC eine IP-Adresse aus dem Bereich 192.168.178.0/24 zu geben (ausgenommen natürlich 192.168.178.1, also z.B. 192.168.178.2 anstatt DHCP) und den Bootloader der FritzBox per "ftp 192.168.178.1" zu erreichen.

DerDerDon schrieb:

Oder das wäre dann die erste von einem knappen Duzend Boxen, die ich final in den Himmel befördert hätte.

Zum Vergrößern anklicken....

Letztlich läuft es wohl darauf hinaus denn selbst wenn man per JTAG den SPI-FLash beschreiben könnte bräuchte man ja was womit man ihn beschreiben kann. Der eingesetzte Bootloader (incl. Environment) ist in gewissen Teilen Boxspezifisch und nicht universell, also auch eine andere 3490 als Quelle für einen funktionierenden Bootloader funktioniert nicht so einfach.

edit
Ach guck an, Peter hat ja erst vor kurzen was dazu geschrieben:
[post]2166098[/post]

Und dort ist auch folgender Link zu finden:
http://freetz.org/wiki/help/howtos/development/adam2



*)
Wenn das tatsächlich so ist wundere ich mich aber dennoch, dass das hier wohl der erste Fall sein soll (von dem man zumindest hier im IPPF lesen kann) wo jemand seinen Bootloader damit vernichtet hat. Das hätte doch m.E. schon eher mal passieren müssen da es ja vermutlich immer mal wieder welche gibt die veraltete Anleitungen ohne weitere Recherche/Gedanken auch auf neue Produkte anwenden.
Oder ist der FTP-Modus des Bootloader für viele doch ein solch großes Hindernis?

qwertz.asdfgh schrieb:

Wenn das tatsächlich so ist wundere ich mich aber dennoch, dass das hier wohl der erste Fall sein soll (von dem man zumindest hier im IPPF lesen kann) wo jemand seinen Bootloader damit vernichtet hat. Das hätte doch m.E. schon eher mal passieren müssen da es ja vermutlich immer mal wieder welche gibt die veraltete Anleitungen ohne weitere Recherche/Gedanken auch auf neue Produkte anwenden.

Zum Vergrößern anklicken....

Ich denke mal, viele alte Anleitungen beziehen sich auch auf das ruKernelTool und das weigert sich ja bei den NAND-Boxen, irgendetwas zu flashen (soweit ich weiß jedenfalls).

Vielleicht kann man ja den nächsten mit einer Box, der nicht mehr zu helfen ist (meinetwegen bei kaputtem Xilinx-SoC), mal zur "Exekution sehenden Auges" überreden ... im Moment ist es mir zu schade, eine 7490 zu riskieren - dir Frage steht aber auf dem Zettel, ob man über den Bootloader nicht nur die Box unbemerkt kapern kann, sondern auch "töten".

BTW ... kennt eigentlich irgendjemand eine Quelle für ein BDSL-File für den VR9?