[Gelöst] 6490 ärgert mich...nicht mehr. Bootvorgang unterbrochen durch eMMC-Fehler

[adfx]

Moin zusammen,

ich hoffe ich bin hier richtig. Bin nicht so Foren erfahren, also erschlagt mich bitte nicht gleich sondern erst irgendwann später
Ich habe eine FB6490 für meine Schwägerin "günstig" kaufen wollen mit einem angegebenen Defekt (Boot Loop). Da ich gerne bastel, dachte ich mir, machste mal eben 'ne neue FW drauf. Weit gefehlt. 2 Nächte ärgert mich das Teil nun schon.
Erst mal zur Box: Es ist eine 2000 2778. Das deckt sich auch mit der von der Box gezogenen env.txt. Ich habe mit @PeterPawn Tools die environment und count sichern können. Zuletzt installierte FW ist die 07.12 laut env.txt und firmware_version ist avm. Ebenso finde ich alle auf dem Sticker des Gehäuses stehenden Angaben in der env.txt wieder. Also scheinen Platine und Gehäuse schon mal zusammen zu gehören.
Habe mit (Ubuntu) FTP und auch ncftp versucht die ATOM/ARM images auf die Box zu schieben, jedoch ohne Erfolg. Beide verweigern den PASV Mode. Irgendwann bin ich dann dahinter gestiegen eva_store_tffs zu nutzen. Das scheint zu gehen. Die INFO Led blinkt ganz fröhlich beim Übertragen und das Script und Log melden: fertig
Also damit mtd0,1,6,7 beschrieben mit den FW 06.87 / 07.12 / 07.27 und linux_fs_start sowohl 0 als auch 1 gesetzt. In keinem Fall bzw in keiner Kombination komme ich aus dem Boot Loop raus und bin absolut am Ende mit meinem Latein. Irgendwann kam mir der Gedankenblitz, dass ich wohl nicht nur eine FW raufschieben sollte, sonder die auch zur environment passen sollte. Habe also die firmware_info an die jeweilige FW angepasst per "quote SETENV firmware_info [X.Y.Z]". Aber auch das war nicht des Rätsels Lösung.
mtd11,12,13,14 sind unberührt. Was noch nie funktioniert hat, ist ein "quote reboot". Auch das eva_reboot verweigert seinen Dienst, weshalb ich bis jetzt zum Neustart also einen Kaltstart durchführen musste.
Ich hoffe einer von Euch kann mir auf die Sprünge helfen. Ich bin es gewohnt mit seriellen Konsolen zu hantieren, aber die 6490 scheint da ja sehr Stumm zu sein. Hatte in einem Thread für die 6591 etwas von "kernel_args mute=0" gelesen. Das gibt es auch in der 6490 hilft aber nicht diese zum reden bzw schreiben zu bringen. So Blind lässt sich für mich einfach kein Fehler erkennen, weshalb ich mich hiermit an Euch wende und hoffe mich kann einer in die richtige Richtung schubsen. Vielen Dank schon mal im voraus.

VG

 

[NDiIPP]

Ich hatte auch schon defekte 6490er in der Hand. Ein Fehler bzw. Defekt der mir dabei unter kam war ein defekter NAND-Flash. Die 6490 hat NOR- und NAND-Flash (letzteres als eMMC). Im NOR-Flash ist der Bootloader (inkl. Bootloader-Environment) und auch das TFFS zu finden. Daher startet der Bootloader in diesen Fällen auch und man kann per Bootloader das Environment auslesen oder auch ein neues TFFS schreiben. Aber die Firmware selbst kann so natürlich nicht geladen werden.

Aber ob das bei dir der Fall ist weiß man nicht. Es fehlen leider die Logs (mit den evtl. vorh. Fehlermeldungen) wo man genau nachvollziehen kann was versucht wurde. Und BTW, wurde auch schon versucht ein neues TFFS-Image zu erstellen und zu flashen?

 

[adfx]

Ein neues tffs Image habe ich noch nicht erstellt. Bis jetzt habe retail FW direkt von avm extrahiert und nur die jeweiligen filesystem/Kernel geflasht.
Logs kann ich gerne nachliefern. Welche werden denn benötigt?
VG

 

[PeterPawn]

Das hier:

mtd11,12,13,14 sind unberührt.

paßt nur bedingt zu dem:

Also damit mtd0,1,6,7 beschrieben mit den FW 06.87 / 07.12 / 07.27 und linux_fs_start sowohl 0 als auch 1 gesetzt.

Ich weiß nicht, ob Du diese Erläuterungen/Anleitung kennst: yourfritz.de/desc-docsis (ist nur ein Redirect auf einen Inhalt bei web.archive.org) ... aber die solltest Du (ge)lesen (haben), bevor Du weitere Aktionen unternimmst.

