[Problem] Freetz auf F!B 4020 - Push_Firmware

Denkbar ... aber in meinen Augen auch unwahrscheinlich. Wozu der gut ist und warum der gerade dort liegt, steht (mehr oder weniger ausführlich und ggf. sogar mehr oder weniger richtig bzw. falsch) in diesem Thread: https://www.ip-phone-forum.de/threads/Übersicht-von-fritz-boxen-mit-junk-bytes-im-squashfs-image.286318/

Die dort verlinkte Dokumentation von Imagination Technologies ist unter dieser Adresse nicht mehr erreichbar, aber unter https://s3-eu-west-1.amazonaws.com/downloads-mips/documents/MD00541-2B-74K-PRG-02.14.pdf findet man sie wieder.

Bei NOR-Flash, der direkt am Bus hängt und in den Adressbereich des Prozessors eingeblendet wird (auch ohne Kopieren von A nach B), wäre das für mich logischer ... solange da nicht ein Controller für das SPI oder irgendwelcher anderer Code etwas in den Bereich bei 0xBFC00000 kopiert (bei NOR-Anbindung an den Memory-Bus wurde der Flash an einer entsprechend hohen Adresse eingeblendet, später kann das dank MMU ja nahezu beliebig umgemappt werden), spielt das wohl nicht wirklich eine Rolle.

Es würde zumindest nicht direkt erklären, warum das System gar nicht erst startet (es sei denn, es verwendet NMIs für den "regulären" Betrieb) ... es könnte sich ggf. bei einem NMI dann aufhängen, weil die Interrupt-Behandlung keinen gültigen Code beinhaltet.

Ich will es nicht vollkommen ausschließen und es ist (ggf. mit den Erläuterungen aus dem oben verlinkten Thread und mit den Sourcen für das Entpacken und Suchen des NMI-Vectors) auch kein großes Kunststück, von Hand ein passendes Image zusammenzuklöppeln für den eigenen Test, aber ich bin erst mal sehr skeptisch und würde deshalb jetzt nicht hingehen (aber ich müßte es ja auch nicht machen) und ein Restaurieren des NMI-Vectors in das Packen eines Images mit "hidden root" einbauen.

Ich bin mir nicht mal sicher, ob der NMI-Vector hier tatsächlich gebraucht würde (wie gesagt, wie kommt der Code bei einem SPI-Flash (Und die 4020 hat doch wohl welchen? "Richtiger" NOR-Flash wäre deutlich teurer.) überhaupt an die richtige Adresse und warum sollte das jemand beim Ummappen genauso machen, als würde es sich um NOR-Flash handeln) oder ob das nicht nur ein Relikt im AVM-Code ist, für das es - bei einem System, welches grundsätzlich mit diesem "hidden root image" arbeitet - einfach keine passenden bedingten Anpassungen dort gibt und das so am Ende sogar noch in ARM-Modellen mit diesem Image-Aufbau zu finden wäre (wo es diese Konstruktion an 0xBFC00000 m.W. gar nicht gibt), weil es vom AVM-Programm zum Packen der Images einfach immer mit eingebaut wird (ggf. noch in der "richtigen" Version, wenn er wirklich von Bedeutung sein sollte).

Dafür spricht in meinen Augen auch, wenn das stur an 0xBE0000 im Image liegt ... diese Verschiebung ergibt sich ja auch daraus, daß da ein Bootloader mit einer Größe von 128 KB vor der Kernel-/Dateisystem-Partition im Flash liegt muß und mit dieser zusätzlichen Verschiebung (diese 128 KB ergeben in Hex dann 0x20000 und wenn man das zu dieser Verschiebung im Image hinzuaddiert, landet man bei 0xC00000 und das ist die Adresse des NMI-Vectors, wenn der betreffende Speicherbereich für den Flash an Adresse 0xBF000000 eingeblendet würde) erst, paßt dann die Adresse auch.

Nun weiß man zwar nichts Genaueres vom Innenleben der 4020 und von deren Flash-Aufbau (zumindest ich nicht) ... aber es erscheint mir auch unwahrscheinlich, daß AVM immer nur Boxen mit 128 KB-Bootloadern (bzw. mit Partitionen für den Bootloader in dieser Größe) unters Volk bringt.

Aber wie gesagt ... ich will es nicht ausschließen, glaube aber bis zum Beweis des Gegenteils eher nicht daran, daß das hier wirklich ein Problem darstellt.
 
Irgendwie verstehe ich nicht, welches Problem gerade analysiert wird und vor allem wieso.

Das von Freetz erstellte, in die richtige mtd-Partition geschriebene und insbesondere keinen NMI-Vektor enthaltende Image startet. Punkt. Startet problemlos, s. #10 in diesem Thread und auch Issue #43 auf GitHub.

