Seite 3 von 3 ErsteErste 123
Ergebnis 41 bis 52 von 52

Thema: Fehlende Bestandteile im OpenSource-Paket von AVM

  1. #41
    IPPF Tausender
    Registriert seit
    14.04.2010
    Beiträge
    1.419
    Na am besten wenn Heise am Montag über die neue Fritzbox auf der Cebit berichtet da die Kommentarfunktion exesiv nutzen. Oder wir streuen das Gerücht das der Verfassungsschutz aus AVM verbietet die Sourcen korrekt zu veröffentlichen.
    Anbieter: Telmex Prodigy Infinitum
    FB 7490 FW: 06.80-43382 INTERN Annex=A
    DSLAM Broadcom 161.242 (Telmex Kupfer)
    Fritz!Fon MT-F FW: 3.88, MT-C
    Nokia E71-2 FW: 510.21.009, Nokia N9 40.2012.21-3_PR_006
    Festnetz: Analog Telmex
    VoIP: 1&1, Sipgate, FreeVoIPDeal

  2. #42
    IPPF-Fan
    Registriert seit
    27.05.2010
    Beiträge
    194
    @PeterPawn: Interessante Entdeckung, freue mich auf dein Update wenn es aktuelle Quellen gibt.
    @er13: nicht vergessen dass man die Quellen einfach so veröffentlichen muss laut GPL! Sondern auf Anfrage!
    Zb die für neueste 7320 6.30 (13.7.2015) kamen am 21.2.2017, nachdem ich Anfang 02/17 anfragte, das ist also soweit Okay. (Ich nutze eigenlich 7320 6.50 Alien mit rk seit fast 1 Jahr, sollte es in Freetz auch geben)
    Für 7390 6.8 fragte ich gleichzeitig an, da kam bis heute über 1 Monat später noch nichts. Hab Anfang März nochmal gefragt, ohen Antwort bislang.
    Für 7490 hingegen kam innerhalb 1 Woche nach meiner Anfrage der Quellcode. Evtl deshlab auch inklusive dieser riesigen Symbol-Datenbank.
    Für den 546 6.5 (29.7.2016) gibts keine Quellcode, dafür hab ich vor langem nachgefragt, weiss nicht mehr wann (ich vewende 6810 sourcen solange für Module...)

    Man kann also zusammenfassend und sagen, solang niemand ne kurze Mail schreibt braucht keiner herumzujammern!
    Die meisten verstehen den Zusammenhang nicht so ganz und schreiben statdessen im Forum/Trac - was aber nichts ändert
    Geändert von opto (18.03.2017 um 17:44 Uhr)

  3. #43
    IPPF Siebentausend-VIP Avatar von PeterPawn
    Registriert seit
    10.05.2006
    Ort
    Berlin
    Beiträge
    7.732
    @opto:
    Ich werde trotzdem dabei bleiben, den Finger eher "öffentlich" in diese Wunde zu legen, zumal ich bei anderen Anfragen (nicht immer unter eigenem Namen, weil es eben auch mal "Verstimmungen" gibt und die Daten ohnehin eher für Kunden gebraucht wurden, weil mein "Arsenal" an Boxen recht übersichtlich ist, was die eigenen Modelle angeht) ähnliche Erfahrungen wie Du machen mußte.

    Daher kritisiere ich im Normalfall (die Feststellung zur 153.06.54 war da eher ein Ausreißer, weil mich die 7580 bisher nicht tangierte und für die 7490 - auf der ansonsten meine Recherchen in den OSS-Paketen basieren - kamen die Pakete immer recht zeitnah) nicht den Zeitpunkt der Bereitstellung von OpenSource-Paketen, sondern deren Umfang und Inhalt - wobei ich diese Anfragen zur Bereitstellung inzwischen tatsächlich weitgehend anderen überlasse.

    Das "notwendige Nacharbeiten" (u.a. beim "avm_kernel_config_area", was ja hier mal der Aufhänger für diesen Thread war) ist aber eben absolut nicht im Sinne der GPL und meine letzte Anfrage in dieser Richtung nach dem passenden, vollständigen Quell-Code stammte vom 19.05.2016 (kriegte damals die Ticket-ID 433246) - diese wurde dann am 15.06.2016 mit dem Hinweis, daß ich die Quellen unter dem bekannten Link abrufen könne, auch "erledigt"; dabei hatte sich am Umfang der Quellen aber bekanntermaßen nichts wirklich Relevantes geändert.

    Allerdings gibt es praktisch keine "Entschuldigung" dafür, wenn AVM die Quellen für neu veröffentlichte Updates erst mit einer erheblichen Verzögerung "nachreicht" - wie es hier ja dann wohl für die 7390 geschieht, wenn Du dahingehend nachgefragt hast. Die Dateien müssen ja zum Zeitpunkt des Erstellens der Firmware bereits existiert haben und dann sind es mittlerweile fast 6 Wochen, seitdem die 84.06.80 erschienen ist - das ist vermutlich im Beamtenleben noch als "unmittelbare Reaktion" zu bewerten, im "real life" wohl eher nicht.

    Da überholt dann mit einiger Wahrscheinlichkeit die nächste Firmware-Version (sollte es die 06.83 auch für die 7390 geben) die Veröffentlichung der Quellen für die 06.80 - wobei das an dieser Stelle AVM gar nicht der Notwendigkeit enthebt, die Quellen auch für die "outdated version" 06.80 bereitzustellen, nachdem man diese in Umlauf gebracht hat. Man könnte höchstens noch erklären, daß die Quellen sich nicht unterscheiden ... was angesichts der fehlenden "_avm_kernel_version_info" in den Quellen sogar stimmen könnte.

  4. #44
    IPPF-Fan
    Registriert seit
    27.05.2010
    Beiträge
    194
    Das "nicht öffentlich" per eMail ist leider erforderlich da avm erklärt dass nur nach Anfrage an fritzbox_info@avm.de was kommt. Das steht in den info.txt zb ftp://ftp.avm.de/fritz.box/fritzbox....utsch/info.txt am Ende
    Man könnte das in die Öffentlihckeit rücken, indem man einen sticky Thread macht in dem jeder postet
    -Datum
    -Box
    -Firmware
    -TicketID von AVM
    Später per edit (evt von moderator) wenn verfügbar

    Wenn man irgendwas an dem Ablauf von AVM ändern möchte, muss man zuerst mal das Problem dokumentieren.
    Dazu kommt halt noch dass die .config nicht passt oder Dinge wie config-area ganz fehlen
    Wenn man so einen thread macht kann man dann auch sagen hier hats so und so lange gedauert. Aber solange man nicht weiss ob überhaupt jemand nachfragte bleibts ungewiss. Darauf vertrauen dass andere fragen hab ich aufgegeben und schreib kurz nach neuer Frirmware einen Einzeiler an AVM
    unmittelbar/unverzüglich wird meist als 2 Wochen angesehen. Wobei ich AVM schon vorschlug das ganze zu automatisieren. Scheint aber zu kompliziert oder ist einfach nicht gewünscht (auch wenn AVM sich selbst als angetan vom Modding darstellt)

  5. #45
    IPPF Siebentausend-VIP Avatar von PeterPawn
    Registriert seit
    10.05.2006
    Ort
    Berlin
    Beiträge
    7.732
    So, ich habe mir den Kernel der 7580 mal etwas genauer angesehen ... der hat am Beginn irgendwie drei zusätzliche (Assembler-)Instruktionen:
    Code:
    00000000  12 91 ed fe a8 30 3f 00  00 00 50 80 81 12 ed fe  |.....0?...P.....|
    00000010  85 de 2d 00 00 00 50 80  01 02 5a 07 6d de 2d 00  |..-...P...Z.m.-.|
    (ich habe gerade keinen MIPS-Disassembler zur Hand, um deren Inhalt zu verstehen, aber das dritte 32-Bit-Wort ist die Ladeadresse des Kernels, sprich: das Ziel für das Entpacken, was aber 12 Byte weiter noch einmal steht) ... aber danach kommt dann offenbar doch wieder ein "normales" LZMA-komprimiertes Image, auch wenn die ".config" aus dem OSS-Paket für die 153.06.53 uns etwas anderes suggerieren will (und ich habe extra eine "frisch ausgepackte" Datei verwendet):
    Code:
    # grep CONFIG_KERNEL .config
    CONFIG_KERNEL_GZIP=y
    # CONFIG_KERNEL_BZIP2 is not set
    # CONFIG_KERNEL_LZMA is not set
    # CONFIG_KERNEL_LZO is not set
    Hier habe ich natürlich diesmal zuerst auch noch anhand der 06.53-Firmware geprüft, daß AVM da nicht wirklich die Kompression gewechselt hat - auch die 06.53 hat einen LZMA-komprimierten Kernel.

    Damit ist das dann auch wieder relativ leicht zu entpacken ... man muß nur auf die Offsets halt immer diese drei zusätzlichen 32-Bit-Worte aufaddieren. Um das etwas flexibler zu gestalten, habe ich das "unpack_kernel.sh" aus dem "avm_kernel_config"-Verzeichnis so angepaßt, daß vom ursprünglichen Offset in 32-Bit-Schritten (zusätzliche MIPS-Instruktionen sollten hier immer 32-Bit groß sein) nach dem Base64-Äquivalent des erwarteten LZMA-Headers (0x5d00008000) gesucht wird und dann die Verschiebung des Headers auf alle Offsets beim Lesen aufaddiert wird. Findet sich dabei kein Header mit dem erwarteten Inhalt innerhalb der nächsten 128 Byte, bleiben die Offsets unverändert und das Entpacken wird trotzdem versucht.

    Damit klappt dann auch das Entpacken des Kernels für die 7580 (und auch die 7560) und das sogar so weit, daß das verwendete "lzma -d" sich nicht über ein vorzeitiges Ende der Daten beschwert.

    Das Ergebnis sieht dann auch wieder gut aus (auf einmal stehen da wieder lesbare Zeichenketten im entpackten Kernel) und auch der AVM-Konfigurationsbereich existiert tatsächlich.

    Da der Kernel an die Adresse 0x80500000 entpackt wird, muß man aber einigermaßen hin und her rechnen, wenn man die tatsächlich verwendeten Offsets finden will. Jedenfalls fehlt der Name für den Start des Bereiches (__avm_kernel_config_start) wohl auch bei den exportierten Symbolen, denn in der "kallsyms" taucht er nicht auf. Dort findet sich nur "__avm_kernel_config_end", was bei der 06.54 den Wert 0x80E58000 hat - damit ist der Beginn (ausgehend von den 96 * 1024 Byte, die da in der vmlinux.lds.S bei der 7580 zu finden sind) wohl bei 0x80E40000 zu suchen, was dann in der entpackten Kernel-Datei dem Offset 0x00940000 entspricht.

    Und siehe da, an dieser Stelle finden sich dann durchaus bekannte Strukturen:
    Code:
    00940000  80 e4 00 04 00 00 00 01  80 e4 fc fc 00 00 00 02  |................|
    00940010  80 e4 fc 3c 00 00 00 05  80 e4 a7 70 00 00 00 06  |...<.......p....|
    00940020  80 e4 52 a4 00 00 01 04  80 e4 00 34 00 00 01 06  |..R........4....|
    00940030  00 00 00 00 d0 0d fe ed  00 00 52 6d 00 00 00 38  |..........Rm...8|
    00940040  00 00 4b 90 00 00 00 28  00 00 00 11 00 00 00 10  |..K....(........|
    00940050  00 00 00 00 00 00 06 dd  00 00 4b 58 00 00 00 00  |..........KX....|
    00940060  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 01  |................|
    00940070  00 00 00 00 00 00 00 03  00 00 00 04 00 00 00 00  |................|
    00940080  00 00 00 01 00 00 00 03  00 00 00 04 00 00 00 0f  |................|
    00940090  00 00 00 01 00 00 00 03  00 00 00 1c 00 00 00 1b  |................|
    009400a0  6c 61 6e 74 69 71 2c 67  72 78 35 30 30 00 6c 61  |lantiq,grx500.la|
    009400b0  6e 74 69 71 2c 78 72 78  35 30 30 00 00 00 00 03  |ntiq,xrx500.....|
    009400c0  00 00 00 23 00 00 00 26  45 41 53 59 33 35 30 20  |...#...&EASY350 |
    009400d0  41 4e 59 57 41 4e 20 28  47 52 58 33 35 30 29 20  |ANYWAN (GRX350) |
    009400e0  4d 61 69 6e 20 6d 6f 64  65 6c 00 00 00 00 00 01  |Main model......|
    Wie sich diese jetzt genau aufteilen und was da beim AVM-Kernel alles in diesem Bereich enthalten ist, ist aber ein Thema, was ich erst heute nachmittag weiter untersuchen werde.

    @er13:
    Ob Du das nun so ähnlich in der Freetz-Version nachziehst oder mein Skript zum Entpacken nimmst, bleibt Deine Entscheidung - aber das Entpacken des Kernels sollte damit abgehakt sein. Den Versuch, ob das "extract_ikconfig" aus den Kernel-Quellen im entpackten Kernel jetzt die komprimierte ".config" findet oder nicht, habe ich noch nicht unternommen.

  6. #46
    IPPF Fünfhunderter
    Registriert seit
    20.12.2005
    Beiträge
    862
    Code:
    00000000  12 91 ed fe a8 30 3f 00  00 00 50 80 81 12 ed fe  |.....0?...P.....|
    00000010  85 de 2d 00 00 00 50 80  01 02 5a 07 6d de 2d 00  |..-...P...Z.m.-.|
    Zitat Zitat von PeterPawn Beitrag anzeigen
    der hat am Beginn irgendwie drei zusätzliche (Assembler-)Instruktionen:
    (ich habe gerade keinen MIPS-Disassembler zur Hand, um deren Inhalt zu verstehen, aber das dritte 32-Bit-Wort ist die Ladeadresse des Kernels, sprich: das Ziel für das Entpacken, was aber 12 Byte weiter noch einmal steht)
    Ich denke nicht, dass es irgendein Code ist. Das sieht stark nach einer Datenstruktur aus, bestehend aus
    1. einem Magic (LE-32-Bit-Wort) 0xFEED9112 (sieht verdammt ähnlich dem TI-AR7-Magic, der in EVA verwendet wird: 0xFEED1281)
    2. einem noch unbekannten Feld (LE?-32-Bit-Wort), vermutlich irgendeinde Länge
    3. der LoadAddr (LE-32-Bit-Wort), wie Du schon selber festgestellt hast, diese steht 2 Mal da


    Edit: vermutlich ist die Suche within 128 bytes nicht wirklich notwendig, man kann auf feste Offsets gehen, es wird bei 12 extra Bytes bleiben, man muss nur deren Bedeutung verstehen. Daraus resultiert übrigens eine weitere Aufgabe für Replace-Kernel: man muss lzma2eva all das beibringen bzw. diese 12 Bytes dem Output von lzma2eva hinzufügen.

    Edit2: das 2.te Feld ist eindeutig ein Längenfeld. EntryAddr (0x8050E100 bei 7580_06.53) ist in der Datei 2 Mal zu finden:
    1. 1stHeaderOffset(0) + LängenFeldAus1stHeader(4141224) + 20 = 4141244
    2. 2ndHeaderOffset(12) + LängenFeldAus2ndHeader(3006085) + 20 = 3006117
    Und da 3006117 nun mal deutlich kleiner ist als die Größe der gesamten Datei schlussfolgere ich daraus, dass kernel.image bei 7580 nicht nur den Kernel enthält, sondern hinten noch fast 1MB irgendwelcher anderer Daten. Die Größe von lzmaCompressedLen(3006061) bestätigt es.

    Edit3: Vermutung - binäre Firmware irgendeiner verbauten Hardware-Komponente
    Geändert von er13 (20.03.2017 um 02:17 Uhr)

  7. #47
    IPPF Siebentausend-VIP Avatar von PeterPawn
    Registriert seit
    10.05.2006
    Ort
    Berlin
    Beiträge
    7.732
    Mir auch recht ... vielleicht erklärt das auch irgendwie die doppelte TI-Prüfsumme (zumindest deren Magic) am Ende des Kernels - ggf. läßt sich mit dieser Prüfsumme der Inhalt aufsplitten, wenn man den Teil findet, für den der "innere" CRC32-Wert paßt. Der "äußere" gehört zum gesamten "kernel.image", das habe ich schon letztens geprüft, als ich das erste Mal diese zwei Magics angesprochen habe.

    Bei mir lasse ich es aber trotzdem bei der Suche nach dem (ersten) LZMA-Header ... wer weiß, wann der nächste Kernel mit anderen Offsets auftaucht.

    Auf alle Fälle sollte die Größe des entpackten Images an Offset 32 mit dem Wert 0x9a1080 (10..096.768) in etwa stimmen und - wie gesagt - "lzma" beschwert sich auch nicht, was meist ein gutes Zeichen dafür ist, daß der komprimierte Payload auch "abgeschlossen" ist.

    Schaut man dann hinter den ersten Teil nach Deiner Vermutung, landet man bei Offset 0x2dde9d (Länge des ersten komprimierten Payloads (0x2dde6d) + 0x30 als Start des Payloads) und da kommen dann (um die "krumme Verschiebung" bereinigt) drei 32-Bit-Worte:
    Code:
    42 8f a9 68   00 00 00 00   00 e1 50 80
    Das wäre dann ggf. im dritten noch einmal die Entry-Adresse ... und danach kommt dann (vermutlich mit Alignment) tatsächlich noch ein weiterer LZMA-Header (bei 0x2ddec8). Geht man von diesem wieder die bekannten 28 Byte (0x1c) zurück, landet man an 0x2ddeac und das sieht dann tatsächlich nach einem weiteren "image header" aus:
    Code:
    002ddea0  68 00 00 00 00 00 e1 50  80 00 00 00 07 b0 ed fe  |h......P........|
    002ddeb0  c3 51 11 00 90 70 f6 8d  01 02 5a 07 ab 51 11 00  |.Q...p....Z..Q..|
    002ddec0  14 ab 24 00 d9 0f ec c8  5d 00 00 80 00 00 00 00  |..$.....].......|
    002dded0  00 00 02 af c7 74 e7 5f  05 50 97 d4 34 07 81 6f  |.....t._.P..4..o|
    Die dort stehenden Daten wären dann 0x1151ab (1.135.019) Byte komprimiert und sollten beim Entpacken 0x24ab14 Byte (2.403.092) ergeben - und genau das machen sie auch. Schaut man dann dort hinein, ist das am Ende ein weiterer Linux-Kernel ... dabei fällt mir dann wieder auf und ein, daß es in den 7580-Quellen zwei verschiedene Setups für den Kernel gibt: grx500 und grx500_bootcore.

    Jetzt wäre natürlich mal eine Entwicklerdokumentation für den GRX500 spannend ... durchaus denkbar, daß da irgendetwas im Hintergrund - quasi als Hypervisor - werkelt und schon hier die ersten Ansätze der ja mal angedachten Virtualisierung auch auf solchen Embedded-Devices existieren, mit denen die verschiedenen Funktionen voneinander abgeschottet werden könnten. Das wäre jedenfalls die erste Erklärung, die mir spontan für diesen "doppelten Kernel" einfallen würde ... ob da wirklich etwas dran sein könnte, muß man aber erst mal in aller Ruhe und Gründlichkeit anhand der sichtbaren Bestandteile (in erster Linie der Zeichenketten in den entpackten Versionen) und der Kernel-Quellen (insb. des Unterschieds zwischen "bootcore" und "nicht bootcore") untersuchen.



    Wie auch immer ... ich habe die Geschichte mit dem "avm_kernel_config" angepaßt an die Möglichkeit, daß es eine abweichende Größe des Bereiches geben könnte ... wobei das nur beim "extract_kernel_config_area" von Interesse war. Bei der Generierung des Assembler-Files spielt die Größe des Bereiches ja nicht wirklich eine Rolle, da wird halt das ausgegeben, was in der Eingabedatei steht - jedenfalls jetzt, denn zuvor gab es dort nur einen DTB und nicht mehrere. Das habe ich aber geändert und jetzt werden auch mehrere dieser DT-BLOBs sauber erzeugt, wenn mehrere in der Eingabedatei stehen.

    Die korrekte Größe des Konfigurationsbereichs braucht man also nur beim Auslesen aus dem entpackten Kernel (extract_...) und beim Patchen des Linker-Files für den Kernel. Mir fällt spontan keine andere Möglichkeit ein, als das aus den AVM-Quellen zu extrahieren (aus der vmlinux.lds.S) und dann genauso auch wieder zu patchen. Zumindest dann, wenn man dieselbe Größe wie AVM verwenden will (oder muß) ... ich weiß aber nicht, ob die wirklich bei AVM statisch hinterlegt ist oder einfach (nach Alignment für den Konfigurationsbereich auf die nächste 32 KB-Grenze) anhand des Symbols für __avm_kernel_config_end ermittelt wird.

    Irgendwelche Skript-Dateien für das Ermitteln dieser Größe und für das Patchen der "vmlinux.lds.S" (da funktionieren ja auch die Ankerzeilen für einen Patch nicht mehr, wenn da andere Zahlen stehen) fehlen noch in meinem Repository - das sollte aber für Freetz keine entscheidende Rolle spielen und die anderen Änderungen sollten erst einmal hinreichend sein, damit man auch einen Konfigurationsbereich für die 7580 und 7560 erzeugen kann.



    Wie man die Geschichte mit den zwei Kernel-Images nun managen will, muß man sich auch in Ruhe überlegen ... ggf. reicht es für das "replace kernel" im Freetz ja bereits, wenn man nur das erste Image austauscht (das zweite halte ich für die "bootcore"-Inkarnation, aber das muß nicht stimmen) und das zweite einfach beläßt.

    Ach so ... die zweite TI-Prüfsumme am Ende (also die "innere", somit eigentlich die erste - jedenfalls die, welche bei der 06.54 den Wert 0x090b48a7 hat) stimmt dann auch wieder für das zweite Image ... von 0x2ddeac aus in der Länge 0x115200 berechnet.

    - - - Aktualisiert - - -

    Ich kannte die von Dir im letzten Freetz-CS verlinkte WHMF-Seite mit den Strukturen beim LZMA-Kernel in der EVA noch gar nicht (bei so einem Wiki ist eben sequentielles Lesen eher schlecht möglich) ... damit kann man ja - bei Kenntnis des Inhalts der Prüfsummen-Felder - sowohl die Daten verifizieren als auch das Entpacken des zweiten Kerns automatisieren, wenn die dort gezeigten Strukturen auch bei der 7580 verwendet werden für das "Verschachteln" zweier Kernel-Images.
    Geändert von PeterPawn (21.03.2017 um 00:57 Uhr)

  8. #48
    IPPF Fünfhunderter
    Registriert seit
    20.12.2005
    Beiträge
    862
    Zitat Zitat von PeterPawn Beitrag anzeigen
    Ich kannte die von Dir im letzten Freetz-CS verlinkte WHMF-Seite mit den Strukturen beim LZMA-Kernel in der EVA noch gar nicht ... damit kann man ja - bei Kenntnis des Inhalts der Prüfsummen-Felder - sowohl die Daten verifizieren als auch das Entpacken des zweiten Kerns automatisieren, wenn die dort gezeigten Strukturen auch bei der 7580 verwendet werden für das "Verschachteln" zweier Kernel-Images.

    Umgesetzt in r14181.
    Denkbare Weiterentwicklungen wären:
    1. Prüfung der Checksummen
    2. Split-Modus (um z.B. nur eines der Kernels austauschen zu können/müssen)


    Deine heutigen "avm_kernel_config"-Commits habe ich gelesen. Muss mir überlegen, wie ich das einbaue. Bisher wurde in Freetz Deine gestripte avm_kernel_config.h verwendet und gar nicht die aus dem Kernel-Baum. Auch die Binaries wurden nicht speziell für jedes FREETZ_KERNEL_LAYOUT bzw. FREETZ_AVM_SOURCE_BOXID_XX_YY kompiliert, wie es nun der jetzige Aufbau quasi verlangt. Muss vermutlich Deine avm_kernel_config-Sources in den Kernel-Baum kopieren und dort FREETZ_AVM_SOURCE_BOXID_XX_YY spezifisch übersetzen.

  9. #49
    IPPF Siebentausend-VIP Avatar von PeterPawn
    Registriert seit
    10.05.2006
    Ort
    Berlin
    Beiträge
    7.732
    Ich habe gesehen, daß Du Freetz an den Stand aus dem YourFritz-Repo angepaßt hast ... allerdings hatte ich wohl den einen Patch (zum Ändern der vmlinux.lds.S) herausgenommen, weil der unter die weiter oben angetexteten "fehlenden Skript-Files" fallen sollte, denn als Patch-File funktioniert das ja bei abweichender Größenangabe nicht richtig.

    Das hat nun aber vermutlich direkte Auswirkungen auch für die 7490 (bzw. alle VR9-Modelle) beim "replace kernel" ... jetzt fehlt dort wohl der Patch und der Bereich wird beim Linken nicht eingebunden. Ich hatte nicht damit gerechnet, daß Du das so schnell nachziehst ... wir/Du/ich müssen nun irgendeine funktionierende Lösung finden (ich kann den Patch auch wieder reinnehmen, dann schlägt der eben bei der 7580 einfach fehl), sonst fällt der nächste Tester beim "replace kernel" auf die Nase und Du hast unnötige Tickets im Trac.

    Das Übersetzen mit den jeweils aktuellen Kernel-Files kann man leider nicht verhindern oder sinnvoll umgehen ... die Definitionen der Tags (in avm_kernel_config_tags_irgendwas) sind unterschiedlich (halt "enum"s mit unterschiedlich vielen Werten) und selbst wenn man hier jetzt die bekannten zwei Varianten beim "relocate..." testen könnte, kann ja AVM jederzeit mit einer weiteren Variante um die Ecke kommen.

    Die Änderung im Makefile und dem einen Include-File auf den Symlink mit dem Namen "linux" (der auf die Basis der Kernel-Quellen zeigen soll) für die Suche nach der "libfdt" und der "avm_kernel_config.h", hast Du ja sicherlich gesehen ... das müßte ja halbwegs zum Freetz passen, notfalls mußt Du eben das Makefile patchen.

    Ich bin dann aber an der Stelle ins Grübeln (und die anschließende Recherche, die ich aber nicht konzentriert durchgehalten habe) verfallen, wo es um den korrekten Pfad zum Loader-Skript ging, wenn da auf einmal die Prozessor-Architektur in den Namen hineinspielen könnte.

    Die Quellen der 6490 wollte ich mir an dieser Stelle nicht antun, denn die basiert ja noch auf einem 2er-Kernel ... und bei den anderen Kandidaten (mit ARM-Architektur) wie der 4020 und der 4040 war ich dann erst einmal auf der Suche, ob die überhaupt eine avm_kernel_config verwenden, denn bei mindestens einem dieser Modelle bilde ich mir ein, da eine Sonderregelung (für irgendwelche "QCA"-Definitionen) in den Kernel-Quellen gesehen zu haben - leider weiß ich nicht mehr, wo das war und dann bin ich bei der Recherche wieder vom Thema abgekommen und habe ganz andere interessante Sachen gefunden.

    Jedenfalls fehlt da auch noch der komplette Teil mit dem Extrahieren der Größe des avm_kernel_config-Bereichs und dem anschließenden Ändern des Linker-Skripts ... wobei das bisher auch nur für MIPS-Prozessoren funktionierte (da war ja der Pfad im Patch-File hinterlegt) und man ggf. auch die anderen Architekturen erst einmal noch in den Skat drücken könnte (ich wollte nur eine Lösung, die nicht bei der nächsten Architektur dann wieder angefaßt werden muß) ... aber die Frage, ob da nun "64 * 1024" steht oder "96 * 1024", muß man trotzdem anders klären oder das Patch-File dynamisch generieren (besser ist aber sicherlich "sed" o.ä. anstelle von "patch" bei dieser Problemstellung).

  10. #50
    IPPF-Fan
    Registriert seit
    27.05.2010
    Beiträge
    194
    Gibt nun die 6.80 sourcen für 7390. Evtl als auf wiederholte Anfrage vom 14.3. Das würde in die "normale" Reaktionszeit passen udn bedeuten meine erste Anfrage Anfang Februar ging verloren.
    Wie dem auch sei, 6.83 Firmware kam heut raus und maile avm gleich noch

  11. #51
    IPPF Siebentausend-VIP Avatar von PeterPawn
    Registriert seit
    10.05.2006
    Ort
    Berlin
    Beiträge
    7.732
    Der andere Aufbau der 7580 führt offenbar auch zu einem anderen "Timing" beim Start der Box.

    Da, wo die VR9-Modelle direkt nach Power-On die GPIO-Ports initialisieren (ich rechne das "Aufblinken" aller LEDs diesem Vorgang zu) und anschließend mit den 5 Sekunden (oder sind es doch eher 10?) Empfängnisbereitschaft im Bootloader beginnen, braucht die 7580 schon erst einmal 5-7 Sekunden (das stoppt sich schlecht), bis die an diesem Punkt (GPIO-Initialisierung) überhaupt ankommt. Jedenfalls startet sie erst einmal mit dauerleuchtender Power-LED und nach dieser Zeit (nehmen wir mal das Mittel meiner Versuche, das wären sechs Sekunden) kommt dann das bekannte Aufblinken aller LEDs und der Bootloader reagiert wohl auch erst dann auf die UDP-Broadcasts. Wie sich die Ethernet-Ports bei der Initialisierung verhalten, habe ich vergessen zu beobachten, auch ab wann ARP-Requests beantwortet werden. Aber damit beginnen diese "kritischen fünf Sekunden" (falls jemand den FTP-Client von Hand verbinden will) hier deutlich später (und auch das sind handgestoppt eher zehn Sekunden, 5x Blinken der Power-LED mit 0,5 Hz) - nur falls jemand sein Freetz-Image (wenn er den Kernel beibehält, könnte er ja schon eines erstellen) über den Bootloader installieren lassen will (die Box arbeitet wieder mit dem Laden in den Speicher und schreibt dann das System aus dem RAM in die NAND-Partitionen).

    Wegen des ausschließlich eingesetzten NAND-Flashs gibt es wohl auch zwei verschiedene Bootloader-Versionen in der "urlader"-Partition ... jedenfalls existieren dort Zeichenketten, die die Vermutung unterstützen, daß nur bei zwei funktionsfähigen Bootloadern (deren Zeichenketten auch tatsächlich doppelt vorkommen) ein Update eines der beiden gestattet wird. Ist einer defekt, wird wohl ein entsprechender Request über den FTP-Server abgelehnt, wobei es auch sein kann, daß das nur in der Seriellen sichtbar wird (ohne genauere Kenntnis des GRX500 und der Vorgänge beim Start werde ich das auch nicht probieren).

  12. #52
    IPPF-Einsteiger
    Registriert seit
    08.01.2006
    Beiträge
    1
    Ich habe am 20.03. ebenfalls AVM geschrieben, wann sie die aktuellen opensource-Files für die 7390 denn nun endlich veröffentlichen, selbst die für 06.69 habe ich angefragt. Sie haben mir sofort ein Tiket gegeben und um Geduld gebeten.
    Bitte nicht über meinen ersten Beitrag wundern, bin seit 10 Jahren treuer Leser und Freetz-Benutzer über mehrere Boxengenerationen. Das wollte ich nur loswerden.

    stulle
    FritzBox 7390 freetz-devel 06.80 Samba, vsftp, nfs - Provider 1&1 (8Mbit/1Mbit)
    Fritzrepeater N/G, 7272v3 als Wlan/Dect-Repeater+Drucker
    3xFrizFon MT-F

Seite 3 von 3 ErsteErste 123

Ähnliche Themen

  1. [Info] Opensource der FBF 7390 84.05.01
    Von 3949354 im Forum Freetz
    Antworten: 4
    Letzter Beitrag: 01.04.2011, 10:40
  2. Antworten: 20
    Letzter Beitrag: 23.10.2008, 20:31
  3. SOT als OpenSource?
    Von FalkoD im Forum SOT / Streaming Client
    Antworten: 6
    Letzter Beitrag: 17.06.2007, 10:46
  4. Fax im BridgeMode: Abbruch, fehlende Linien, fehlende Seiten usw.
    Von Ralph* im Forum Asterisk ISDN mit CAPI (chan_capi, chan_capi_cm)
    Antworten: 16
    Letzter Beitrag: 18.12.2006, 15:27
  5. Bestandteile von 1&1 Bündel einzeln kündbar ?
    Von Dino75195 im Forum 1&1 VoIP
    Antworten: 7
    Letzter Beitrag: 13.04.2006, 11:14

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • Anhänge hochladen: Nein
  • Beiträge bearbeiten: Nein
  •