Du verwendest einen veralteten Browser. Es ist möglich, dass diese oder andere Websites nicht korrekt angezeigt werden. Du solltest ein Upgrade durchführen oder ein alternativer Browser verwenden.
Hallo zusammen,
ich habe eine 7520 die nach dem schreiben des mtd1 nicht mehr startet
Habe einen seriellen Adapter angeschlossen und so sieht der Startlog aus:
Code:
Format: Log Type - Time(microsec) - Message - Optional Info
Log Type: B - Since Boot(Power On Reset), D - Delta, S - Statistic
S - QC_IMAGE_VERSION_STRING=AVM_BOOT.BF.3.1.1
S - IMAGE_VARIANT_STRING=DAABANAZA
S - OEM_IMAGE_VERSION_STRING=1204
S - Boot Config, 0x00000025
S - Reset status Config, 0x00000000
S - Core 0 Frequency, 0 MHz
B - 261 - PBL, Start
B - 1339 - bootable_media_detect_entry, Start
B - 2612 - bootable_media_detect_success, Start
B - 2626 - elf_loader_entry, Start
B - 4044 - auth_hash_seg_entry, Start
B - 5975 - auth_hash_seg_exit, Start
B - 110185 - elf_segs_hash_verify_entry, Start
B - 301613 - PBL, End
B - 0 - SBL1, Start
B - 401997 - pm_device_init, Start
D - 9 - pm_device_init, Delta
B - 403122 - boot_flash_init, Start
D - 80146 - boot_flash_init, Delta
B - 487612 - boot_config_data_table_init, Start
D - 13964 - boot_config_data_table_init, Delta - (419 Bytes)
B - 504033 - clock_init, Start
D - 7430 - clock_init, Delta
B - 514437 - CDT version:2,Platform ID:8,Major
B - 515742 - sbl1_ddr_set_params, Start
B - 520450 - cpr_init, Start
D - 4 - cpr_init, Delta
B - 525528 - Pre_DDR_clock_init, Start
D - 5 - Pre_DDR_clock_init, Delta
D - 13021 - sbl1_ddr_set_params, Delta
B - 538923 - pm_driver_init, Start
D - 4 - pm_driver_init, Delta
B - 574161 - sbl1_wait_for_ddr_training, Start
D - 30 - sbl1_wait_for_ddr_training, Delta
B - 590282 - Image Verify, Start 0:QSEE
D - 283753 - QSEE Image Loaded, Delta - (293144 Bytes)
B - 874350 - Image Verify, Start 0:QSEE_B
D - 286531 - QSEE Image Loaded, Delta - (293144 Bytes)
B - 1161237 - Selected TZ0: 10228 (0:QSEE)
B - 1164298 - Image Load, Start
D - 286442 - QSEE Image Loaded, Delta - (293144 Bytes)
B - 1451053 - Image Load, Start
D - 2029 - SEC Image Loaded, Delta - (2048 Bytes)
B - 1464613 - Image Verify, Start 0:APPSBL
B - 1589146 - Image Verification failed (689)
D - 124890 - APPSBL Image Loaded, Delta - (118924 Bytes)
B - 1593278 - Image Verify, Start 0:APPSBL_B
B - 1721701 - Image Verification failed (689)
D - 128781 - APPSBL Image Loaded, Delta - (118924 Bytes)
B - 1725781 - No verified EVA in flash!!! Booting not possible!!!
Original mtd1 ist vorhanden, aber wie bekomme ich den drauf? Eingabe ist keine möglich.
Jedenfalls nicht per RS232-Schnittstelle. Wenn dann wäre es per (E)JTAG-Schnittstelle denkbar oder aber man beschreibt den NAND-Flashbaustein mit einem anderen Gerät direkt.
SBL - Second stage of the boot process on ARM based systems - BoxMatrix FRITZ!Box Research Wiki
boxmatrix.info
Du hattest 2 kaputte EVA instanzen. Keine Ahnung wie das passieren kann. Vielleicht marodes Flash, weil normal ost extra die zweite Instanz da zur Sicherheit...
Vielen Dank.
PS: Beim nächsten Mal schick mir so was statt es zu entsorgen. Zahle Porto und symbolischen Preis.
nach fast 5 Jahren hab ich mir mal wieder den Bootloader in mtd1 angeschaut und überlegt was wohl damals schief gelaufen ist. Habe damals den mtd1 mit cat gesichert mit einem HEX Editor angepasst und mit cat wieder zurückgeschrieben ohne lang darüber nachzudenken. Hab Heute nochmal geschaut wie die environment in mtd1 gespeichert sind und was mich wundert (und das war wahrscheinlich damals der fatale Fehler) das alles doppelt oder sogar 4fach drinnen steht. Die Fritz_Box_HW von der 7530 (Fritz_Box_HW236) steht auch drinnen obwohl es eine 7520 (Fritz_Box_HW247) ist.
Flash-Speicher einfach direkt mit cat zu beschreiben, funktioniert in der Regel nicht und wenn das damals tatsächlich so war bei Deinem ersten Versuch, hätte man vermutlich auch nicht gleich auf irgendwelche Sicherungen durch AVM getippt, denn daß dieses Vorgehen funktionieren würde, ist sehr, sehr unwahrscheinlich. Erst recht, wenn man dafür die Block-Device-Emulation verwenden will, die gar kein "bad block"-Handling hat: http://www.linux-mtd.infradead.org/doc/general.html (Zitat: "In other words, please, do not use mtdblock unless you know exactly what you are doing." - man sollte das zumindest mal gelesen haben, bevor man irgendwie mit MT-Devices hantieren will).
Da müssen die betreffenden Blöcke zunächst mal per ioctl-Aufruf gelöscht werden, bevor sie neu "programmiert" werden können. Ansonsten erhält man eine "Überlagerung" von altem und neuem Inhalt, die natürlich NICHT mit dem gewünschten Inhalt übereinstimmt. Da gelöschte Blöcke in aller Regel alle Bits gesetzt haben, kann man derartige Schreibvorgänge zwar auch gezielt zur Änderung bestehender Inhalte benutzen, aber auch das ist heutzutage eher selten (weil bei NAND-Flash auch mit defekten Blöcken zu rechnen ist und beim Schreiben Wear-Leveling verwendet werden sollte, wo die neuen Inhalte dann an ganz anderen Stellen im physikalischen Speicher landen und eine weitere Abstraktionsschicht die Verbindung zwischen physischen und logischen Blöcken herstellt). Man kann bei noch nicht geschriebenen Bits diese zwar von logisch 1 auf 0 bringen, aber nicht umgekehrt. Nur dann, wenn da noch irgendein zusätzlicher Dateisystem-Treiber über den Flash-Speicher wacht (wie das z.B. beim UBIFS der Fall wäre), muß man sich nicht selbst um das Löschen kümmern.
AVM hat sich bei seinem TFFS-Treiber dieses Verhalten zunutze gemacht (beim "legacy format" in NOR- oder SPI-Flash), indem man das "tag" mit dem Namen ID für ältere Einträge der komprimierten Streams mit den Daten für die Minor-IDs (z.B. 113 bzw. 0x0071 für die ar7.cfg) einfach durch Schreiben von binären Nullen als "zu überspringen" markiert:
, während eben die nach dem Löschen dort enthaltenen binären Einsen (also 0xFFFF für einen 16-Bit-Wert) freie Bereiche markieren, die zum "Fortschreiben" von Inhalten verwendet werden können.
Zum Neuprogrammieren von Flash-Speicher gibt es bei AVM schon seit vielen Versionen ein passendes Utility namens sbin/update_kernel, das man auch zum Beschreiben von NAND-Flash verwenden kann und zu dem hier auch schon sehr viel von mir geschrieben wurde. AVM verwendet das selbst tatsächlich i.d.R. mit zwei getrennten Aufrufen (1x ohne Eingabedatei, wo dann die Partition nur gelöscht wird und 1x mit Eingabedatei, wo dann der neue Inhalt programmiert wird), was aber m.E. unnötig ist, da vor dem Schreiben der Eingabedaten ohnehin noch einmal die IOCTL-Aufrufe für das Löschen ausgeführt werden. Ansonsten gibt es dafür auch noch andere Tools, z.B. das flash_erase aus den mtd-utils.
Der Bootloader dürfte in zwei Kopien in der entsprechenden Partition stehen (zusammen mit weiteren Images oder Libraries, der Anzahl der ELF-Header nach zu urteilen), zwischen denen ggf. umgeschaltet wird, wenn die erste Kopie nicht lesbar sein sollte. Je nachdem, woran dieses "nicht lesbar" festgemacht wird, kann es eben dazu führen, daß Änderungen an einer dieser Kopien zu einem Problem führen, wenn dabei irgendwelche Prüfsummen (oder gar kryptographische Signaturen) verwendet werden, die durch die Änderungen an der Loader-Kopie dann ungültig werden und zum Versuch mit der zweiten Kopie führen. Wenn diese dann ebenfalls solchen (falschen) Änderungen zum Opfer gefallen ist, kann das eben dazu führen, daß gar keine funktionsfähige EVA-Kopie mehr gefunden wird. Es gibt (der einfachen Ansicht nach) jedenfalls zwei verschiedene Funktionen (namens get_eva0_verified und get_eva1_verified), die vermutlich dazu dienen, eine funktionsfähige Kopie des Bootloaders zu lokalisieren.
Wie genau da geprüft wird (das "verified" läßt es zumindest vermuten, DASS da etwas geprüft wird), ist (afaik) bisher unbekannt - aber die Idee, da irgendwie mittels sed auf dem Block-Device ändern zu wollen, ist aus mehreren Gründen ziemlich furchtbar. Allerdings wird das aus den erwähnten Gründen wohl ohnehin nicht funktionieren ... zum Glück, müßte man hier vermutlich konstatieren.
Jedenfalls enthält die Bootloader-Partition bei der 7520 auch den "üblichen" Konfigurationsbereich (die dritte Version) in zwei getrennten Kopien, dabei liegt die erste bei der Verschiebung 0x27E800 (also am Ende der ersten EVA-Kopie, denn die zweite müßte bei 0x280000 beginnen) und die zweite bei 0x2BE800 (die Partition selbst ist 0x2C0000 Byte groß). Darin steht dann auch das Branding der Box - allerdings als null-terminierte Zeichenkette und damit sollte man max. mit einem Hex-Editor auf das/ein Image(!) des Bootloaders losgehen und nach dem avm zwei binäre Nullen setzen, falls man es sich wirklich nicht verkneifen kann.
Anschließend KÖNNTE man dann das gesamte geänderte Image erneut in die Bootloader-Partition schreiben lassen (was definitiv NICHT zum Ausdruck bringen soll, daß ich das für schlau oder irgendwie erforderlich halte), was dann immerhin eine CHANCE hätte, zu funktionieren. Was man ansonsten mit einem unbedachten Einsatz eines textorientierten Editors anrichten kann, hatten wir hier auch schon oft, u.a. hier: https://www.ip-phone-forum.de/threads/f-b-6591-bootloop.318729/post-2551754
Die Tatsache, daß bei der 7520/7530 der Konfigurationsbereich an so einer "krummen" Adresse (aus Programmsicht sind 6 KB vor dem Ende der jeweiligen Kopie schon "bemerkenswert") liegt, ist es auch, die verhindert, daß mein Bootmanager auf diesen Modellen funktioniert - der findet halt derzeit den Konfigurationsbereich bei diesen beiden Modellen nicht, was ich eigentlich auch schon seit Jahren korrigieren will - nur fehlt mir Zeit und Lust, weil diese Boxen halt nicht wirklich verbreitet sind und daher eher nicht zur Zielgruppe gehören.
vielen Dank für deine ausführliche Antwort.
Tatsächlich habe ich das damals nicht in mtdblock1 geändert sondern in mtd1.
Ich habe Heute bevor ich hier geschrieben habe chatgpt gefragt welches mtd besser geeignet ist für Änderungen.
Code:
Wenn du einen Flash-Baustein ändern möchtest, hängt die Wahl zwischen /dev/mtd1 und /dev/mtdblock1 von der Art des Zugriffs und der Operation ab:
1. /dev/mtd1 (Character Device)
• Dieses Device wird verwendet, wenn du direkten Zugriff auf den Flash-Speicher benötigst.
• Es erlaubt niedrigere Zugriffsebene, wie z. B. Löschen, Schreiben oder Lesen von Rohdaten auf Blockebene.
• Wird häufig für spezielle Flash-Operationen wie mit Tools wie flash_erase, nandwrite oder nanddump verwendet.
2. /dev/mtdblock1 (Block Device)
• Dieses Device bietet einen blockorientierten Zugriff auf den Flash-Speicher, ähnlich wie bei herkömmlichen Festplatten.
• Es ist nützlich für Datei-basierte Operationen oder wenn der Flash-Speicher mit einem Dateisystem (z. B. JFFS2, UBIFS) formatiert ist.
• Wird von Tools oder Programmen verwendet, die mit Blockgeräten arbeiten, wie z. B. dd.
Fazit:
• Rohzugriff (z. B. Flash löschen oder neu beschreiben): Verwende /dev/mtd1.
• Dateisystem-Operationen (z. B. Mounten oder Kopieren): Verwende /dev/mtdblock1.
Beachte, dass falsche Operationen auf diesen Geräten irreparable Schäden am Flash-Speicher oder den Daten verursachen können. Stelle sicher, dass du die richtigen Tools und Befehle für die jeweilige Operation verwendest.
Das ändert aber auch nichts wirklich (mal abgesehen davon, daß ja sogar ChatGPT sehr deutlich warnt vor dem Block-Device - oder fällt das bei Dir dann unter "dateibasierte Operationen" bzw. was für ein Filesystem verwendet denn die Bootloader-Partition nach Deiner Ansicht?), denn auch die Benutzung von mtd1 mit cat ist ohne vorheriges Löschen der zu schreibenden Blöcke Unsinn und das müssten bei Verwendung von cat dann ja auch wieder ALLE (Erase-)Blöcke für das Device sein.