Denn die "Nummerierung" der Partitionen im Bootloader der Puma6-Modelle ist nicht "statisch" ... sie paßt sich an die aktuelle Einstellung von linux_fs_start an und so "verstecken" sich hinter derselben mtdX-Partition im Bootloader auch immer zwei "echte" eMMC-Partitionen - abhängig von jeweiligen Wert für linux_fs_start. Das heißt dann im Klartext: Wenn man zweimal "alle aktiven" Partitionen (mtd0/1, mtd6/7) mit neuen Daten beschreibt (einmal bei linux_fs_start 0 und einmal bei linux_fs_start 1), dann gibt es keine "unberührten" Partitionen mehr.

Welche werden denn benötigt?

Alle.

Denn das:

Was noch nie funktioniert hat, ist ein "quote reboot"

ist (wenn ich mich jetzt nicht irre) auch kein "echtes Wunder" - der Loader der 6490 war schon immer "etwas genauer", wenn es um die Groß-/Kleinschreibung von Kommandos ging und wenn Du hier mit irgendeinem FTP-Client (ich weiß nicht, was Ubuntu standardmäßig als Paket verwendet) oder NcFTP arbeitest, dann versuchen diese Clients (sofern man ihnen das nicht durch eine Parameter-Orgie austreibt) immer wieder besonders "smart" zu sein und so senden sie jede Menge zusätzliche (Server-)Kommandos an die Gegenstelle, wenn man nur irgendein simples (Client-)Kommando eingegeben hat.

Und für die Frage, warum eva_reboot nicht funktioniert (ein kleines "Zusatz-Skript", was tatsächlich nur selten zum Einsatz kommt und daher auch noch Fehler enthalten kann - es ist praktisch nur eine (ältere) Kopie eines anderen Skripts, in dem die Kommandos angepaßt wurden und ich bin nicht sicher, ob der Rest jeweils mit aktualisiert wurde, wenn eva_to_memory oder eva_store_tffs angepaßt wurden), bräuchte es dann genauso dessen Log-File - im Extremfall (wenn der Fehler im Skript vermutet wird) sogar mit passenden Optionen (-x) beim Shell-Aufruf.

angepasst per "quote SETENV firmware_info [X.Y.Z]"

