Dann hat wohl doch der Prozessor (die Schnittstelle ist auf dessen Die) einen Schuß.
Wenn Du nicht nur löten kannst, sondern Dich auch mit Linux einigermaßen auskennst (Deine bisherigen Aktionen waren ja eher durch mangelnde Fakten über die Boxen belastet), dann kannst Du zumindest mal vor dem Auslöten irgendeines Flash-Chips testen, ob der tatsächlich defekt ist. Dazu müßte man nur ein passendes Image bauen (das geht auch ohne große Compiler-Installationen ... und es gibt Beispiele) und die Box von diesem booten (das funktioniert ja augenscheinlich noch - das Recovery-Programm macht auch nichts anderes) - dann kann man sich die Inhalte der Flash-Partitionen z.B. über TFTP von der Box aus irgendwohin schreiben lassen und wenn diese stimmen, kann man die Idee mit dem defekten Flash auch gleich wieder vergessen.
Der Kern des Problems ist hier m.E. immer noch die Schnittstelle ... und die Tatsache, daß der Bootloader eben gar nicht erst versucht, ein System zu laden. Daß das dann über FTP trotzdem noch funktioniert, liegt nur daran, daß es verschiedene "Eingabekanäle" sind, auf denen ein "Kommando" bereitgestellt wird (seriell und per FTP - und beide haben keineswegs einen identischen Funktionsumfang) und das Speichern eines Systems ins RAM direkt im Anschluß auch den Start dieses hochgeladenen Systems auslöst - da wird dann der (Eingabe-)Zustand der seriellen Schnittstelle einfach ignoriert.
Was man auch noch machen könnte ... sich einfach mal direkt in den Datenstrom auf der seriellen Schnittstelle einklinken (und nicht mit
putty
) und die Rohdaten ansehen. Ein Terminalprogramm ignoriert auch bestimmte Zeichen bzw. behandelt sie gesondert und ist teilweise auch für das (lokale) "Echo" der eingegebenen Zeichen zuständig - vielleicht sieht man im "raw data stream" noch irgendwelche anderen Zeichen, dann wüßte man wenigstens, daß solche Zeichen vorhanden sind und die Schnittstelle ggf. der Ansicht ist, da lägen Daten vor - was wieder die Unterbrechung des Bootvorgangs erklären könnte, denn - wie bereits bemerkt - Eingaben auf der seriellen Schnittstelle (und seien es "eingebildete") unterbrechen den automatischen Start (wie übrigens auch ein
autoload no
im Environment) und nach Deinen Berichten verhält sich Deine Box ja eigentlich auch exakt so.
Denn - wie auch schon zuvor angeführt - ein zumindest versuchter Start aus dem NAND-Flash sollte weitere Ausgaben hervorrufen. Das würde ein Drücken der Return-Taste zwar auch machen (dann kommt noch einmal der Prompt) - aber andere (Phantom-)Zeichen müssen da nicht zwangsläufig eine Ausgabe hervorrufen (insb. weiß ich nicht, was die Kombination aus EVA und Terminalprogramm PuTTY bei Eingabe von NUL-Zeichen am Ende anzeigen würde) und so sieht das bisher nun mal bei Dir aus.
Wobei ich:
Selbst wenn ich den Bootloader manuel über ein falsches Recover oder das Script aufhalte ergibt sich keine Änderung
ohnehin nicht verstehe ... da Dein Bootloader (dem Protokoll "ohne Recovery" nach zu urteilen) gar nicht mit dem Laden des Systems aus dem Flash beginnt (wobei zuvor bei einer funktionierenden Box noch eine Gedenkpause von ca. 5-10 Sekunden eingelegt würde, in der man dann per FTP Kontakt aufnehmen kann), KANNST Du den auch gar nicht selbst anhalten (weder mit dem Recovery-Programm, noch mit einer Dritt-Software) ... der hält sich tatsächlich selbst an und kommt nur dann über diesen Punkt hinweg, wenn man ihm ein System per FTP in den Speicher schreibt. Der besondere Aufbau dieses Schreibkommandos (
STOR from to
) signalisiert dann auch gleich noch, was nach diesem Upload erfolgen soll - ein spezielles "Kommando", mit dem man den Bootloader zum Start eines Systems auf dem Flash-Speicher veranlassen könnte (wie das
go
auf der Console) gibt es nämlich gar nicht.
Egal was Du jetzt auch machst ... solange Du die serielle Schnittstelle nicht zum "normalen" Funktionieren bringst, wird es Dir eher nichts helfen, irgendwelche anderen Chips auf dem PCB zu tauschen - der Bootloader würde (zumindest nach meiner Ansicht, die auf meinen Erfahrungen fußt) auch dann noch stehenbleiben. Damit kann man die Box vermutlich immer noch benutzen, wenn man sie jedesmal aus dem RAM startet - aber das ist erstens aufwändig und schränkt zweitens den verfügbaren Hauptspeicher auch noch ein (weil das Filesystem ja irgendwo gespeichert sein muß).
Wenn Du jetzt schon die Kabel getauscht hast und das immer noch keinen Fortschritt ergab ... hast Du denn mal einen anderen RS232-USB-Adapter verwendet? Nach Deinen Ausführungen verwendest Du ja auch einen FT232 und von irgendwelchen Kreuztests, bei denen genau dieser Adapter dann auch funktioniert hat (möglichst auch noch mit den 3,3 V-Pegeln), hast Du bisher auch noch nichts geschrieben (wenn ich es nicht überlesen habe). Wobei das auch wieder keine Erklärung für beide Probleme (keine Eingabe möglich, trotzdem bleibt der Loader stehen) wäre - zumindest keine, die ins Auge springt. Es sei denn, der Adapter produziert einen ständigen Datenstrom auf seiner Sendeleitung, der dann von der FRITZ!Box fehlinterpretiert wird. Das erscheint mir aber auch etwas zu weit hergeholt ... nur bieten sich eben - außer einen Defekt im SoC, was dann sicherlich das Ende der Mission bedeuten würde - keine anderen Erklärungen an.