7490 bootet nicht, Power/DSL blinkt

Winter49

Neuer User
Mitglied seit
10 Dez 2010
Beiträge
8
Punkte für Reaktionen
0
Punkte
1
Hallo Zusammen,

Ich habe eine Fritzbox mit folgendem Problem:
Die FritzBox bootet nicht, Recovery läuft angeblich erfolgreich durch, aber kein Erfolg, Bei Flash von MTD3 u 4 leuchtet kurz die rote LED auf.

Was ich bisher feststellen konnte:
Die Box läuft direkt in den Bootloader, ich kann mich direkt per ftp auf die Box aufschalten.
Manueller Flash über den FTP funktioniert auch nicht, "425 Can't Open Data Connection" bei dem Windows ftp
NCFTP sendet die Datei meldet aber dann eine Fehlermeldung
Gleichzeitig ist das Serielle Interface der FB angeschlossen. Dort werden beim flashen 0x0 Fehler gemeldet (mit den entsprechenden Speicheradressen)
Im seriellen Log kann ich aber sehen das der Flashbaustein erkannt wird.

Dazu dann meine Fragen:
Ich gehe hoffentlich richtig davon aus das dei Kernel.image auf mtd0 und der Filesystem.image auf die mtd1 Partition kopiert werden muss?
Diese Partitionen sollten dann ja auf dem NAND liegen

So wie ich das schätze ist der NAND Flashbaustein defekt?

Ich weiß das Aufwand und Kosten in keiner Relation stehen, ich sehe das als Bastelobjekt.

Theoretisch könnte ich den NAND auslöten und versuchen per EEPROMer auszulesen\ zu testen, vielleicht hat ja jemand noch ein paat Tipps für mich.

Vielen Dank im Voraus

MFG Winter49
 
Manueller Flash über den FTP funktioniert auch nicht, "425 Can't Open Data Connection" bei dem Windows ftp
NCFTP sendet die Datei meldet aber dann eine Fehlermeldung
Direkt flashen per Bootloader und FTP geht auch gar nicht bei einer 7490. Nur indirekt über den Umweg RAM. Also was genau hast du versucht zu machen? Terminal-Logs wären da bspw. ganz hilfreich/interessant...

Im seriellen Log kann ich aber sehen das der Flashbaustein erkannt wird.
Welcher? Die 7490 hat ja 2, einmal NOR-Flash und einmal NAND-Flash. Wenn der NAND-Flash bspw. nicht gefunden wird, kann die Box nicht starten denn da sind normalerweise die Kernel und FS zu finden. Der Bootloader und TFFS ist dagegen im NOR-Flash.

Ich gehe hoffentlich richtig davon aus das dei Kernel.image auf mtd0 und der Filesystem.image auf die mtd1 Partition kopiert werden muss?
Nein, das ist falsch! Sogar ganz falsch! Wenn man das macht, besteht (vermutlich bei einigen Bootloader-Versionen) sogar die Gefahr, den Bootloader zu überschreiben. Einige haben das schon geschafft, weil sie meinten uralte Anleitungen für ältere Fritzbox-Modelle bspw. auch für die neuere 7490 anwenden zu können...

Diese Partitionen sollten dann ja auf dem NAND liegen
Nein, das ist nicht er Fall! Wie kommst du darauf?
 
Zuletzt bearbeitet:
Hallo,

danke für die Rückmeldung. Ich habe versucht mich über die unzähligen Anleitungen schlau zu lesen was anscheinend nicht so ganz geklappt hat.

Direkt flashen per Bootloader und FTP geht auch gar nicht bei einer 7490. Nur indirekt über den Umweg RAM. Also was genau hast du versucht zu machen? Terminal-Logs wären da bspw. ganz hilfreich/interessant...
Ich hatte versucht per quote MEDIA FLSH die Partitionen direkt zu schreiben. Was dann ja anscheinend (Gott sei Dank) nicht geklappt hat.
Wie muss ich denn richtig vorgehen? Logs könnte ich nur über Reproduktion der falschen Schritte darstellen.
Welcher? Die 7490 hat ja 2, einmal einmal NOR-Flash und einmal NAND-Flash. Wenn der NAND-Flash bspw. nicht gefunden wird, kann die Box nicht starten denn da sind normalerweise die Kernel und FS zu finden. Der Bootloader und TFFS ist dagegen im NOR-Flash.
Beide Flashbausteine werden erkannt: Der Bootloader (per FTP läuft die FB ja noch) geht anscheinend noch. Oder wird dieser im Ur-Lader schon zur Verfügung gestellt. Im Seriellen Log wird mir zudem der MT29F4G08 aufgelistet.
Nein, das ist falsch! Sogar ganz falsch! Wenn man das macht, besteht (vermutlich bei einigen Bootloader-Versionen) sogar die Gefahr, den Bootloader zu überschreiben. Einige haben das schon geschafft, weil sie meinten uralte Anleitungen für ältere Fritzbox-Modelle bspw. auch für die neuere 7490 anwenden zu können...

