[Problem] FritzBox 7590 Startet nicht / Recovery nicht möglich

[PeterPawn]

Ich hoffe mal, daß dabei nicht auch noch der versteckte LTE-Chip in der 7590 aktiviert wird ... sonst geht das Gebastel morgen garantiert so richtig los.

 

[prisrak1]

wenn die F!B erst wieder startet, ist es schon ok.

 

[prisrak1]

ich habs immer noch nicht den versteckten LTE-Chip in der 7590 aktiviert. oder die 7590 selbst. Hat sich was in den Scripten, oder den Methoden geähndert? Wie bekomme ich die 7590 zum Laufen? Mir währe egal was für eine Firmware drauf läuft. Hauptsache es läuft was.

 

[PeterPawn]

Wenn wir hier immer noch von der 7590 reden, bei der Du MTD0 (oder war's MTD1) beschrieben hast über EVA, dann wirst Du da wohl Pech haben ... wenn tatsächlich der Bootloader im Eimer ist nach dieser Aktion (das war ja die Vermutung, weshalb das in den Freetz-Skripten auch entschärft wurde), hilft nur ein neuer.

Über JTAG wird's vermutlich nichts werden (ich kenne jedenfalls keinen positiven Bericht), also bleibt nur noch das Programmieren des eingelöteten SPI-Flashs über einen Adapter: https://www.amazon.de/s?k=soic+clip

Den Bootloader dafür mußt Du Dir halt aus einem (möglichst baugleichen) anderen Gerät besorgen, die Kalibrierungsdaten für WLAN und DECT sind wohl Geschichte (wenn die tatsächlich im SPI-Flash gespeichert sind und nicht direkt im WLAN-Modul).

BTW ... auf den LTE-Chip mußt Du dann wohl auch verzichten - das war nur ein LTE-fähiges SDR, was über die WLAN-Antennen arbeitete, das ist natürlich jetzt auch weg. *SCNR*

 

[Priority]

Wie bekomme ich die 7590 zum Laufen?

Schreib mir mal PM, ich helfe Dir!

Was hat man(n) davon eine 7590 auf 6890 umflaschen? Nur WLAN Vorteile?

Ein regional entsperrtes Gerät, keine Restriktionen mehr diesbezüglich. Man kann einfach in den Regionen und Sprachen umstellen sowie einige interna die sonst verborgen bleiben. Ebenso Branding umändern, das geht bei 7590 gar nicht so einfach. Gibt diesbezüglich mehrere Threads.

Wobei ich mir gerade die Frage stelle, warum dann die internationale Version der 7590 bei "Australien" (LKZ 61 ist in jedem Falle vorgesehen in der 7590-avme-Firmware) den Kanal 161 nicht anbietet ... aber das kann ich (mangels Box) auch nicht prüfen. Sollte der aber doch dabei sein, würden vermutlich auch die wenigsten ihre 7590 (für die i.d.R. deutlich eher eine neue Firmware-Version erscheint) mit einer 6890-Firmware versehen wollen, die bekanntlich noch so einige Probleme im Betrieb (und wohl nicht nur bei Mischbetrieb mit LTE) hat, wenn man den Threads zu diesem Modell hier im Board Glauben schenken will.

Die int Version der 7590 hat alle Kanäle inkl Kanal 161-165 inkl

Meine 6490 cable die ich umgeflasht habe hat auch alle Kanäle. War mir gar nicht bekannt das es INT Versionen gibt wo es diese Kanäle nicht inkl gibt

 

[PeterPawn]

Ebenso Branding umändern, das geht bei 7590 gar nicht so einfach.

Wieso sollte sich das Branding mit einer anderen Firmware ändern?

Nur weil die Firmware für diese Box beide Brandings enthält (avm + avme), ändert sich das Branding der Box, auf der man die Firmware installiert, ja noch nicht. Oder was verstehe ich hier falsch?

Die Variable OEM wird in der rc.conf jedenfalls immer noch so gesetzt, wie man es aus anderen Modellen kennt. Wenn die Box also "avm" als Branding hat, landet das auch so in der laufenden Firmware.

Korrekt wäre also die Feststellung, daß bei der 6890 keine Unterscheidung am Dateiinhalt für die "avm"- und die "avme"-Version erfolgt (das ist bei den anderen Modellen i.d.R. anders, weil da die Dateien für anderen "country"- und "language"-Einstellungen in der deutschen Version fehlen) - das heißt aber auch noch nicht, daß nicht dann doch wieder anhand von "avm vs. avme" einige Funktionen in einer deutschen 7590 auch mit der 6890-Firmware nicht verfügbar sind.

Diese Unterscheidung zwischen "avm" und "avme" geht auch bereits in der rc.conf los, auch wenn da bei der 6890 schon bei "avm"-Branding ein paar Optionen (der üblicherweise der internationalen Version vorbehaltenen Auswahl) automatisch verfügbar sind, für die man ansonsten erst die Firmware ändern müßte - z.B. die Annex-Auswahl dank CONFIG_DSL_MULTI_ANNEX="y":

401 ##########################################################################################
402 ## OEM Ermitteln
403 ##########################################################################################
404 OEM_tmp=`cat $CONFIG_ENVIRONMENT_PATH/firmware_version`
405 if [ -z "${OEM_tmp}" ] ; then
406 OEM_tmp=$CONFIG_OEM_DEFAULT
407 fi
408 OEM=${OEM_tmp%,*}
409 OEM_DEFAULT_INDEX=${OEM_tmp#*,}
410 if [ "$OEM_DEFAULT_INDEX" = "$OEM" ] ; then
411 OEM_DEFAULT_INDEX=""
412 fi
413 export OEM_DEFAULT_INDEX
414 export OEM
415 ##########################################################################################
416 ## OEM spezifische Konfiguration
417 ##########################################################################################
418 if [ "$OEM" = "avm" ]; then
419 export CONFIG_DSL_MULTI_ANNEX="y"
420 export CONFIG_MULTI_COUNTRY="y"
421 export CONFIG_MULTI_LANGUAGE="y"
422 export CONFIG_PROV_DEFAULT="n"
423 fi
424 if [ "$OEM" = "avm" ]; then
425 export CONFIG_LAND_LISTE_OEM="049 99 0234 0255 0256 0264 027 030 031 032 033 034 0351 0352 0353 0357 0358 036 0371 0372 0382 0385 0386 0387 0389 039 041 0420 0421 043 044 045 046 047 048 054 061 064 066 0972"
426 fi
427 if [ "$OEM" = "avm" ]; then
428 export CONFIG_SPRACH_LISTE_OEM="de en es it fr pl nl"
429 fi
430 if [ "$OEM" = "avme" ]; then
431 export CONFIG_BOX_FEEDBACK="y"
432 export CONFIG_ERR_FEEDBACK="y"
433 export CONFIG_SPEECH_FEEDBACK="n"
434 fi

Ich weiß allerdings auch nicht genau, ob es tatsächlich 6890 mit unterschiedlichen Brandings gibt ... die deutsche hat ja wohl die Artikelnummer 2000 2817 und die internationale soll die 2000 2818 haben. Aber ob jetzt das eine Modell "avm" und das andere "avme" verwendet, können wohl nur deren Besitzer ermitteln - für die 6490 soll es ja z.B. gar keine originalen Geräte mit "avme" geben, wenn ich das letztens richtig verstanden habe in irgendeinem anderen Thread.

-------------------------------------------------------------------------------------------------------------------------

War mir gar nicht bekannt das es INT Versionen gibt wo es diese Kanäle nicht inkl gibt

Das habe ich auch gar nicht behauptet ... ich FRAGTE (mich, aber implizit auch alle anderen), warum man (mit der Begründung "WLAN") dann eine 6890-Firmware auf eine 7590 braten muß und da nicht einfach die internationale Version nimmt.

Das mit dem:

das geht bei 7590 gar nicht so einfach.

ist ja eher Ansichtssache (außer man weiß es halt nicht anders zu lösen) und ich würde jedem Nachahmer anraten, erst mal diese Option (Ändern des Brandings der Firmware auf "avme" - und zwar "fixed" für diese Version) zu probieren, weil die Ähnlichkeiten zwischen einer 7590 und einer 7590 intl. dann doch deutlich größer sind, als (von beiden) zur 6890 - immer unter der Annahme, daß ich noch aufgeklärt werde, was die 6890-Firmware am Branding der 7590 ändert.

Dieselbe Frage (warum Du nicht einfach die internationale Version installierst) hat Dir @NDiIPP in einem anderen Thread (sogar praktisch zeitgleich mit mir in diesem Thread, wenn man den Zeitpunkt der Veröffentlichung der Beiträge betrachtet) ja auch schon gestellt ... auch da hast Du ja behauptet (oder zumindest bis dahin wohl gedacht), es wäre gar nicht möglich, die internationale Version auf einer deutschen 7590 zu verwenden.

Wobei mit der "einfachen Lösung" eben nicht alle Fundstellen von firmware_version erwischt werden (zumindest nicht, wenn man das nicht bei jedem Start des FRITZ!OS in /proc/sys/urlader/environment einträgt, wo es für die Dauer der Uptime dann auch erhalten bleibt (afaik), selbst wenn es beim nächsten Start wieder aus dem Bootloader-Code neu gesetzt wird), weil einige Libs nicht über OEM zugreifen bzw. zumindest noch den Text firmware_version (dann vermutlich aber eben auch zum Zugriff auf diese Einstellung) enthalten.

Aber es bleibt bei mir halt die Frage von oben, wieso nur durch die Installation der 6890-Firmware jetzt das Branding einer Box "änderbar" wird (oder auch nur geändert wird) und eine Erklärung dafür erschließt sich mir bisher nicht ... vielleicht kannst Du das ja noch einmal genauer erklären.

Beiträge zusammengefügt - HabNeFritzbox

@prisrak1:
Mir ist gerade erst so richtig auf- und eingefallen, daß Du ja über eine 7590 sprichst ... die hat aber den Bootloader selbst auch im NAND-Flash und der hat zumindest das Lesen von NAND gelernt und wohl auch das Schreiben, denn die Einstellungen schreibt der ja nach "mtdnand" und er könnte wohl auch ein Update des Urladers selbst ausführen.

Damit vergiß einfach alles, was ich in #8 schrieb ...

Da müßte man also den NAND-Flash-Chip im PCB neu programmieren und dafür kenne ich keine Clips. Das ist bei 48 Pins am TSOP-Gehäuse (mit einem Pinabstand von ~0,5 mm) auch nicht so einfach ... das wird also ohne Löten vermutlich gar nichts, wenn Dir nicht jemand beim JTAG-Interface unter die Arme greifen kann (ich kann es nicht, hatte mal irgendwo hier etwas zu den Problemen geschrieben, vor denen man (zumindest ich) da steht).

Meines Wissens gibt es auch keine weiteren Infos, wie da das "defective block management" für den Bootloader in NAND gehandhabt wird. Ich würde (aufgrund der Struktur des Bootloaders, der normalerweise zweimal in der Partition enthalten ist) darauf tippen, daß da gar keine Rücksicht auf defekte Blöcke genommen wird, solange eine der beiden Kopien ausführbar ist. Zumindest sprechen auch einige Fehlermeldungen (die ich vom Bootloader der 7580 kenne) dafür ... bei der 7580 (und dann auch bei der 7590) gibt es z.B. die folgenden Nachrichten im Bootloader:

Detected broken Urlader @ 0x%08x, starting anyway 0x%08x != 0x%08x

All EVA Bootloaders broken, booting not possible

Das spricht ja (a) für eine Kontrolle der Gültigkeit von Blöcken , (b) für eine "Ausweichstrategie" (Prinzip Hoffnung - "starting anyway") und (c) für mehr als eine Kopie (die man natürlich auch im Hex-Dump sieht), wenn da "All ... broken" sein können und auch die Vorbereitung:

Error: Refusing to update! Urlader is finalized and the first EVA Urlader is broken, probably because of Bad Blocks.
Therefore we cannot downgrade to one EVA Urlader

zeigt, daß man sich Gedanken gemacht hat, daß man so einen Urlader-Code besser nicht aktualisiert, wenn der erste defekt ist und die Box ohnehin schon aus dem zweiten startet.

Neuere Boxen haben wohl alle NAND-Flash mit Hardware-ECC ... meine 7580 hat z.B. Toshiba-Chips - TC58NVG2S3E - lt. "dmesg":

NAND device: Manufacturer ID: 0x98, Chip ID: 0xdc (Toshiba NAND 512MiB 3,3V 8-bit), 512MiB, page size: 4096, OOB size: 128

(-> http://www.linux-mtd.infradead.org/nand-data/nanddata.html hat eine Tabelle)
, damit sollten (Bit-)Fehler in gewissen Grenzen nicht nur erkannt, sondern auch korrigiert werden können. Meine Box hatte auch von Beginn an (das war 3 Tage nach Lieferung) schon vier defekte Blöcke, die aber glücklicherweise alle weiter hinten lagen, wo schon der UBI-Layer verantwortlich ist.

Daher jedenfalls auch meine Annahme, daß der Bootloader schon gefälligst sequentiell im Flash vorliegen muß in fehlerfreien Blöcken, weil der Loader selbst keine alternativen Blöcke irgendwo an anderen Stellen suchen kann ... ggf. macht das auch schon der On-Chip-Controller des GRX5, der mit irgendeiner Bootstrap-Routine ja den allerersten NAND-Inhalt erst mal ins RAM bringen muß, damit der von dort laufen kann. So etwas wie eine XiP-Schnittstelle für SPI (eXecute in Place - die Daten werden in den Adressraum des Prozessors eingeblendet, wie bei "richtigem" NOR-Flash) gibt es m.W. für NAND-Flash nicht bzw. der MX30LF kennt so etwas m.W. ohnehin auch nicht.

Es gibt noch eine weitere Zeile im Loader, die mich vermuten läßt, daß die Installation des "endgültigen" Bootloaders am Ende vielleicht auch über ein Booten von einer seriellen Schnittstelle erfolgt ... die Nachricht:

Booting from UART. Only Urlader-Update supported!!!

klingt für mich jedenfalls so.

Auch wenn das "Booting from UART" erstens vermutlich einen funktionierenden Bootloader als Vorgänger voraussetzt (da steht ja auch "Urlader-Update") und zweitens könnte das auch gut ein anderer Anschluß auf dem PCB sein und nicht unbedingt der mit der seriellen Console.

Wobei die zwei nicht durchgebohrten Kontaktreihen auf der Rückseite wohl eher für den DECT-Chip sind ... zumindest gehören sie "räumlich" eher dazu, wenn es überhaupt RS232-Schnittstellen sind - die Frage des Pegels bliebe auch noch und selbst dann wäre immer noch das Protokoll für die Datenübertragung unbekannt - am wahrscheinlichsten erscheinen mir irgendwelche Synchronisationszeichen direkt beim Start der Schnittstelle, ähnlich XModem oder so.

---------------------------------------------------------------------------------------------------------------------------------------------

Bei den GRX-Boxen ist auch die Frage, woher man nun die Dateien für den Bootloader kriegt, tatsächlich eher unproblematisch (zumindest sollte sie es in der Theorie sein) ... AVM linkt den offensichtlich statisch gegen die uClibc (der Loader hat ja auch noch keine Chance, irgendwo in einem Filesystem nach Libraries zu suchen - ein Bootloader mit "shared libraries" ist fast per Definition Blödsinn und eher kein Bootloader mehr, sondern ein "Mini-OS") und diese wiederum steht unter LGPL.

In der Folge müßte AVM eigentlich die Binärdateien (Object Format) des Bootloaders herausgeben (nach Klausel 6a/6b der LGPL 2.1 - und auch die uClibc-ng steht unter derselben Lizenz, es ist also egal, welche Version das wirklich ist), damit man diese selbst gegen eine aktualisierte Version der uClibc linken und danach weiter verwenden kann - ob man dann dieselbe nimmt wie AVM oder nicht, spielt auch keine Geige in lizenzrechtlicher Hinsicht.

Wobei AVM durchaus auch die Quelltexte rausgeben darf ... denn in der LPGL steht ausdrücklich: as object code and/or source code.

Andererseits enthalten bei den GRX-Boxen die Firmware-Images auch gerne mal ein (ebenfalls statisch gg. uClibc oder ein Derivat gelinktes) Binary zum Aktualisieren des Urladers (als ./var/urladerupdate) ... mit etwas Spielerei (notfalls in einer QEMU-Instanz) kriegt man von dem bestimmt auch den Bootloader in ein emuliertes MTD geschrieben (sofern man ihm den vorherigen in der Partition vorsetzt).

 

[prisrak1]

wenns um eine QEMU-Instanz geht, so müßte diese irgendwo vorhanden sein. Ich vermute sogar, die neuen F!B-en werden / könnten vom Usbstick starten und werden danach mit einer entsprechender Software beschrieben. Somit stellt sich die Frage. wie gehts weiter? Wer hat die Info dazu?

Vermutlich gibts hier auch Mitarbeiter von AVM o.so, die das nötige Fachwissen besitzen. Es muß eigentlich eine Möglichkeit geben, jede F!B zu virtualisieren, bevor man eigene schrotet und den Hersteller unnötig mit einem Anspruch aus Garantie belästigt. Etliche Versuche mit Quemu gabs hier und da: h**ps://www.zebradem.com/wiki/index.php?title=Qemu_auf_Fritzbox

 

[PeterPawn]

Ich vermute sogar, die neuen F!B-en werden / könnten vom Usbstick starten

Das könnte ich mir max. für eine 6591 vorstellen, daß die - dank UEFI-BIOS - schon im Bootloader (wenn man das BIOS dazuzählen will) alles Notwendige haben könnte (und dann aber auch eine entsprechende Größe des Bootloader-Codes verzeichnet), um den USB-Stack zu initialisieren ... das ist nun mal eeeetwaaaas umfangreicher, was da (im Linux) für den Zugriff auf einen USB-Speicher benötigt wird ... und da rede ich noch gar nicht von der Notwendigkeit, dann auch irgendwelche Dateisysteme schon im Bootloader zu unterstützen - im Minimum FAT und da gehen die Probleme (was ist mit vFAT und exFAT, wie groß dürfen Partitionen max. sein, etc.) dann auch ganz schnell weiter.

Bei der 6591 wäre das dann hingegen - bereits von Intel - in der Architektur des Chipsets angelegt ... was bringt es AVM am Ende, wenn man eine solche Box vom Stick booten könnte? Für die Entwicklung braucht man's kaum, da wird entweder emuliert oder mit "nfsroot" gearbeitet und ob der Kunde dann einfach irgendetwas anderes starten kann oder nicht, interessiert AVM hoffentlich nicht wirklich bzw. sollte von AVM eigentlich ohnehin verhindert werden. Wenn eine FRITZ!Box einfach durch den angesteckten USB-Stick eines Angreifers eine andere Firmware startet, ist das zwar wie im schlechten Film, sollte aber (hoffentlich) mit der Realität nichts zu tun haben. Im Film da kommt der Trojaner ja manchmal schon auf das Gerät, wenn man den Stick daneben legt - vermutlich sind die verwendeten IPv4-Adressen wie 437.195.269.073 (um mal ein Schema aufzudecken) daran Schuld.

Mein Fazit: Es ist gar keine wirklich gute Idee, wenn so ein Gerät wie ein SOHO-Router einfach von einem eingesteckten Stick startet ... dann müsste im Minimum die Software auf diesem Stick auch mit einer Signatur versehen sein, die gegen Schlüssel im Bootloader geprüft werden kann. Alles das fehlt aber (derzeit) bei den FRITZ!Box-Modellen, zumindest bei denen, die man kaufen kann (im AVM-Labor mag es andere Prototypen geben).

 

[prisrak1]

ist schon eine interessante Argumentierung. Wie funktioniert es aber mit emulierten, oder den nfsroot Möglichkeiten? Ich würde schon sehr gern ein Systen von der Fritz.Box testen, gerade weil ich kene physische Version davon besitze.

 

[fesc]

Das könnte ich mir max. für eine 6591 vorstellen

Hat man Zugriff auf die shell kann man das startup.nsh skript auf der UEFI emmc partition editieren. Damit kann man dann booten von was man möchte, die entsprechenden USB treiber sind vorhanden. Zusätzliche filesystem-Treiber kann man leicht mittels frei verfügbarer .efi module nachladen, zumindest ein USB NIC (eine bestimmte ASIX variante, hab gerade das modell nicht da) ist direkt unterstützt und kann für Netzwerk-boot verwendet werden.