Das wäre mit Kenntnis der o.a. Anleitung eher nicht passiert - daher meine Vermutung, daß Du die nicht kennen könntest (oder vielleicht nicht gründlich genug gelesen hättest). Ein explizites Setzen dieser Variablen auf die installierte FRITZ!OS-Version erfolgt durch das startenden FRITZ!OS - allerdings kann es durchaus Sinn machen, in dieser Variablen etwas anderes zu setzen, falls man (halbwegs plausibel) davon ausgehen kann, daß Fehler im ext4-Dateisystem für den NAS-Flash zum erwähnten Bootloop führen und man diese Partition (immerhin 1,5 GB groß, da kann auch ein fsck schon mal brauchen, wenn's schlecht läuft - so ein eMMC-Flash ist ohnehin nicht der flinkeste) mal formatieren lassen möchte.

Aber auch die Aussage "Bootloop" ist nicht wirklich belastbar ... irgendeine Idee, wodurch eine solche Schleife ausgelöst werden KÖNNTE, kann man logischerweise nur dann entwickeln, wenn man wenigstens eine ungefähre Vorstellung hat, wie lang diese Schleife ist, was dabei (inkl. Timings auf einer "Zeitachse") von den LEDs der Box signalisiert wird und (bei Dir sicherlich schwerer möglich, wenn die Box eine unbekannte Historie hat - aber Deine eigenen Aktionen kannst Du sicherlich noch deutlich genauer und in korrekter zeitlicher Reihenfolge beschreiben) was man bisher selbst unternommen hat.

Ich würde hier auch nicht als nächstes ein eigenes TFFS-Image erstellen und flashen - erst einmal würde ich die gelesenen Daten aus dem Environment analysieren (die Counter sind bei der 6490 ohnehin Unsinn) und wenn da nichts Unerwartetes oder Unerklärliches zu sehen ist, dann kann man mit gutem Gewissen zunächst mal von einem intakten TFFS-Inhalt ausgehen, denn der Bootloader liest diese "Rohdaten" ja auch, um die eigene Ansicht (cooked view) dieser Einstellungen zusammenzustellen.

Erst dann, wenn sich die beschriebene "Schleife" als eine herausstellt, bei der tatsächlich schon Kernel und Dateisystem geladen wurden und damit die Einstellungen für das FRITZ!OS ins Spiel kommen können (was dann den Hardware-Defekt fast schon ausschließt oder er wäre sehr umfangreich, ohne gleichzeitig alle erfolgreichen (Lese-)Zugriffe zu verhindern), dann lohnt es sich, über ein "frisches TFFS-Image" nachzudenken, wo dann die alten Einstellungen entfernt sind - auch wenn so ein "neues TFFS-Image" per se nichts schadet. Aber es bringt eine weitere "Hürde" ins Spiel (das Image muß ja erst mal erstellt werden und dazu muß man auch erst mal weiteres lesen) und eröffnet einen "Nebenkriegsschauplatz", von dem man (bisher) noch nicht weiß, ob er tatsächlich notwendig ist (gerade dann, wenn jemand das noch nicht alles kennt).

Wie geschrieben ... bitte erst einmal das Verständnis dafür entwickeln (bei Dir UND beim Leser hier, der Dir helfen will/soll), was beim Flashen passiert (ist) und dem "Problem" mit dem Neustart per FTP-Kommando nachgehen - zusätzlich noch die "Schleife" hinreichend genau beschreiben. Erst mit diesen Ergebnissen machen weitere Überlegungen dann Sinn - man zäumt ein Pferd (dem Volksmund nach jedenfalls) ja auch nicht von hinten auf.

 

[adfx]

Vielen Dank schon mal an alle für die Ratschläge und Vorgehensweise. Ich hefte Euch erst mal die Log's an, die ich noch habe und zum drüber schauen die env/count:

count.txt

reboot_major          u
reboot_minor          u
run_hours             u
run_days              u
run_mounths           u
run_years             u

env.txt

HWRevision            213
HWSubRevision         4
ProductID             Fritz_Box_HW213a
SerialNumber          0000000000000000
annex                 Kabel
autoload              yes
bootloaderVersion     1.3125
bootserport           tty0
country               049
cpufrequency          1200000000
crash                 [0]0,0,0[1]cb7359e8,5d75cbbb,1[2]0,0,0[3]0,0,0
firstfreeaddress      0x00b20000
firmware_info         141.07.12
firmware_version      avm
flashsize             nor_size=0MB sflash_size=2MB nand_size=2048MB
kernel_args           mute=0
language              de
linux_fs_start        0
maca                  C8:0E:14:AF:xx:xx
macb                  C8:0E:14:AF:xx:xx
macwlan               C8:0E:14:AF:xx:xx
macwlan2              C8:0E:14:AF:xx:xx
macdsl                C8:0E:14:AF:xx:xx
memsize               0x10000000
modetty0              38400,n,8,1,hw
modetty1              38400,n,8,1,hw
modulemem             11267314
mtd0                  0x0,0x4000000
mtd1                  0x4000000,0x4800000
mtd2                  0xa0000,0xc0000
mtd3                  0xc0000,0x100000
mtd4                  0x100000,0x140000
mtd5                  0x140000,0x1e0000
mtd6                  0x4800000,0x8800000
mtd7                  0x8800000,0x9000000
mtd8                  0x0,0x80000
mtd9                  0x80000,0x90000
mtd10                 0x90000,0xa0000
mtd11                 0x9000000,0xd000000
mtd12                 0xd000000,0xd800000
mtd13                 0xd800000,0x11800000
mtd14                 0x11800000,0x12000000
my_ipaddress          192.168.178.1
prompt                Eva_AVM
req_fullrate_freq     100000000
sysfrequency          100000000
tr069_passphrase      0xxxxxxxxxxY
tr069_serial          00040E-xxxxxxxxxx25
urlader-version       4125
usb_board_mac         C8:0E:14:xx:xx:xx
usb_device_id         0x0000
usb_device_name       USB DSL Device
usb_manufacturer_name  AVM
usb_revision_id       0x0000
usb_rndis_mac         C8:0E:14:xx:xx:xx
webgui_pass           bxxxxxxx9
wlan_key              25xxxxxxxxxxxxxxxx57

Ich werde jetzt meine Hausaufgaben machen und den von Peter geschickten Link lesen.

VG

Edit:
Ach noch eins. Kann mir denn jemand einen FTP Client empfehlen der besser geeignet ist? Vielen Dank

Und zu dem angesprochenen Zeitstrahl:
Nach Power-On:
- leuchten einmal alle LED's (GPIO initialisierung)
- blinkt die Power LED 6 mal
- Power LED leuchtet für ca 2 sek
- Power LED blinkt für ca 1min
- alles duster, außer Info LED glimmt rot

 

[PeterPawn]

Ein Problem, was mir bisher noch nie sooo aufgefallen ist, wäre das fehlende "Ausloggen" meiner (Shell-)Skripte am Ende (man sieht's in beiden Protokollen in #5).

Es gibt einige Bootloader-Versionen (welche das genau sind, weiß ich aus dem Kopf auch nicht mehr), die es gar nicht mögen, wenn man die Verbindung mit ihrem FTP-Server nicht "sauber" beendet und das ist dann eben noch ein QUIT, bevor die Verbindung geschlossen wird. Genau dieses Kommando fehlt aber in den veröffentlichten Versionen überall - ich wollte diese Dateien ja ursprünglich nur als "Demonstration" des Prinzips verstanden wissen und habe mir die Shell-Dateien gar nicht genau angesehen, als ich für die PowerShell-Files (wo ein FTP-Client schneller "zusammengezimmert" ist, als unter (*nix-)Shell-Bedingungen) das "saubere" Abmelden nachträglich implementiert habe.

Die erwähnten Bootloader-Versionen lassen dann i.d.R. keinen weiteren Verbindungsversuch zu bzw. reagieren nicht mehr auf einen solchen, bis man sie schließlich irgendwie neu startet. Vielleicht ist das auch hier ein Problem ... die Beschreibung in #1 gibt das noch nicht wirklich her, ob da der erste Zugriff jeweils funktionierte und erst der zweite (und weitere) nicht mehr - inkl. der Versuche, über den FTP-Server den Neustart auszulösen.

Die Shell-Skripte haben auch noch weitere "Unzulänglichkeiten" ... so wird z.B. bei eva_get_environment die Ausgabe von Fehlermeldungen nach STDOUT und STDERR bunt gemischt, was für ein "Pipen" dieses Handles in eine weitere Instanz auch nicht gerade förderlich ist. Auch sind die alle noch nicht "POSIX-only" (so weit wie möglich jedenfalls), denn da sind noch echo-Aufrufe drin (wo printf deutlich kompatibler wäre), die ich üblicherweise fast gar nicht mehr verwende. Die bräuchten wohl mal wieder ein "Refresh" ... andererseits haben mittlerweile schon genug Leute ihre 6490 auch mit diesen Skript-Dateien behandelt (das weiß ich auch von Feedback außerhalb des IPPF), daß die 6490 vermutlich eher nicht zu den Modellen mit dieser "Macke" im FTP-Server gehört.

Wären also noch ein "Reboot"-Protokoll und die Beschreibung des Zustands der LEDs über die gesamte Schleife abzuwarten ...

 

[adfx]

Wer lesen kann usw...
Mit einem quote REBOOT (anstelle reboot) macht die Box natürlich was sie soll. Sie bootet neu...
Der LED Zeitstrahl ist in #6 zu finden. Ist immer identisch. Egal ob ich nun von linux_fs_start 0|1 starte.
Nach einem software reboot gelingt es mir nicht in EVA zu gelangen. Das geht nur nach einem Hard reset

Edit:
Also eine echte Schleife scheint nicht vorzuliegen. Bei einer Schleife würde ich ein aufblinken aller LEDs erwarten. Dass kommt jedoch nicht. Viel mehr scheint die Box zu hängen nach dem oben beschriebenen Muster.
Mir ist es inzwischen gelungen den ncftp so zu nutzen, dass ich schreiben und lesen kann. Ebenso ist ein reboot möglich, mit aufblinken aller LEDs. Allerdings komme ich anschliessend nicht mehr in EVA. Hier hilft nur ein Hard-reset per Strom trennen.
Ich bin den von @PeterPawn angezogenen thread durch und habe exakt nach dem Muster mtd11–14 mit der eigentlich installierten 141.07.12 beschrieben, ein umstellen der linux_fs_start durch geführt und dann mit
quote REBOOT
bye
einen Neustart durch geführt. Das Ergebnis bleibt wie vorher auch. Protokoll liefere ich gleich nach.

VG

Edit 2:

ich@linux:$ ncftp -u adam2 -p adam2 192.168.178.1
NcFTP 3.2.5 (Feb 02, 2011) by Mike Gleason (http://www.NcFTP.com/contact/).
Connecting to 192.168.178.1...                                                                                  
ADAM2 FTP Server ready
Logging in...                                                                                                    
User adam2 successfully logged in
Command not implemented                                                                                          
Command not implemented
Logged in to 192.168.178.1.                                                                                      
ncftp / > quote MEDIA FLSH
Media set to MEDIA_FLASH
ncftp / > binary
ncftp / > passive
passive                        off
ncftp / > quote SYST
AVM EVA Version 1.3125 0x0 0x36409
ncftp / > quote SYST
AVM EVA Version 1.3125 0x0 0x36409
ncftp / > quote SYST
AVM EVA Version 1.3125 0x0 0x36409
ncftp / > quote SYST
AVM EVA Version 1.3125 0x0 0x36409
ncftp / > passive
passive                        on
ncftp / > quote SYST
AVM EVA Version 1.3125 0x0 0x36409
ncftp / > quote SYST
AVM EVA Version 1.3125 0x0 0x36409
ncftp / > quote SYST
AVM EVA Version 1.3125 0x0 0x36409
ncftp / > ls
List failed.
ncftp / > lpwd      
/github/YourFritz/6490_backup/FritzBox6490_141_07_12_image
ncftp / > lls
ARM/        chksum.x86*         info.txt     regelex*
ATOM/        content         install*     remote/
burnimage*  docsiscertdefaults*  md5sumext*     signature
chksum*     ewnw_check_install*  md5sumext.x86*  version
ncftp / > put -z ARM/filesystem.image mtd11
ARM/filesystem.image:                                    5,53 MB    1,00 MB/s
ncftp / > put -z ARM/kernel.image mtd12
ARM/kernel.image:                                        1,79 MB  939,10 kB/s
ncftp / > put -z ATOM/filesystem.image mtd13
ATOM/filesystem.image:                                  23,08 MB    1,16 MB/s
ncftp / > put -z ATOM/kernel.image mtd14
ATOM/kernel.image:                                       3,33 MB  914,26 kB/s
ncftp / > quote GETENV linux_fs_start
Invalid reply: "linux_fs_start        1"
ncftp / > quote SETENV linux_fs_start 0
Protocol violation by server: blank line on control.
GETENV command successful
ncftp / > quote SYST
SETENV command successful
ncftp / > quote SYST
AVM EVA Version 1.3125 0x0 0x36409
ncftp / > quote SYST
AVM EVA Version 1.3125 0x0 0x36409
ncftp / > quote GETENV linux_fs_start
AVM EVA Version 1.3125 0x0 0x36409
ncftp / > quote SYST                
Invalid reply: "linux_fs_start        0"
ncftp / > quote SYST
Protocol violation by server: blank line on control.
GETENV command successful
ncftp / > quote SYST
AVM EVA Version 1.3125 0x0 0x36409
ncftp / > quote REBOOT
AVM EVA Version 1.3125 0x0 0x36409
ncftp / > quote SYST
AVM EVA Version 1.3125 0x0 0x36409
ncftp / > quote SYST
Thank you for using the FTP service on ADAM2
ncftp / > bye

Sind denn die environment und count soweit in Ordnung?

 

[PeterPawn]

Power LED blinkt für ca 1min

Das ist aber ein deutliches Zeichen, daß der Kernel tatsächlich schon geladen wird bzw. wurde - ein "NAND/eMMC komplett defekt" kann man also wohl schon mal ausschließen.

Ich würde hier mal eine FRITZ!OS-Version versuchen, bei der die Serielle noch einigermaßen "gesprächig" ist ... ich weiß nicht mehr genau, wann AVM das "abgestellt" hat, aber die Version 06.83 sollte - aus dem gestarteten FRITZ!OS heraus - noch die serielle Schnittstelle nutzen.

Ich hatte mal begonnen mit einem Skript, was auch spätere Kernel entsprechend patchen kann an der Stelle, wo dieses "mute" auf den Standardwert gesetzt wird:

(so sah das bei irgendeinem Kernel (Version weiß ich nicht mehr) im x86-Code aus, wenn das Flag geprüft wurde), das dann aber nicht weiter verfolgt.

Bei meinem Bootloader habe ich es auch nicht hinbekommen, ein mute=0 tatsächlich bis ins System zu kriegen (so daß es wenigstens bei den Kernel-Parametern angezeigt wird) - irgendwie wird/wurde das immer von Loader ausgefiltert, so daß ich mit dem Kernel-Parameter (in drivers/tty/serial/8250.c, ca. Zeile 3690) nichts anfangen konnte und das lieber immer wieder gepatcht habe.

Langer Rede kurzer Sinn: Um das "Problem" einzugrenzen, würde ich hier (bei dieser "Schleifenlänge") man eine ältere Version mit aktivierter serieller Schnittstelle installieren und damit nach der Ursache suchen. Welche Version es genau sein müßte, steht hier bestimmt auch irgendwo - ich tippe mal auf 06.83, weil das die Version ist, die ich auf meiner Test-Box mit den bestückten seriellen Schnittstellen installiert habe.

PS:

Allerdings komme ich anschliessend nicht mehr in EVA. Hier hilft nur ein Hard-reset per Strom trennen.

Solche Dinge gibt/gab es auch schon öfter, aber m.W. bisher nie vor den GRX5-Boxen. Hier wäre die Seriennummer (Herstellungsdatum) mal interessant - wobei die Bootloader-Versionsnummer ja auch immer noch die 1.3125 ist und bei dem ist das eigentlich so nicht bekannt (soweit ich weiß und ich habe selbst eine Box mit diesem Loader). Aber das ist wohl von AVM - dem Anschein nach - irgendwann absichtlich geändert worden ... immerhin sorgt es dann auch dafür, daß "Angriffe" auf den Bootloader tatsächlich nur noch nach einem "Power-On-Reset" erfolgen können.

---

EDIT:
Bei Environment und Countern (die sind - wie geschrieben - ohnehin Müll bei der 6490) sehe ich keine Probleme ... bei der Benutzung von NcFTP hingegen schon. Zumindest regt der sich auch über die "protocol violation" beim GETENV auf (das kann auch von der Version des FTP-Clients abhängig sein) - ich würde mich nicht darauf verlassen, daß das danach alles noch stimmt bzw. ich habe auch keine Lust, da jetzt "Ratespiele" zu veranstalten, welche (verspätete) Antwort zu welchem Kommando gehört.

Schon die Tatsache, daß da noch zwei quote SYST nach dem quote REBOOT zu sehen sind, zeigt ja deutlich, daß hier etwas nicht stimmen kann - die Box sollte/müßte bei einem REBOOT-Kommando nur noch quittieren und dann neu starten. Wenn man einen NcFTP verwendet, sollte das - meine Empfehlung - zumindest einer sein, der sich durch die Protokoll-Verletzung durch den FTP-Server NICHT irritieren läßt - bei älteren Versionen war das vermutlich noch nicht der Fall, wenn man sich andere Protokolle ansieht (ich selbst würde natürlich NIE mit dem NcFTP "freiwillig" arbeiten).

 

[adfx]

Das hört sich nach einem Plan an. Mit einer seriellen Ausgabe kann ich mehr anfangen. Ich berichte...

Welchen ftp Client kannst du denn empfehlen?

Edit:
Es gibt eine Änderung/Neuerung. Ich befinde mich nun in einem echten Loop mit Auto Neustart der Box. Zuvor musste ich ja selbst neu starten um die glimmende Info LED zu beseitigen. Das macht nun die Box allein. Folgendes habe ich durch geführt:

ich@linux:~/github/YourFritz/eva_tools$ pftp 192.168.178.1
Connected to 192.168.178.1.
220 ADAM2 FTP Server ready
Name (192.168.178.1:eddy): adam2
331 Password required for adam2
Password:
230 User adam2 successfully logged in
Remote system type is AVM.
ftp> quote MEDIA FLSH
200 Media set to MEDIA_FLASH
ftp> binary
200 Type set to BINARY
ftp> passive
Passive mode off.
ftp> passive
Passive mode on.
ftp> put ../6490_backup/FritzBox6490_141_06_62_image/ARM/filesystem.image mtd11
local: ../6490_backup/FritzBox6490_141_06_62_image/ARM/filesystem.image remote: mtd11
227 Entering Passive Mode (192,168,178,1,54,69)
150 Opening BINARY data connection
226 Transfer complete
14901497 bytes sent in 12.36 secs (1.1494 MB/s)
ftp> put ../6490_backup/FritzBox6490_141_06_62_image/ARM/kernel.image mtd12
local: ../6490_backup/FritzBox6490_141_06_62_image/ARM/kernel.image remote: mtd12
227 Entering Passive Mode (192,168,178,1,54,69)
150 Opening BINARY data connection
226 Transfer complete
1818451 bytes sent in 1.74 secs (1019.5789 kB/s)
ftp> put ../6490_backup/FritzBox6490_141_06_62_image/ATOM/filesystem.image mtd13
local: ../6490_backup/FritzBox6490_141_06_62_image/ATOM/filesystem.image remote: mtd13
227 Entering Passive Mode (192,168,178,1,54,69)
150 Opening BINARY data connection
226 Transfer complete
13407536 bytes sent in 11.28 secs (1.1340 MB/s)
ftp> put ../6490_backup/FritzBox6490_141_06_62_image/ATOM/kernel.image mtd13
local: ../6490_backup/FritzBox6490_141_06_62_image/ATOM/kernel.image remote: mtd13
227 Entering Passive Mode (192,168,178,1,54,69)
150 Opening BINARY data connection
226 Transfer complete
3697840 bytes sent in 3.13 secs (1.1251 MB/s)
ftp> quote GETENV linux_fs_start
linux_fs_start        1
ftp> quote SETENV linux_fs_start 0

ftp>
ftp> quote GETENV linux_fs_start
200 GETENV command successful
ftp> quote
(command line to send) ^C
ftp> quote SYST
200 SETENV command successful
ftp> quote SYST
linux_fs_start        0
ftp> quote SYST

ftp> quote SYST
200 GETENV command successful
ftp> quote SYST
215 AVM EVA Version 1.3125 0x0 0x36409
ftp> quote REBOOT
215 AVM EVA Version 1.3125 0x0 0x36409
ftp> quote SYST
215 AVM EVA Version 1.3125 0x0 0x36409
ftp> quote SYST
215 AVM EVA Version 1.3125 0x0 0x36409
ftp> quote SYST
215 AVM EVA Version 1.3125 0x0 0x36409
ftp> quote SYST
221 Thank you for using the FTP service on ADAM2
ftp> quit
221 Goodbye.

Nach dem

quit

startete die Box neu und ist seit dem im Loop. Der läuft so ab:
- Anschalten
- alle LED's blinken 1x
- Power blinkt 6X
- Power leuchtet 20 sek.
- Power blinkt 43 sek
- neustart

Leider bekomme ich nur auf dem serial Port rechts neben dem schwarzen Kühlkörper folgende Ausgabe (115200,8N1):

CLI>build_version=0x11, rom_version=0x41020000, ram_version=0x11, stack_size=6348
reset reason=0x0

Image startup of Normal mode

Die anderen beiden serial Ports, also über und unter dem Kühlkörper schweigen mich nach wie vor an. @PeterPawn Baudrate falsch?? Ich habe extra die niedrigste 141.06'er FW genommen die ich finden konnte, da Du Dir ja nicht ganz sicher warst, ab welcher die serielle Konsole tot ist.

Edit DM41: Mehrfachbeiträge zusammengeführt.

 

[PeterPawn]

Ich habe extra die niedrigste 141.06'er FW genommen die ich finden konnte, da Du Dir ja nicht ganz sicher warst, ab welcher die serielle Konsole tot ist.

Trotzdem hatte ich Dir ja eine einigermaßen konkrete Firmware-Version genannt. Da vor der 06.8x die Firmware komplett anders aufgebaut war (das findet man hier auch, zumindest einen "Verlauf" der Firmware-Versionen und die Info, wann AVM mit dem FRITZ!OS auf den x86-Core gewechselt ist), war der Versuch, das mit einer anderen Firmware zu machen, wahrscheinlich eher ein Eigentor ... obendrein eines, was ich nicht verstehe. Denn eigentlich ist "die niedrigste 141.06'er Firmware" auch wieder ein reines Ratespiel - der einzige "echte Hinweis" sind die Dateinamen im Protokoll und niemand wäre Dir böse, wenn Du das einfach mal explizit "erwähnen" würdest, welche Firmware-Version verwendet wurde.

Jedenfalls ist die 06.6x-Reihe noch eine, wo ein guter Teil auf dem ARM-Core läuft, der in der Referenzimplementiering eigentlich dem CM vorbehalten wäre - woran sich AVM dann ab der 06.8x auch gehalten hat. Das sieht man schon am Größenunterschied des (ARM-)Systems zwischen der 06.6x und der 06.8x - zumindest an der des Dateisystems.

Außerdem verstehe ich die Intention auch nicht ... ich schrieb, daß in der 06.83 die Console funktioniert und daß ich die auch auf einer solchen Box mit bestückten seriellen Schnittstellen habe - siehe #8 vor dem PS. Warum willst Du dann "noch weiter zurück" mit der FRITZ!OS-Version? Ich hätte es ja noch verstanden, wenn man daraus gelesen hätte, daß auch eine 06.84 oder 06.85 noch funktionieren KÖNNTE - einen Grund, da noch weiter zurück zu gehen, sehe ich nicht und ich hatte die 06.8x schon "mit Hintergedanken" (eben im Wissen um den Architekturwechsel) "empfohlen".

DAS mußt Du also noch einmal nacharbeiten - dann sollte auch die x86-Console funktionieren. Wo die genau liegt, steht hier auch irgendwo (ich tippe mal, daß Du an der ARM-Console bist) ... ich glaube mich sogar zu erinnern, daß ich hier mal ein Foto einer offenen 6490-Box mit zwei eingebauten RS232-USB-Adaptern gezeigt habe, wo auch dabei stand, welcher Adapter für welchen Core zuständig ist. Das sind auch alles Dinge, die ich nicht mehr unbedingt "im Kopf" habe und wo ich genauso erst suchen müßte ... außer ich schraube die betreffende Box noch einmal auf, wozu ich erst einmal keinen Anlaß erkennen kann.

EDIT:
Rein aus Interesse, ob mein Hirn noch taugt, habe ich selbst mal schnell gesucht: https://www.ip-phone-forum.de/threads/6490-serial-port.283851/post-2292185 - Du bist also auch nicht am ARM-Core, sondern an der dritten Schnittstelle, wo es nur Vermutungen (WiSoC) gibt.

 

[adfx]

Wenn ich den angehängten output der Konsole richtig lese, habe ich eine defekte eMMC. Zeile 535 oder bei 16.573776s gibt es einen timeout der mmc0. Allerdings bin ich kein Fachmann, hatte allerdings ähnliche Fehler bei einem HD-sterben. Korrigiert mich gerne wenn ich falsch liege.

 

[PeterPawn]

Da ist zwar irgendein Problem mit dem eMMC zu sehen, aber das betrifft die bereits erwähnten 1,5 GB der NAS-Flash-Partition. Als nächstes würde ich hier erst einmal durch die Angabe von recovered=2 in der Urlader-Variablen firmware_info (von der Version durch ein Komma getrennt oder auch ohne Versionsnummer) versuchen, diese Partition neu formatieren zu lassen. Defekte "Sektoren" können entweder durch die Hardware (den Controller auf dem eMMC-Chip) oder sogar durch die Software (es gab bei Block-Devices schon immer die Möglichkeit, daß da einzelne Blöcke fehlerhaft sind, die werden dann halt nicht genutzt) ausgeblendet/übergangen werden ... bei 2 GB sind ein paar wenige Fehler sogar zu erwarten, wobei der eMMC-Controller (der ja aus den "Speicherzellen" erst ein Block-Device macht) die normalerweise sofort durch Spare-Blöcke (die genau dafür vorgehalten werden) ersetzen sollte.

Wenn er das beim Formatieren macht, ist danach alles wieder in Ordnung - wenn nicht, kann man immer noch (indem man das Mounten des NAS-Flashs in einer eigenen Firmware vorübergehend abschaltet und die Partition manuell prüft bzw. sogar ggf. die Größe passend ändert) von Hand versuchen, die tatsächlich defekten Blöcke weiter einzugrenzen.

Generell defekt KANN der Chip nicht sein, denn sowohl Kernel als auch Root-Dateisystem werden ja von dort gelesen. Was man noch (der Vollständigkeit halber) machen kann, ist der Start aus dem anderen Partition-Set - nur damit man sicher sein kann, daß auch hier die Kernel- und die Dateisystem-Partition fehlerfrei sind (bzw. vom Controller korrekt behandelt werden).

 

[adfx]

Moin zusammen,

also die Box läuft wieder. An dieser Stelle vielen Dank an @PeterPawn für seine Geduld mit mir.
Des Rätsels Lösung hier war:

- Box mit FW 141.06.83 um eine serielle Konsole zu haben und den Fehler beim booten lesbar zu machen
- firmware_info 141.06.83,recovered=2 setzen, um die (Teil-)Defekte eMMC formatieren zu lassen
- Box beim "reparieren" zugucken

Danach bootete die Box einwandfrei hoch und zwar von beiden Partitionssets. Werde auf einem Set die 06.83 lassen und die andere noch aktualisieren. Dann geht es für die Box zu meiner Schwägerin. Vielen Dank noch mal und viel gelernt bei der Aktion.

Grüße
adfx

 

[H´Sishi]

Gratuliere .

Ich habe hier der Neugierde zuliebe mitgelesen und zum Punkt "eMMC" eine Frage: Ist das hardwaremäßig ein verlöteter Chip oder eine tatsächliche "card", die in irgendeinem Sockel steckt?
Die Frage stelle ich mit dem Hintergedanken, daß die 7490 auch einen vom Benutzer verwendbaren internen Flash-Speicher von sagenhaften 512 MB hat. Wenn das auch eine gesteckte Karte ist (SD, MMC), müßte ja ein Speicherupgrade möglich sein ...

 

[SaschaBr]

Nein, keine gesteckten Karten. Alles verlötet.

 

[H´Sishi]

Ah, schade, hab's aber befürchtet.

Mir ist mal ein WLAN-Router untergekommen, dessen WLAN von einer PCMCIA-Karte erzeugt wurde ...

 

[NDiIPP]

Die Frage stelle ich mit dem Hintergedanken, daß die 7490 ...

Selbst wenn das bei der 6490 eine Steckkarte wäre (was nicht der Fall ist, siehe oben, ist ein aufgelöteter Chip im BGA-Gehäuse) könnte man das nicht auf eine 7490 übertragen denn die hat im Gegensatz zur 6490 gar keinen eMMC-Speicher (eMMC-Speicher = NAND-Flash + Controller). Die 7490 hat "nur" einen reinen NAND-Flash Baustein (jedoch ebenfalls im BGA-Gehäuse, Edit: Irrtum, es ist ein TSOP-Gehäuse) und der Controller ist quasi in Software realisiert (Linux-Kernel).

Das ist ja auch der Grund, weshalb man bei einer 7490 (im Gegensatz zur 6490) nicht direkt per Bootloader die Firmware in den Flash-Speicher schreiben kann da der (vgl. simple) Bootloader keine NAND-Flash "Controller-Funktionalität" (u.a. für Defekt-Management, Wear-Leveling) besitzt und daher bei der 7490 die Firmware in den RAM geladen wird damit sie von dort gestartet werden kann um sich dann selbst in den NAND-Flash zu schreiben. Bei der 6490 (oder auch 6590, 6591 und 6660) sieht das aufgrund des eMMC-Speicher anders aus, hier ist der Controller bereits im Flash-Baustein enthalten (in Hardware) und kann somit direkt vom Bootloader beschrieben werden.

Und bevor die Frage auftaucht weshalb man das bei der 7490 so und bei der 6490 anders gelöst hat. Auch wenn diese beiden Modelle nach außen hin die gleiche Generation darstellen, so ist der SoC der 6490 und 7490 sehr unterschiedlich (nicht nur bezüglich xDSL vs DOCSIS). Der SoC der 7490 (VRX288) besitzt m.W.n. kein eMMC-Speicherinterface (und der SPI-Modus dürfte wohl zu langsam/ineffizient sein als Ersatz) und der SoC der 6490 (Puma 6) imo kein Interface für die direkte Anbindung eines reinen NAND-Flash dafür aber ein eMMC-Interface.