In Unzähligen Anleitungen wird mir folgende Partitionstabelle angegeben:
mtd0: "kernel"
mtd1: "filesystem"
mtd2: "reserved-kernel"
mtd3: "reserved-filesystem"
mtd4: "config"
mtd5: "nand-filesystem"
mtd6: "urlader"
mtd7: "tffs (1)"
mtd8: "tffs (2)"

Das kommt ja dann überhaupt nicht hin, oder?


Nein, das ist nicht er Fall! Wie kommst du darauf?

Das SPI ROM ist ja laut meinen Informationen nur 8MB groß, da passen die Daten schlichtweg nicht drauf.

Ich befürchte das ich teilweise gefährlichem Halbwissen "zum Opfer" gefallen bin, kannst du mich ein wenig aufklären?

MFG Winter49
 
wird mir folgende Partitionstabelle angegeben
Da sollte dann aber auch jeweils dabei stehen, daß das die Aufteilung des Flash-Speichers unter dem laufenden FRITZ!OS ist. Die Sicht des Bootloaders auf den Flash-Speicher sieht vollkommen anders aus, wie man leicht an den Größen der dort definierten mtdX-Werte errechnen kann. Dort ist auch mtd2 der Bootloader - das ist eine "Zieladresse", die man in jedem Falle vermeiden sollte (wenn, dann fummelt man an dieser Partition vom FRITZ!OS aus herum, weil die dann garantiert nicht "in use" ist - aber auch das sollte man nur machen, wenn man WIRKLICH genau weiß, was man da tut).

Die jeweiligen Definitionen der Partitionen sehen (bei der 7490 und EINIGEN (aber nicht ALLEN) anderen Boxen) so aus:
Rich (BBCode):
/var # cat /proc/mtd
dev:    size   erasesize  name
mtd0: 00400000 00020000 "kernel"
mtd1: 03000000 00020000 "filesystem"
mtd2: 00400000 00020000 "reserved-kernel"
mtd3: 03000000 00020000 "reserved-filesystem"
mtd4: 00200000 00020000 "config"
mtd5: 19600000 00020000 "nand-filesystem"
mtd6: 00040000 00001000 "urlader"
mtd7: 00060000 00001000 "tffs (1)"
mtd8: 00060000 00001000 "tffs (2)"
/var # cat /proc/sys/urlader/environment
HWRevision      185
HWSubRevision   3
ProductID       Fritz_Box_HW185
SerialNumber    0000000000000000
annex   B
[...]
mtd0    0x400000,0x3400000
mtd1    0x0,0x400000
mtd2    0x0,0x40000
mtd3    0x40000,0xA0000
mtd4    0xA0000,0x100000
mtd5    0x0,0x200000
/var #
Schon die Anzahl stimmt also nicht überein und wenn man sich die Größenangaben ausrechnet (bei der Bootloadersicht ist das jeweils Start- und Endeadresse) und das entsprechend vergleicht, stellt man fest, daß mtd6 bis mtd8 aus Sicht des FRITZ!OS den Definitionen für mtd2 bis mtd4 aus EVA-Sicht entsprechen und auch deren (summierte) Größe von 1 MB zum "Platzangebot" des SPI-Flashs paßt ... denn das sind vielleicht 8 MBit, was der bietet (=> 1 MByte), aber keine 8 MByte (wofür MB die "gebräuchliche" Einheit wäre).

Wie man eine solche Box flashen kann (entweder mit dem AVM-Programm oder auch mit anderer Software) ist hier vielfach beschrieben (am besten sortiert man die Ergebnisse dann nach absteigender Aktualität, dann kommt man bei alten und nicht mehr funktionierenden Beiträgen erst sehr spät an) - ggf. auch eher in einem anderen Unterforum: https://www.ip-phone-forum.de/forums/fritz-box-fon-modifikationen.444/