Das Problem, wo man nach den Ursachen dafür suchen sollte, ist (dachte ich zumindest), warum das Flashen mittels push_firmware nicht funktioniert. Theoretisch kann es an dem Format liegen, dann würde push_firmware das Image einfach nicht entpacken können. Aber bevor wir theoretisch was vermuten, soll uns lieber @Jott-Emm sagen, was genau er versucht hat und wie sich push_firmware dabei verhalten hat. Denn Stand jetzt haben wir lediglich die folgende Aussage und nichts mehr...

Die serielle habe ich eigentlich benutzt, um zu sehen, was die Box denn macht. Mittels push_firmware und FB aus - an wollte es partout nicht klappen.

Offen gesprochen ist für mich ein Bedienfehler noch längst nicht ausgeschlossen.
 
Zuletzt bearbeitet:
Sind die Infos/Daten einer 4020 nun schon vorhanden oder werden noch benötigt? (oder gibt's nen Unterschied im Bootloader, zur Behandlung via push_firmware, ect.?)

Hier schon mal "the first datas from supportdata" nach Recovery auf 6.50 und bestätigen der Sprachwahl "deutsch" danach direkt die Supportdaten erstellt.
Code:
##### TITLE Version 147.06.50
##### TITLE SubVersion
##### TITLE Produkt Fritz_Box_HW219
##### TITLE Datum Thu Jan  1 01:03:18 CET 1970
##### BEGIN SECTION Support_Data Supportdata Linux fritz.box 2.6.32.61 #1 Wed Mar 30 15:21:05 CEST 2016 mips GNU/Linux Version 147.06.50
Support Data
------------
Thu Jan  1 01:03:18 CET 1970
2.6.32.61
HWRevision   219
HWSubRevision   1
ProductID   Fritz_Box_HW219
SerialNumber   0000000000000000
annex   Ohne
autoload   yes
bootloaderVersion   1.2779
bootserport   tty0
country   049
cpufrequency   775000000
firstfreeaddress   0x8113DB4C
firmware_info   147.06.50
firmware_version   avm
flashsize   nor_size=0 sflash_size=16MB nand_size=0MB
language   de
Nun weiß man zwar nichts Genaueres vom Innenleben der 4020 und von deren Flash-Aufbau
ein Bild der Platine von beiden Seiten würde Dir helfen? Wenn ja, schraub ich meine (F511) gerne auf und liefere die Bilder, ebenso wie Ausgaben-Logs via UART (falls ich bei der 4020 wie bei der 7390 erfolgreich bin - anders als bei der 6490..)
 
ein Bild der Platine von beiden Seiten würde Dir helfen? Wenn ja, schraub ich meine (F511) gerne auf und liefere die Bilder,
Die relevanten Bauteile liegen bei der 4020 unter einem EMI-Shield. Wenn du dir zutraust dieses vorsichtig (mit einem geeigneten Kunststoffhebel) abzuhebeln dann wären die gewonnen Informationen vielleicht ganz interessant.
 
Bin "relativ" schmerzfrei - ich werde bei Bedarf und weiterer Diagonse/Infosammlung gerne zur Not die 4020 opfern ;)
Der Text stand seid heute nacht.... Die 4020 hats natürlich überlebt :D

--- aktualisiert ---

Recovery auf 6.50 + 6.83 sind via Wireshark als Paketmitschnitt verfügbar. Falls @PeterPawn diese gebrauchen kann - bitte kurze Info.

Bilder der Platine (ohne EMI-Shield) anbei.
 

Anhänge

  • 20180826_200911.jpg
    20180826_200911.jpg
    2 MB · Aufrufe: 21
  • 20180826_200903.jpg
    20180826_200903.jpg
    1.8 MB · Aufrufe: 21
Bilder der Platine (ohne EMI-Shield) anbei.
Danke! Leider ist auf dem SoC ja noch das Wärmeleitpad drauf aber ich denke darunter würde man wohl sowieso nur den Qualcomm QCA9561 vorfinden, daher auch nicht weiter schlimm.

Ich vermute mal auf der Rückseite des PCB waren auch keine weiteren bedeutsamen Bauelemente vorhanden? Wenn ja dann scheint bis auf die WiFi-Verstärker, den RAM und den Flash alles wichtige (CPU, WiFi und Ethernetswitch mit PHYs) im SoC (QCA9561) zu stecken. Der LV595 beziehungsweise 74LV595 scheint für die Ansteuerung der LEDs verwendet zu werden.

Ansonsten halt noch ein Winbond W971GG6KB-25 für die 128MB DDR2-RAM, ein Macronix MX25L12835F der die 16MB NOR-Flash (SPI) zur Verfügung stellt, 3 WiFi-Verstärker und die 5 Übertrager für die LAN-Ports.
 