Wobei mich die Sätze:
Die FritzBox bootet nicht, Recovery läuft angeblich erfolgreich durch, aber kein Erfolg, Bei Flash von MTD3 u 4 leuchtet kurz die rote LED auf.
schon irritieren ... bezieht sich das alles auf einen einzelnen Versuch mit dem Recovery-Programm? Ich habe eigentlich noch nie gesehen, daß bei einer 7490 beim Flashen irgendeiner Partition über das Recovery-Programm (und die "Nähe" von "Recovery" und den Bemerkungen zur LED legen hier ja einen Zusammenhang nahe) die LEDs irgendwelche zusätzlichen Signale liefern (vielleicht wäre das bei einem Hardware-Schaden aber schon der Fall und daher will ich es nicht ausschließen - einen solchen haben nur die Wenigsten und ihn zu simulieren ist noch schwerer).

Ansonsten solltest Du erst mal lesen, wie man das Recovery-Programm RICHTIG benutzt (hier vermute ich tatsächlich, daß Du die Box einfach nur im falschen Moment neu startest) und welche Fallstricke man dabei vermeiden sollte. Solange der Bootloader (den man auch schon mal "Urlader" nennt - das ist dann aber dieselbe Software, die bei AVM auch "EVA" heißt) funktioniert, wird auch das Recovery-Programm i.d.R. klarkommen (was es ja nach #1 bei Dir auch machen soll) - zumindest sollte man dann erst mal dessen Protokolle kontrollieren. Den Thread zur Benutzung des Recovery-Programms findest Du dann tatsächlich in diesem Unterforum: https://www.ip-phone-forum.de/threads/wie-recovere-ich-eigentlich-richtig.299790/ - allerdings ist der nicht angepinnt, was ich auch nicht so richtig auf dem Schirm hatte und obendrein ist der ursprüngliche Start des Threads (den ich dann immer mal wieder erweitert habe) auch schon etwas länger her.
 
Danke erst mal das Ihr euch die Mühe macht mir zu helfen.

Was die Partitionen betrifft war ich ja schon mal komplett auf dem Holzweg. Danke für die Info, da hätte ich auch selber drauf kommen können das der Platz gar nicht ausreichen kann...



Die roten LED werden mir im Laufe des Recovery angezeigt wenn MTD3 und 4 gelöscht und neu beschrieben werden. Das Serielle interface gibt zu dem Zeitpunkt leider keine Infos aus

FRITZ!Box 7490 suchen an: 192.168.178.1
Eine Anlage gefunden! - Ermitteln der aktuellen Version.
Version erfolgreich ermittelt!
Hardware: FRITZ!Box 7490
Urlader: 1964
Firmware: recovered=2
Flashbereich (mtd3)
Lösche Flashbereich (mtd3) <- rote LED
Restauriere Flashbereich (mtd3)
Flashbereich (mtd4)
Lösche Flashbereich (mtd4) <- rote LED
Restauriere Flashbereich (mtd4)
Restauriere Flashbereich (mtd1)
FRITZ!Box 7490 erfolgreich wiederhergestellt!
Die Wiederherstellung ist nach einem Neustart des Gerätes abgeschlossen.

Ich hatte das Recovery Programm schon mehrfach verwenden müssen, auch bei anderen FB Typen. Da hatte ich das Problem nie. Gerne kann ich den Vorgang auch filmen. Dein Hinweis ist nett gemeint aber ich denke das beim Recovern der FB mit dem Original Tool der Faktor Mensch nicht das Problem ist. Firewall usw ist deaktiviert, selbst mir einem alten XP Rechner das gleiche Ergebnis, neu gestartet wird so wie es das Programm verlangt.

Zum Verständnis habe ich die beiden seriellen Logs und die FTP logs des Recovery angehängt. Letztendlich kann ich Diese mangels Erfahrung nicht interpretieren. Bei Boot ohne Recovery wird die FB einfach nur mit Strom versorgt.



Was benötigt die FB denn SW-seitig um booten zu können?

Bootloader ist klar: Kann ich heraus bekommen ob der "verbastelt" wurde?
Dann natürlich Kernel und Filesystem.. Da scheine ich ja nicht mal hin zu kommen.

Habt Ihr noch Ideen? Parallel werde ich mich erst mal in das richtige Flashen der 7490 einlesen

MFG Winter49
 

Anhänge

  • Boot ohne Recovery.txt
    434 Bytes · Aufrufe: 17
  • Boot mit Recovery.txt
    17.4 KB · Aufrufe: 9
  • ftp.txt
    6.7 KB · Aufrufe: 8
  • environment_19.txt
    1.5 KB · Aufrufe: 11
Zuletzt bearbeitet:
lösche deine env, oder mach mac´s, wlan keys unkenntlich.
 
@Winter49:
Schon die Frage, warum die Box - wenn man kein Recovery-Programm verwendet - einfach in EVA stehen bleiben sollte (nach dem Protokoll), ist hier interessant.

Starte mal bitte die Box ohne Recovery-Programm, gib in der Console ein printenv ein und danach ein go. Ersteres soll die aktuellen Einstellungen anzeigen und das zweite versucht dann, einen Kernel aus einer passenden Partition (welche das ist, ergibt sich aus den aktuellen Einstellungen) zu laden und zwar einen mit einem bestimmten Format.

Bei den Vorbereitungen zum Entpacken des Kernels sollten erst zwei Rauten ausgegeben werden und dann beim Entpacken sich die Reihe von Punkten (die man auch beim Start mit Recovery sieht, direkt vor der ersten Kernel-Message) aufbauen. Funktioniert das mit den aktuellen Einstellungen nicht, das Ganze noch einmal mit dem alternativen Wert für linux_fs_start wiederholen - den kann man auch mit SETENV über die serielle Console in EVA ändern (das braucht also nicht zwingend FTP). Dabei aber bitte immer sauber mitprotokollieren, was man da macht und welches Ergebnis (am besten in Form eines Protokolls) das zeitigt.

Es geht erst einmal um eine Bestandsaufnahme und die Klärung der Frage, warum die Box (und zwar auch ohne weitere Fehlermeldungen, nach dem Protokoll zu urteilen) nicht versucht, den Kernel zu laden. Bei der Gelegenheit kannst Du dann auch gleich mal ptest entfernen (UNSETENV ptest) - daran kann man später ggf. erkennen, ob die /sbin/flash_update auch ausgeführt wurde (und zwar bis hinter die Stelle, wo die Daten geschrieben werden).

Allerdings sieht es tatsächlich so aus, als würden da Daten geschrieben (update_kernel ist zeitweise die aktivste Task) - um so merkwürdiger, daß das beim nächsten Start dann nicht klappt mit dem Laden eines Kernels. Zumal man auch sieht (anhand der Meldungen des YAFFS2-Treibers und des cp, was danach die aktivste Task ist), daß das Flashen des Kernels abgeschlossen sein soll und auch das Dateisystem noch kopiert wird.

Theoretisch ist es denkbar, daß der NAND-Flash so kaputt ist, daß da kein Kernel mehr sauber aus einer der beiden Partitionen geladen werden kann, weil die gelesenen Daten nicht stimmen. Aber das wird ja nicht bei BEIDEN Systemen (bzw. Partition-Sets) der Fall sein und ein Fehler beim Entpacken des Kernels sollte ja zumindest ein paar der "blips" (bzw. Punkte) auf den Schirm bringen. Das überzeugt mich also auch noch nicht so richtig als Erklärung. Aber wenn das jetzt keine Erkenntnisse bringt, versuche ich mal auf einer Test-Box, wie ein Start mit einem ungültigen Kernel aussehen müßte - das Dateisystem interessiert hier noch gar nicht, das kommt erst sehr viel später überhaupt zum Einsatz.
 
Guten Morgen,

bei dem ersten Teil habe ich schon ein Problem:

@Winter49:
Schon die Frage, warum die Box - wenn man kein Recovery-Programm verwendet - einfach in EVA stehen bleiben sollte (nach dem Protokoll), ist hier interessant.

Starte mal bitte die Box ohne Recovery-Programm, gib in der Console ein printenv ein und danach ein go. Ersteres soll die aktuellen Einstellungen anzeigen und das zweite versucht dann, einen Kernel aus einer passenden Partition (welche das ist, ergibt sich aus den aktuellen Einstellungen) zu laden und zwar einen mit einem bestimmten Format.

Bei den Vorbereitungen zum Entpacken des Kernels sollten erst zwei Rauten ausgegeben werden und dann beim Entpacken sich die Reihe von Punkten (die man auch beim Start mit Recovery sieht, direkt vor der ersten Kernel-Message) aufbauen. Funktioniert das mit den aktuellen Einstellungen nicht, das Ganze noch einmal mit dem alternativen Wert für linux_fs_start wiederholen - den kann man auch mit SETENV über die serielle Console in EVA ändern (das braucht also nicht zwingend FTP). Dabei aber bitte immer sauber mitprotokollieren, was man da macht und welches Ergebnis (am besten in Form eines Protokolls) das zeitigt.
Ich verbinde mich mit putty auf die serielle Schnittstelle, kann da aber keine Eingaben machen. Ein anderes Programm zur Ansteuerung der seriellen Konsole hat das identische Problem.
Was nutzt du denn? die mittleren Pins sind bei mir mit RX TX und Masse belegt. VC lasse ich weg



Es geht erst einmal um eine Bestandsaufnahme und die Klärung der Frage, warum die Box (und zwar auch ohne weitere Fehlermeldungen, nach dem Protokoll zu urteilen) nicht versucht, den Kernel zu laden. Bei der Gelegenheit kannst Du dann auch gleich mal ptest entfernen (UNSETENV ptest) - daran kann man später ggf. erkennen, ob die /sbin/flash_update auch ausgeführt wurde (und zwar bis hinter die Stelle, wo die Daten geschrieben werden).

Allerdings sieht es tatsächlich so aus, als würden da Daten geschrieben (update_kernel ist zeitweise die aktivste Task) - um so merkwürdiger, daß das beim nächsten Start dann nicht klappt mit dem Laden eines Kernels. Zumal man auch sieht (anhand der Meldungen des YAFFS2-Treibers und des cp, was danach die aktivste Task ist), daß das Flashen des Kernels abgeschlossen sein soll und auch das Dateisystem noch kopiert wird.
Das werde ich heute Nachmittag testen. Die Befehle lassen sich ja per FTP eingeben?
Theoretisch ist es denkbar, daß der NAND-Flash so kaputt ist, daß da kein Kernel mehr sauber aus einer der beiden Partitionen geladen werden kann, weil die gelesenen Daten nicht stimmen. Aber das wird ja nicht bei BEIDEN Systemen (bzw. Partition-Sets) der Fall sein und ein Fehler beim Entpacken des Kernels sollte ja zumindest ein paar der "blips" (bzw. Punkte) auf den Schirm bringen. Das überzeugt mich also auch noch nicht so richtig als Erklärung. Aber wenn das jetzt keine Erkenntnisse bringt, versuche ich mal auf einer Test-Box, wie ein Start mit einem ungültigen Kernel aussehen müßte - das Dateisystem interessiert hier noch gar nicht, das kommt erst sehr viel später überhaupt zum Einsatz.
Ich habe mir zum Einen einen neuen NAND speicher, sowie einen Adapter um das NAND in meinen EEPROM Brenner zu packen. Bis das ankommt wird aber noch Zeit vergehen.
 
Irgendwo hier gibt es Bilder von mir, wo man auch die Verkabelung für den RS232-USB-Adapter erkennen sollte - außerdem gibt es mehrere andere Quellen im Netz, wie das aussehen sollte.

Ich würde mir also erst einmal eine funktionierende(!) serielle Console zulegen - ggf. sind nämlich schon falsche "Eingaben" die Ursache, warum der Bootloader einfach stehen bleibt... das würde er nach einem einfachen Return auch machen und wenn es schlecht läuft, gilt das für jedes (vermeintlich) auf der Schnittstelle ankommende Zeichen (außer vielleicht für die Flußkontrolle) ebenso.

Auch wenn Du ggf. mit einem "echten" COM-Port arbeiten solltest (wer noch XP hat, hat u.U. auch noch alte Mainboards oder auch "spezielle" Kriterien beim Kauf von neuen), muß am Ende in der Gesamtheit von Verkabelung, Terminalprogramm und Einstellungen eine Zwei-Wege-Kommunikation über den Port auf dem PCB der 7490 möglich sein.

EDIT: Hier: https://www.ip-phone-forum.de/threa...riff-auf-serielle-konsole.303107/post-2324553 ist der Link auf einen Thread mit Fotos.
 
Zuletzt bearbeitet:
Ich habe die FB genau so verkabelt Selbst der FTDI Wandler ist der gleiche. Die Pins sind fest verlötet, da gibt es auch keine Wackler. Ich kann in der Konsole generell keine Eingabe tätigen. Ich werde das gleich noch mal testen, Übertragunsrate passt, kann nur eine Einstellung sein, warum keine bidrektionale kommunikation zustande kommt.
 
Da tippe ich dann doch eher auf einen Kabelbruch o.ä. - man kann ja auch einfach mal (an beiden Enden) Rx und Tx vertauschen und schauen, ob dann immer noch die von der Box gesendeten Daten ankommen. Wobei das nicht erklärt, warum der Loader stehenbleibt ... aber auch ein dauerhafter Pegel (welcher auch immer) auf der Rx-Leitung der Box sollte jetzt eigentlich nicht als "echtes Signal" interpretiert werden, dazu sind schon Pegelwechsel erforderlich und die dürften bei einem Kabelbruch nicht auftreten.
 
Habe auf beiden Seiten das Kabel verdreht, keine Eingabe möglich. Selbst wenn ich den Bootloader manuell über ein falsches Recover oder das Script aufhalte ergibt sich keine Änderung

Edit: mit einer 7312 die gleiche Verkabelung getestet, Funktioniert! Bei der FB7490 mit einem Multimeter die Verkabelung durchgemessen. (zu den benachbarten Bauteilen) Überall entsprechend Verbindung und auch kein Kurzschluss zwischen den Pins

Gibt es eine Möglichkeit sich selber aus dem Bootloader auszusperren?
 
Zuletzt bearbeitet:
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.
 
Zuletzt bearbeitet:
Danke für deine sehr ausführlichen Erläuterungen. Was ich schon mal machen könnte wäre stur mal einen Oszilloskopen an die Leitungen zu halten ob der Prozessor überhaupt etwas wie ein Signal raus gibt. Dann wäre das ja schon Ursachenforschung auf unterster Ebene.
 
Ich habe gerade noch einmal Dein Protokoll ohne Recovery genauer angesehen ... die Zeile 4 darin enthält ja schon einige "wilde" Ausgaben, die da - wieder nur nach meiner Erfahrung - eigentlich nicht hingehören und vermutlich Reaktionen auf (undefinierte) Eingaben sind. Ähnliches kenne ich z.B. nur dann, wenn an einem RS232-Adapter auf der anderen Seite kein Terminal (oder auch kein USB-Kabel) hängt und die Pegel auf der Empfangsleitung eher willkürlich interpretiert werden.

Bei mir sieht ein Start einer 7490 (es ist auch noch dieselbe Version von EVA) etwas anders aus - das Terminal-Programm ist hier allerdings minicom unter Linux.
Code:
ROM VER: 1.1.4
CFG 05
** START
RVEC bf200000
[\]

(AVM) EVA Revision: 1.1964 Version: 2964
(C) Copyright 2005 AVM Date: Nov 27 2013 Time: 14:33:10 (1) 3 0x0-0x740D

[FLASH:] MACRONIX Uniform-Flash 1MB 256 Bytes WriteBuffer
[FLASH:](Eraseregion [0] 16 sectors a 64kB)
[NAND:] 512MB MICRON 2048 Pagesize 128k Blocksize 4096 Blocks 8Bit 1 CS HW
[SYSTEM:] VR9 on 500MHz/250MHz/250MHz

.Atheros 8030/35 detected

Eva_AVM >go
Hier startet der Bootloader auch nicht gleich durch ... das liegt aber an einer (absichtlich vorgenommenen) Einstellung von autoload no.
 
Dann befürchte ich das ich das Thema doch beerdigen muss. Schade drum. Eine 7312 mit identischer Verkabelung läuft und kann auch Seriell angesteuert werden
 
Hatte heute weil ich hier mitlese ein 7490 mit Überspannungsschaden mit serieller Konsole getestet. Bei der kommt nur was wenn die 3.3V verbunden sind - ist wohl auf dem Board der Spannungsteil defekt, die findet aber dann keine Phy's bei ca. 100 mA sicher verständlich.
 
Welche der drei Anschlussmöglichkeiten (Kontaktreihen) hast du genutzt?
 
Holen Sie sich 3CX - völlig kostenlos!
Verbinden Sie Ihr Team und Ihre Kunden Telefonie Livechat Videokonferenzen

Gehostet oder selbst-verwaltet. Für bis zu 10 Nutzer dauerhaft kostenlos. Keine Kreditkartendetails erforderlich. Ohne Risiko testen.

3CX
Für diese E-Mail-Adresse besteht bereits ein 3CX-Konto. Sie werden zum Kundenportal weitergeleitet, wo Sie sich anmelden oder Ihr Passwort zurücksetzen können, falls Sie dieses vergessen haben.