Anhänge

  • 20180826_225343.jpg
    20180826_225343.jpg
    287.9 KB · Aufrufe: 13
  • 20180826_225552.jpg
    20180826_225552.jpg
    1.2 MB · Aufrufe: 13
  • Like
Reaktionen: NDiIPP
Hallo!
Nun habe ich Zeit gefunden, mich mit meiner zweiten Fritz!Box 4020 zu beschäftigen - mit für mich erstaunlichen Ergebnissen.
Der Wireshark-Mitschnitt des Firmware-Recovers auf 6.83 hat ergeben, dass die Box sich genauso verhält, wie sie soll. Anschließend habe ich ein Freetz-Image mit push_firmware aufgespielt - erfolgreich und fehlerfrei! Insofern hat @PeterPawn recht, wenn er vermutet, dasss das Verhalten der 4020 nicht vom "üblichen Verhalten" abweicht.
Da ich bei meiner ersten Box zuerst ganz genauso vorgegangen bin (mit Ausnahme des Wireshark-Mitschnittes), vermute ich, dass entweder diese Box im Bootloader einen Fehler hat oder wie von @Shirocco88 vermutet, am fehlerhaften Image.
Aber jetzt funktioniert alles so, wie gewünscht, auch dank dieses Forums. Das muss hier mal gesagt werden. Dürfen. :)

Bei mir gibt's auch einen Wireshark-Mitschnitt (ca. 17 MB). Bei Bedarf, bitte bei mir melden.
 
Danke, ich habe inzwischen von @stoney vieles an notwendigen Informationen zur 4020 erhalten ... bis hin zu zwei Recovery-Mitschnitten (06.50 und 06.83).
 
Hallo,

ich habe auch eine 4020 rumstehen, von der ich mir erhoffe, bei ihr mit Hilfe von Freetz von bridge-Mode aktivieren zu können um ihn als Repeater/Access Point nutzen zu können.
Die Fritz.Box hängt momentan via PowerLAN hinter einem Kabel-Router (auf dem ein WLAN läuft). Sie soll selber das gleiche WLAN bereitstellen, jedoch kein eigenes Subnetz aufmachen, da sich die Clients vom Kabel-Router und die Clients vom 4020 sonst nicht sehen.
Wisst ihr, ob das mit Freetz geht? @stoney @PeterPawn @Jott-Emm

Danke
 
danke, hatte gestern ewig danach gegoogelt aber bin nicht fündig geworden. Manchmal kann es so einfach sein
 
Hi,

um meine 3270 mit UMTS Stick gegen eine aktuelle FB mit LTE Stick zu ersetzen, habe ich mir nen Huawei 8372 (3372 sollte es auch tun) gekauft und in der Bucht ne benutzte 4020. Ziel der Übung, Freetz auf der kleinen Box für OpenVPN um das Bundle "Box und LTE Stick" in mein Netzwerk zu integrieren.
Mit den Infos hier und einer Anleitung für push_firmware ist es mir ohne große Probleme gelungen, mein selbst kompiliertes Images einzuspielen.
Meine Box kam mit der Original Firmware 7.01, die habe ich auf 6.83 mit dem AVM Tool recovert (die Links dazu findet man im Netz - vermutlich hätte es auch ohne geklappt).
Dann meinen PC eine feste IP aus dem 192.168.178 er Subnetz gegeben, Freetz Linux in der Virtual Box gestartet. Mit Putty eingeloggt, das komplilierte Image mit tar xvf ausgepackt und mit push firmware das kernel.image geschrieben.

Code:
root@freetz-linux:/home/freetz/freetz-devel_29_02_2020_FB4020_OK/tools# ./push_firmware /home/image/var/tmp/kernel.image 192.168.178.1
ftp command found.

!!! WARNING !!! WARNING !!! WARNING !!! WARNING !!! WARNING !!!
!!!  THERE IS NO WARRANTY AT ALL !!! USE AT YOUR OWN RISK   !!!

Are you sure, that you want to flash /home/image/var/tmp/kernel.image directly to mtd1?

proceed (y/n)

* You should now reboot your box (192.168.178.1).
         Waiting for box to shut down.
         Tip: switch off, if reboot is not detected because it happens too quickly
   .........................

* No reply from box (192.168.178.1). Assuming switch-off or restart.
         Trying to re-detect box.
   .....

* Box is back up again.
         Initiating transfer.
         Tip: switch off/on box several times, if FTP client cannot log in ...

Debugging on (debug=1).
---> TYPE I
---> MEDIA FLSH
---> PASV
---> STOR mtd1
---> REBOOT
---> QUIT

das wars, die Box neu gestartet und siehe da, es läuft 7.01 mit Freetz auf Port 81. LTE Stick ran und Internet mit Tethering läuft ;-)
 
Zuletzt bearbeitet:
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.