Seite 3 von 4 ErsteErste 1234 LetzteLetzte
Ergebnis 41 bis 60 von 65

Thema: Fehlende Bestandteile im OpenSource-Paket von AVM

  1. #41
    IPPF Tausender
    Registriert seit
    14.04.2010
    Beiträge
    1.486
    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
    170
    @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 Achttausend-VIP Avatar von PeterPawn
    Registriert seit
    10.05.2006
    Ort
    Berlin
    Beiträge
    8.147
    @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
    170
    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 Achttausend-VIP Avatar von PeterPawn
    Registriert seit
    10.05.2006
    Ort
    Berlin
    Beiträge
    8.147
    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
    881
    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 Achttausend-VIP Avatar von PeterPawn
    Registriert seit
    10.05.2006
    Ort
    Berlin
    Beiträge
    8.147
    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
    881
    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 Achttausend-VIP Avatar von PeterPawn
    Registriert seit
    10.05.2006
    Ort
    Berlin
    Beiträge
    8.147
    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
    170
    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 Achttausend-VIP Avatar von PeterPawn
    Registriert seit
    10.05.2006
    Ort
    Berlin
    Beiträge
    8.147
    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

  13. #53
    IPPF Fünfhunderter
    Registriert seit
    20.12.2005
    Beiträge
    881
    Zitat Zitat von PeterPawn Beitrag anzeigen
    Ich habe gesehen, daß Du Freetz an den Stand aus dem YourFritz-Repo angepaßt hast ...


    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 ...
    Du hast vermutlich übersehen, dass ich nicht auf die allerletzte Version, sondern auf die Version "vor den avm_kernel_config_area-Änderungen" aktualisiert habe. D.h. es funktioniert weiterhin für VR9-Boxen und funktioniert weiterhin NICHT für GRX5-Boxen.


    Zitat Zitat von PeterPawn Beitrag anzeigen
    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)
    Ich lese mich in Deinen avm_kernel_config_area-Code ein und versuche mal was vorzuschlagen. Mir wäre immer noch "(extract|gen).avm_kernel_config ist ein Tool unter tools (und nicht irgendwo unter Kernel-Quellen), welches für alle Boxen funktioniert, ggf. per Übergabe notwendiger Parameter" lieber.


    Ich weiß nicht, ob es Dir aufgefallen ist, aber aktuell wird nicht mal libfdt aus den AVM-Kernel-Quellen verwendet, sondern das letzte Release davon (mit einigen cherry-picked Fixes) von github.

    Edit: Ist diese Zeile aus 1f293608fa übrigens richtig? Diese Zeile lässt vermuten, eher nicht. Sollte die Schleife nicht bei avm_kernel_config_tags_device_tree_subrev_0 starten und in der zweiten Zeile es nicht i - avm_kernel_config_tags_device_tree_subrev_0 heißen?

    Edit2:
    Vorschlag1:
    An einigen Stellen findet sich folgender Code
    Code:
      while (entry->tag <= avm_kernel_config_tags_last)
      {
        if (entry->config == NULL) return bzw. break;
        ...
      }

    Der Code liest sich so, als wäre entry->config == NULL ein allgemeingültiger Marker fürs Ende der Struktur, i.e. der Code wie folgt umgeschrieben werden könnte:
    Code:
      while (entry->config != NULL)
      {
        ...
      }

    Damit wäre man der Abhängigkeit an avm_kernel_config_tags_last los.
    Geändert von er13 (25.03.2017 um 14:49 Uhr)

  14. #54
    IPPF Achttausend-VIP Avatar von PeterPawn
    Registriert seit
    10.05.2006
    Ort
    Berlin
    Beiträge
    8.147
    @er13:
    Ist mir nicht aufgefallen, so genau habe ich dann (zu meiner Schande) wieder nicht hingesehen.

    Ich verstehe ja Dein Anliegen bei der Integration auch in gewissem Maße ... aber da die ganze Geschichte mit dem "avm_kernel_config"-Bereich ja nur dann überhaupt von Interesse ist, wenn der Freetz-Benutzer ohnehin ein "replace kernel" machen will, sehe ich das mehr als Tool für das Kompilieren eines kompletten Kernels an (was dann ohnehin stattfinden muß, wenn der Benutzer "replace kernel" verwenden will) als eines, was zu den Freetz-Tools gehört und die notwendige "Live-Kompilierung" der beiden Programme (und es wären eben beide, weil der "relocate"-Teil mit der Abhängigkeit von der AVM-Enum-Variablen in beiden verwendet wird) eher als "intermediate result", was man hinterher auch problemlos wieder entsorgen könnte (das spart das Aufbauen von komplizierten Abhängigkeiten für's "make" und der Zeitfaktor durch mehrfaches Kompilieren und Ausführen ist hier m.E. zu vernachlässigen).

    Mit dem passenden Symlink im Verzeichnis kannst Du das ja auch problemlos "außerhalb der Kernel-Quellen" verwalten (allerdings eher nicht als "host tool", was nur einmal für die richtige Architektur übersetzt werden muß und daher dort einzuordnen wäre) und mußt nur am Ende die vom Assembler erzeugte Objekt-Datei zusammen mit dem Patch für das Linker-Skript (auch der ist bei der Größe nun mal modellabhängig und auch wenn wir im Moment nur zwei Größen kennen, würde ich das doch dynamisch an die AVM-Quellen anpassen, falls weitere "flavors" dazukommen) in den Baum mit den Kernel-Quellen kopieren. Wenn Du das dann wieder "restaurierst", hast Du auch einen "stabilen" Stand der Kernel-Quellen, den man (wenn man will) wieder für mehrere Modelle oder zumindest für mehrere Builds mit wechselnder Konfiguration beim "replace kernel" verwenden kann.

    Aber auch das Einbinden mit absoluten Pfaden oder über Symlinks (dann brauchst Du gar nichts in den Kernel-Baum kopieren, änderst die Struktur aber auch wieder) wäre vielleicht eine Überlegung wert ... aber ich verstehe ohnehin noch nicht so ganz, wo Du die Grenzen der Änderungen ziehen willst bzw. was Dich bei dieser Differenzierung "Kernel vs. Freetz-Tools" nun wirklich antreibt.

    Das sind nun mal leider drei verschiedene Level von "Volatilität" ... die (Prozessor-)Architektur ändert sich nur mit dem Prozessor-Modell (das braucht bisher nur den Rebuild der "host tools"), die Inhalte der FDTs ändern sich mit dem (FRITZ!Box-)Modell und die finalen Inhalte des Konfigurationsbereichs ändern sich sogar (wg. der Modul-Tabelle und der "version_info") für jede neue FRITZ!OS-Version.

    Da sich auch der Aufbau des Konfigurationsbereiches mit jeder neuen FRITZ!OS-Version ändern kann (das weiß man erst, wenn man die Quellen hat und theoretisch könnte mit jedem neuen OS auch eine neue HWSubRevision in den FDT-Bereich Einzug halten), sehe ich auch die beiden Tools aus "avm_kernel_config" eher auf derselben Ebene bei ihrer "Vergänglichkeit", wie den Inhalt des Konfigurationsbereiches an sich ... und das bedeutet dann tatsächlich, daß man sie für jeden Build, bei dem sich der zugrundeliegende AVM-Kernel geändert hat, auch neu erstellen und benutzen muß (wenn man einen eigenen Kernel haben will) und sie bei den Abhängigkeiten für einen Build auch am ehesten dort unterbringt, wo ein neues AVM-Image entpackt wird. Man muß ja nicht jedesmal den kompletten Kernel übersetzen und entpackt wird der doch (m.W.) ohnehin, weil man ja die Include-Files für Userland-Programmierung auch braucht. Vielleicht brauchst Du ja auch eine neue "Kategorie" für solche Hilfsprogramme, die "image tools", die von der AVM-Version der Firmware abhängig sind und für jede dieser Versionen neu erstellt werden müssen.

  15. #55
    IPPF Fünfhunderter
    Registriert seit
    20.12.2005
    Beiträge
    881
    Ok, nochmal meine Motivation.

    Background: in Freetz können unterhalb einer Working-Copy Images für mehrere Boxen erstellt werden, ohne dass dazwischen ein kompletter Clean notwendig wäre (man kann die .config anderer Boxen reinkopieren oder einfach mal über menuconfig umschalten). Ich weiß nicht, ob außer den Entwicklern dieses Feature jemand nutzt, aber ich finde es bei z.B. Version-Bumps sehr nützlich, da ich einfach testen kann, ob sich die neue Version des Pakets, bei dem der Version-Bump stattfindet, eben mit allen uClibc-Versionen (zumindest) übersetzen lässt.

    Damit gilt per Definition, unter tools darf sich nur ein Tool befinden, welches "allgemeingültig" ist. Die Unterschiede dürfen sich nur auf folgendes beschränken: "wird für die Box gar nicht verwendet" oder "dem Tool werden Box-spezifische Parameter übergeben".

    Und solange es nicht unbedingt notwendig ist, möchte ich auch bei avm_kernel_config_area-Tools nicht davon abweichen.

    Warum möchte ich das. Es erscheint mir schlicht und ergreifend einfacher als das Ganze make-technisch umzusetzen. Denn (noch mal Background) in Freetz wird dasselbe OpenSource-Paket (oft gezwungenermaßen) für mehrere Boxen verwendet, das Umschalten der Box soll auch in dem Fall, dass für die Box, auf die umgeschaltet wurde, dasselbe OpenSource-Paket verwendet wird, dazu führen, dass Teile des Kernels neu übersetzt werden. Das wäre alles zwar möglich auch in dem Fall, wenn alles OpenSource-Paket spezifisch wäre, aber erfordert das Einschleusen von Freetz-Parametern in Kernel-Build-Environment, was ich bisher erfolgreich vermieden habe, und damit die Anzahl der Freetz-Kernel-Patches für AVM-OpenSource-Pakete klein gehalten habe.

    Wenn man sich nun die Unterschiede zwischen 7490.06.80/avm_kernel_config.h und 7580.06.53/avm_kernel_config.h anschaut
    Code:
    --- 7490.06.80/avm_kernel_config.h
    +++ 7580.06.53/avm_kernel_config.h
    @@ -17,7 +17,253 @@
         avm_kernel_config_tags_device_tree_subrev_7,
         avm_kernel_config_tags_device_tree_subrev_8,
         avm_kernel_config_tags_device_tree_subrev_9,  /* subrev müssen aufeinander folgen */
    -    avm_kernel_config_tags_device_tree_subrev_last = avm_kernel_config_tags_device_tree_subrev_9,
    +    avm_kernel_config_tags_device_tree_subrev_10,
    +    avm_kernel_config_tags_device_tree_subrev_11,
    +    avm_kernel_config_tags_device_tree_subrev_12,
    +    avm_kernel_config_tags_device_tree_subrev_13,
    +    avm_kernel_config_tags_device_tree_subrev_14,
    +    avm_kernel_config_tags_device_tree_subrev_15,
    +    avm_kernel_config_tags_device_tree_subrev_16,
    +    avm_kernel_config_tags_device_tree_subrev_17,
    +    avm_kernel_config_tags_device_tree_subrev_18,
    +    avm_kernel_config_tags_device_tree_subrev_19,
    +    avm_kernel_config_tags_device_tree_subrev_20,
    +    avm_kernel_config_tags_device_tree_subrev_21,
    +    avm_kernel_config_tags_device_tree_subrev_22,
    +    avm_kernel_config_tags_device_tree_subrev_23,
    +    avm_kernel_config_tags_device_tree_subrev_24,
    +    avm_kernel_config_tags_device_tree_subrev_25,
    +    avm_kernel_config_tags_device_tree_subrev_26,
    +    avm_kernel_config_tags_device_tree_subrev_27,
    +    avm_kernel_config_tags_device_tree_subrev_28,
    +    avm_kernel_config_tags_device_tree_subrev_29,
    +    avm_kernel_config_tags_device_tree_subrev_30,
    +    avm_kernel_config_tags_device_tree_subrev_31,
    +    avm_kernel_config_tags_device_tree_subrev_32,
    +    avm_kernel_config_tags_device_tree_subrev_33,
    +    avm_kernel_config_tags_device_tree_subrev_34,
    +    avm_kernel_config_tags_device_tree_subrev_35,
    +    avm_kernel_config_tags_device_tree_subrev_36,
    +    avm_kernel_config_tags_device_tree_subrev_37,
    +    avm_kernel_config_tags_device_tree_subrev_38,
    +    avm_kernel_config_tags_device_tree_subrev_39,
    +    avm_kernel_config_tags_device_tree_subrev_40,
    +    avm_kernel_config_tags_device_tree_subrev_41,
    +    avm_kernel_config_tags_device_tree_subrev_42,
    +    avm_kernel_config_tags_device_tree_subrev_43,
    +    avm_kernel_config_tags_device_tree_subrev_44,
    +    avm_kernel_config_tags_device_tree_subrev_45,
    +    avm_kernel_config_tags_device_tree_subrev_46,
    +    avm_kernel_config_tags_device_tree_subrev_47,
    +    avm_kernel_config_tags_device_tree_subrev_48,
    +    avm_kernel_config_tags_device_tree_subrev_49,
    +    avm_kernel_config_tags_device_tree_subrev_50,
    +    avm_kernel_config_tags_device_tree_subrev_51,
    +    avm_kernel_config_tags_device_tree_subrev_52,
    +    avm_kernel_config_tags_device_tree_subrev_53,
    +    avm_kernel_config_tags_device_tree_subrev_54,
    +    avm_kernel_config_tags_device_tree_subrev_55,
    +    avm_kernel_config_tags_device_tree_subrev_56,
    +    avm_kernel_config_tags_device_tree_subrev_57,
    +    avm_kernel_config_tags_device_tree_subrev_58,
    +    avm_kernel_config_tags_device_tree_subrev_59,
    +    avm_kernel_config_tags_device_tree_subrev_60,
    +    avm_kernel_config_tags_device_tree_subrev_61,
    +    avm_kernel_config_tags_device_tree_subrev_62,
    +    avm_kernel_config_tags_device_tree_subrev_63,
    +    avm_kernel_config_tags_device_tree_subrev_64,
    +    avm_kernel_config_tags_device_tree_subrev_65,
    +    avm_kernel_config_tags_device_tree_subrev_66,
    +    avm_kernel_config_tags_device_tree_subrev_67,
    +    avm_kernel_config_tags_device_tree_subrev_68,
    +    avm_kernel_config_tags_device_tree_subrev_69,
    +    avm_kernel_config_tags_device_tree_subrev_70,
    +    avm_kernel_config_tags_device_tree_subrev_71,
    +    avm_kernel_config_tags_device_tree_subrev_72,
    +    avm_kernel_config_tags_device_tree_subrev_73,
    +    avm_kernel_config_tags_device_tree_subrev_74,
    +    avm_kernel_config_tags_device_tree_subrev_75,
    +    avm_kernel_config_tags_device_tree_subrev_76,
    +    avm_kernel_config_tags_device_tree_subrev_77,
    +    avm_kernel_config_tags_device_tree_subrev_78,
    +    avm_kernel_config_tags_device_tree_subrev_79,
    +    avm_kernel_config_tags_device_tree_subrev_80,
    +    avm_kernel_config_tags_device_tree_subrev_81,
    +    avm_kernel_config_tags_device_tree_subrev_82,
    +    avm_kernel_config_tags_device_tree_subrev_83,
    +    avm_kernel_config_tags_device_tree_subrev_84,
    +    avm_kernel_config_tags_device_tree_subrev_85,
    +    avm_kernel_config_tags_device_tree_subrev_86,
    +    avm_kernel_config_tags_device_tree_subrev_87,
    +    avm_kernel_config_tags_device_tree_subrev_88,
    +    avm_kernel_config_tags_device_tree_subrev_89,
    +    avm_kernel_config_tags_device_tree_subrev_90,
    +    avm_kernel_config_tags_device_tree_subrev_91,
    +    avm_kernel_config_tags_device_tree_subrev_92,
    +    avm_kernel_config_tags_device_tree_subrev_93,
    +    avm_kernel_config_tags_device_tree_subrev_94,
    +    avm_kernel_config_tags_device_tree_subrev_95,
    +    avm_kernel_config_tags_device_tree_subrev_96,
    +    avm_kernel_config_tags_device_tree_subrev_97,
    +    avm_kernel_config_tags_device_tree_subrev_98,
    +    avm_kernel_config_tags_device_tree_subrev_99,
    +    avm_kernel_config_tags_device_tree_subrev_100,
    +    avm_kernel_config_tags_device_tree_subrev_101,
    +    avm_kernel_config_tags_device_tree_subrev_102,
    +    avm_kernel_config_tags_device_tree_subrev_103,
    +    avm_kernel_config_tags_device_tree_subrev_104,
    +    avm_kernel_config_tags_device_tree_subrev_105,
    +    avm_kernel_config_tags_device_tree_subrev_106,
    +    avm_kernel_config_tags_device_tree_subrev_107,
    +    avm_kernel_config_tags_device_tree_subrev_108,
    +    avm_kernel_config_tags_device_tree_subrev_109,
    +    avm_kernel_config_tags_device_tree_subrev_110,
    +    avm_kernel_config_tags_device_tree_subrev_111,
    +    avm_kernel_config_tags_device_tree_subrev_112,
    +    avm_kernel_config_tags_device_tree_subrev_113,
    +    avm_kernel_config_tags_device_tree_subrev_114,
    +    avm_kernel_config_tags_device_tree_subrev_115,
    +    avm_kernel_config_tags_device_tree_subrev_116,
    +    avm_kernel_config_tags_device_tree_subrev_117,
    +    avm_kernel_config_tags_device_tree_subrev_118,
    +    avm_kernel_config_tags_device_tree_subrev_119,
    +    avm_kernel_config_tags_device_tree_subrev_120,
    +    avm_kernel_config_tags_device_tree_subrev_121,
    +    avm_kernel_config_tags_device_tree_subrev_122,
    +    avm_kernel_config_tags_device_tree_subrev_123,
    +    avm_kernel_config_tags_device_tree_subrev_124,
    +    avm_kernel_config_tags_device_tree_subrev_125,
    +    avm_kernel_config_tags_device_tree_subrev_126,
    +    avm_kernel_config_tags_device_tree_subrev_127,
    +    avm_kernel_config_tags_device_tree_subrev_128,
    +    avm_kernel_config_tags_device_tree_subrev_129,
    +    avm_kernel_config_tags_device_tree_subrev_130,
    +    avm_kernel_config_tags_device_tree_subrev_131,
    +    avm_kernel_config_tags_device_tree_subrev_132,
    +    avm_kernel_config_tags_device_tree_subrev_133,
    +    avm_kernel_config_tags_device_tree_subrev_134,
    +    avm_kernel_config_tags_device_tree_subrev_135,
    +    avm_kernel_config_tags_device_tree_subrev_136,
    +    avm_kernel_config_tags_device_tree_subrev_137,
    +    avm_kernel_config_tags_device_tree_subrev_138,
    +    avm_kernel_config_tags_device_tree_subrev_139,
    +    avm_kernel_config_tags_device_tree_subrev_140,
    +    avm_kernel_config_tags_device_tree_subrev_141,
    +    avm_kernel_config_tags_device_tree_subrev_142,
    +    avm_kernel_config_tags_device_tree_subrev_143,
    +    avm_kernel_config_tags_device_tree_subrev_144,
    +    avm_kernel_config_tags_device_tree_subrev_145,
    +    avm_kernel_config_tags_device_tree_subrev_146,
    +    avm_kernel_config_tags_device_tree_subrev_147,
    +    avm_kernel_config_tags_device_tree_subrev_148,
    +    avm_kernel_config_tags_device_tree_subrev_149,
    +    avm_kernel_config_tags_device_tree_subrev_150,
    +    avm_kernel_config_tags_device_tree_subrev_151,
    +    avm_kernel_config_tags_device_tree_subrev_152,
    +    avm_kernel_config_tags_device_tree_subrev_153,
    +    avm_kernel_config_tags_device_tree_subrev_154,
    +    avm_kernel_config_tags_device_tree_subrev_155,
    +    avm_kernel_config_tags_device_tree_subrev_156,
    +    avm_kernel_config_tags_device_tree_subrev_157,
    +    avm_kernel_config_tags_device_tree_subrev_158,
    +    avm_kernel_config_tags_device_tree_subrev_159,
    +    avm_kernel_config_tags_device_tree_subrev_160,
    +    avm_kernel_config_tags_device_tree_subrev_161,
    +    avm_kernel_config_tags_device_tree_subrev_162,
    +    avm_kernel_config_tags_device_tree_subrev_163,
    +    avm_kernel_config_tags_device_tree_subrev_164,
    +    avm_kernel_config_tags_device_tree_subrev_165,
    +    avm_kernel_config_tags_device_tree_subrev_166,
    +    avm_kernel_config_tags_device_tree_subrev_167,
    +    avm_kernel_config_tags_device_tree_subrev_168,
    +    avm_kernel_config_tags_device_tree_subrev_169,
    +    avm_kernel_config_tags_device_tree_subrev_170,
    +    avm_kernel_config_tags_device_tree_subrev_171,
    +    avm_kernel_config_tags_device_tree_subrev_172,
    +    avm_kernel_config_tags_device_tree_subrev_173,
    +    avm_kernel_config_tags_device_tree_subrev_174,
    +    avm_kernel_config_tags_device_tree_subrev_175,
    +    avm_kernel_config_tags_device_tree_subrev_176,
    +    avm_kernel_config_tags_device_tree_subrev_177,
    +    avm_kernel_config_tags_device_tree_subrev_178,
    +    avm_kernel_config_tags_device_tree_subrev_179,
    +    avm_kernel_config_tags_device_tree_subrev_180,
    +    avm_kernel_config_tags_device_tree_subrev_181,
    +    avm_kernel_config_tags_device_tree_subrev_182,
    +    avm_kernel_config_tags_device_tree_subrev_183,
    +    avm_kernel_config_tags_device_tree_subrev_184,
    +    avm_kernel_config_tags_device_tree_subrev_185,
    +    avm_kernel_config_tags_device_tree_subrev_186,
    +    avm_kernel_config_tags_device_tree_subrev_187,
    +    avm_kernel_config_tags_device_tree_subrev_188,
    +    avm_kernel_config_tags_device_tree_subrev_189,
    +    avm_kernel_config_tags_device_tree_subrev_190,
    +    avm_kernel_config_tags_device_tree_subrev_191,
    +    avm_kernel_config_tags_device_tree_subrev_192,
    +    avm_kernel_config_tags_device_tree_subrev_193,
    +    avm_kernel_config_tags_device_tree_subrev_194,
    +    avm_kernel_config_tags_device_tree_subrev_195,
    +    avm_kernel_config_tags_device_tree_subrev_196,
    +    avm_kernel_config_tags_device_tree_subrev_197,
    +    avm_kernel_config_tags_device_tree_subrev_198,
    +    avm_kernel_config_tags_device_tree_subrev_199,
    +    avm_kernel_config_tags_device_tree_subrev_200,
    +    avm_kernel_config_tags_device_tree_subrev_201,
    +    avm_kernel_config_tags_device_tree_subrev_202,
    +    avm_kernel_config_tags_device_tree_subrev_203,
    +    avm_kernel_config_tags_device_tree_subrev_204,
    +    avm_kernel_config_tags_device_tree_subrev_205,
    +    avm_kernel_config_tags_device_tree_subrev_206,
    +    avm_kernel_config_tags_device_tree_subrev_207,
    +    avm_kernel_config_tags_device_tree_subrev_208,
    +    avm_kernel_config_tags_device_tree_subrev_209,
    +    avm_kernel_config_tags_device_tree_subrev_210,
    +    avm_kernel_config_tags_device_tree_subrev_211,
    +    avm_kernel_config_tags_device_tree_subrev_212,
    +    avm_kernel_config_tags_device_tree_subrev_213,
    +    avm_kernel_config_tags_device_tree_subrev_214,
    +    avm_kernel_config_tags_device_tree_subrev_215,
    +    avm_kernel_config_tags_device_tree_subrev_216,
    +    avm_kernel_config_tags_device_tree_subrev_217,
    +    avm_kernel_config_tags_device_tree_subrev_218,
    +    avm_kernel_config_tags_device_tree_subrev_219,
    +    avm_kernel_config_tags_device_tree_subrev_220,
    +    avm_kernel_config_tags_device_tree_subrev_221,
    +    avm_kernel_config_tags_device_tree_subrev_222,
    +    avm_kernel_config_tags_device_tree_subrev_223,
    +    avm_kernel_config_tags_device_tree_subrev_224,
    +    avm_kernel_config_tags_device_tree_subrev_225,
    +    avm_kernel_config_tags_device_tree_subrev_226,
    +    avm_kernel_config_tags_device_tree_subrev_227,
    +    avm_kernel_config_tags_device_tree_subrev_228,
    +    avm_kernel_config_tags_device_tree_subrev_229,
    +    avm_kernel_config_tags_device_tree_subrev_230,
    +    avm_kernel_config_tags_device_tree_subrev_231,
    +    avm_kernel_config_tags_device_tree_subrev_232,
    +    avm_kernel_config_tags_device_tree_subrev_233,
    +    avm_kernel_config_tags_device_tree_subrev_234,
    +    avm_kernel_config_tags_device_tree_subrev_235,
    +    avm_kernel_config_tags_device_tree_subrev_236,
    +    avm_kernel_config_tags_device_tree_subrev_237,
    +    avm_kernel_config_tags_device_tree_subrev_238,
    +    avm_kernel_config_tags_device_tree_subrev_239,
    +    avm_kernel_config_tags_device_tree_subrev_240,
    +    avm_kernel_config_tags_device_tree_subrev_241,
    +    avm_kernel_config_tags_device_tree_subrev_242,
    +    avm_kernel_config_tags_device_tree_subrev_243,
    +    avm_kernel_config_tags_device_tree_subrev_244,
    +    avm_kernel_config_tags_device_tree_subrev_245,
    +    avm_kernel_config_tags_device_tree_subrev_246,
    +    avm_kernel_config_tags_device_tree_subrev_247,
    +    avm_kernel_config_tags_device_tree_subrev_248,
    +    avm_kernel_config_tags_device_tree_subrev_249,
    +    avm_kernel_config_tags_device_tree_subrev_250,
    +    avm_kernel_config_tags_device_tree_subrev_251,
    +    avm_kernel_config_tags_device_tree_subrev_252,
    +    avm_kernel_config_tags_device_tree_subrev_253,
    +    avm_kernel_config_tags_device_tree_subrev_254,
    +    avm_kernel_config_tags_device_tree_subrev_255,
    +    avm_kernel_config_tags_device_tree_subrev_last = avm_kernel_config_tags_device_tree_subrev_255,
         avm_kernel_config_tags_avmnet,
         avm_kernel_config_tags_last
     };
    dann sieht man, dass AVM da nicht besonders kreativ war und dass mein Ziel im Wesentlichen dadurch erreicht werden kann, dass die Abhängigkeiten an avm_kernel_config_tags_device_tree_subrev_last und avm_kernel_config_tags_last eliminiert werden (avm_kernel_config_tags_avmnet wird in Deinem Code nicht verwendet).

    Zu avm_kernel_config_tags_last habe ich einen Vorschlag in #53 gemacht (Du hast Dich dazu nicht geäußert, vermutlich den Edit übersehen). Wegen avm_kernel_config_tags_device_tree_subrev_last muss ich mir noch Gedanken machen.

    Das Argument "in der nächsten Fritz!OS-Version könnte AVM es ändern" ist zwar absolut legitim, aber solange AVM das OpenSource-Paket dazu nicht veröffentlicht hat, bist Du eher in Schwierigkeiten, denn Du musst mit irgendwelchen Annahmen arbeiten. Da wäre dann die quasi automatische Erkennung von avm_kernel_config_tags_last (damit meine ich eher "der Code ist so, dass es ihm wurscht ist") ein Vorteil.

    - - - Aktualisiert - - -

    Edit: und ganz ehrlich, ich glaube nicht, dass AVM an avm_kernel_config.h bzw. an Enums/Strukturen darin was großartig ändern wird. Unter Umständen haben sie jetzt bei GRX5-Boxen für alle Zeit der Welt diese avm_kernel_config_tags_device_tree_subrev_* hinzugefügt und werden es nie wieder machen. Der Index vom letzten 255 ist da meiner Ansicht nach ein sehr starker Indikator dafür
    Geändert von er13 (25.03.2017 um 16:15 Uhr)

  16. #56
    IPPF Achttausend-VIP Avatar von PeterPawn
    Registriert seit
    10.05.2006
    Ort
    Berlin
    Beiträge
    8.147
    Bei der Schleife (die ist ja neu hinzugekommen, weil ich vorher immer nur Kernel mit einem einzigen FDT hatte bei der 7490) hast Du m.E. recht, aber an anderer Stelle als aufgezeigt bzw. wir haben da vermutlich wieder unterschiedliche Ideen.
    [ EDIT: Quatsch, da habe ich mich ja auch nur verwirren lassen. Die Schleife geht eben von 0 bis "avm_kernel_config_tags_device_tree_subrev_last" und das ist ein anderer Wert (und auch der richtige) als "avm_kernel_config_tags_last", der dann tatsächlich größer wäre als der max. Index für eine HWSubrevision. ]

    Die Schleife soll von 0 bis "subrev_last - subrev_0" gehen (also alle möglichen "subrevs" umfassen) - jedenfalls sollte dafür auch das fprintf() dann stimmen (bin zu müde für sinnvolle Überlegungen). Daß die Aufrufe für eine Subrevision jenseits von "subrev_last" hier nicht tatsächlich "out of bounds" gehen, liegt u.a. daran, daß aus "hasDeviceTree(i)" dann eben für alles jenseits von "last - subrev_0" ohnehin "false" zurückkommt. [ EDIT: Auch Unfug, siehe oben. ]

    Wie man nun die Schleife gestaltet, ist aber auch egal ... entscheidend ist nur, daß am Beginn der Assembler-Datei die Liste der später folgenden FDTs stehen sollte, wobei die einmal einen Wert für den "reinen Index" (also "HWSubRevision") und einmal den Wert aus der Enum-Variablen (also HWSubRevision + subrev_0) für das Makro erwartet ... wobei Du gerne auch das Makro ändern und anstelle des "absoluten" Wertes 5 für "subrev_0" einen Namen ausgeben kannst. Aber normalerweise kennt das generierte Assembler-File die Enum-Variable bisher gar nicht und die Anlehnung der von mir generierten Label an die von AVM verwendeten Namen dient auch nur der besseren Übersicht und Vergleichbarkeit - damit heißt dann der FDT für subrev_0 eben auch so und nicht irgendetwas mit 5, was dem Enum-Wert entsprechen würde.

    Deiner Vermutung bzgl. der "Konstanz" der AVM-Strukturen mag ich mich nicht so ganz anschließen ... wenn man sich die als Basis verwendeten Linux-Versionen ansieht, würde ich sogar sagen, daß die GRX500-Strukturen mit 256 möglichen Subrevisionen älter sind als die verbliebenen 10 in der Aufzählung bei der 7490 - ob die wieder bei allen VR9-Modellen gleich sind, weißt Du viel besser als ich, weil ich andere Quellen von AVM für VR9 gar nicht benutze.

    Deiner Argumentation zum NULL-Pointer als (derzeitigem) Ende der Liste kann man ja problemlos in der ""init/avm_kernel_config.c" nachgehen:
    Code:
      1 #include <linux/kernel.h>
      2 #include <linux/avm_kernel_config.h>
      3 #include <asm/prom.h>
      4
      5 struct _avm_kernel_config **avm_kernel_config;
      6 struct _avm_kernel_version_info *avm_kernel_version_info;
      7 struct _kernel_modulmemory_config *kernel_modulmemory_config;
      8 unsigned char *avm_kernel_config_device_tree[avm_subrev_max];
      9
     10 void init_avm_kernel_config(void) {
     11     const char *intro = "AVM Kernel Config";
     12     struct _avm_kernel_config *p;
     13
     14     if (init_avm_kernel_config_ptr()) {
     15         pr_err("[%s] %s failed\n", __func__, intro);
     16         return;
     17     }
     18     pr_err("[%s] %s (ptr %p)\n", __func__, intro, avm_kernel_config);
     19
     20     p = *avm_kernel_config;
     21
     22
     23     if (p == NULL)
     24         return;
     25
     26     while (p->tag <= avm_kernel_config_tags_last) {
     27         if (p->config == NULL)
     28             return;
     29
     30         switch (p->tag) {
     31             case avm_kernel_config_tags_undef:
     32                 pr_err("[%s] %s: undef entry\n", __func__, intro);
     33                 break;
     34             case avm_kernel_config_tags_modulememory:
     35                 pr_err("[%s] %s: module memory entry\n", __func__,
     36                         intro);
     37                 kernel_modulmemory_config =
     38                     (struct _kernel_modulmemory_config *)(p->config);
     39                 break;
     40         case avm_kernel_config_tags_version_info:
     41                 pr_err("[%s] %s: version info entry\n", __func__,
     42                         intro);
     43                 avm_kernel_version_info = (struct _avm_kernel_version_info *)(p->config);
     44         break;
     45             case avm_kernel_config_tags_last:
     46                 return;
     47             case avm_kernel_config_tags_avmnet:
     48                 pr_err("[%s] %s: unhandled avmnet entry\n", __func__,
     49                         intro);
     50                 break;
     51             case avm_kernel_config_tags_hw_config:
     52                 pr_err("[%s] %s: unhandled hw_config entry\n",
     53                         __func__, intro);
     54                 break;
     55             case avm_kernel_config_tags_cache_config:
     56                 pr_err("[%s] %s: unhandled cache_config entry\n",
     57                         __func__, intro);
     58                 break;
     59             case avm_kernel_config_tags_device_tree_subrev_0 ... avm_kernel_config_tags_device_tree_subrev_last: {
     60                      unsigned int index = p->tag - avm_kernel_config_tags_device_tree_subrev_0;
     61                      pr_err("[%s] %s: device-tree for subrev %d found\n", __func__, intro, index);
     62                      avm_kernel_config_device_tree[index] = (unsigned char *)((unsigned long)p->config + 0x00UL);
     63                  }
     64                  break;
     65         }
     66         p++;
     67     }
     68
     69     pr_err("[%s] %s: internal error, should not be reached.\n",
     70             __func__, intro);
     71 }
     72
     73 /* vim: set noexpandtab sw=8 ts=8 sts=0: */
    [ AVM hat zwar keinen Header mit der Lizenz drin, aber packt das zum Kernel, damit darf man GPLv2 annehmen und ich habe das mal in vollem Umfang zitiert. ]

    Nach Zeile 27 sieht AVM das mit der Abbruchbedingung genauso wie Du ... da stellt sich dann die Frage, was die Redundanz mit dem "..._last" überhaupt soll. Nun mag das reine Vorsicht des Programmierers gewesen sein, der das umgesetzt hat ... aber es gäbe ja keinen logischen Grund, da zwei unabhängige Kennzeichnungen des Listen-Endes zu führen und da sieht das für mich mehr nach einem (vorgezogenen) "avoid NULL pointer usage" (als "weak reference") für einige "cases" im nachfolgenden "switch"-Statement aus, falls doch mal (ich vermute, bei AVM sind das unabhängige Dateien bei der Übersetzung und auch beim Linken, die Offsets also "externe Adressen") etwas beim Linken fehlt.

    Ich habe die denkbaren Abbruchbedingungen eigentlich nur 1:1 aus dem o.a. Code übernommen ... und da findest Du auch die Erklärung, warum ich auf die anderen - in der Enum-Variablen definierten - Typen von Einträgen verzichtet habe. Es gibt sie m.W. bisher schlicht nicht (zumindest wüßte ich nicht, bei welchem Modell das wäre) und sie werden auch vom AVM-Code als "unhandled" ausgewiesen, wenn sie dann trotzdem auftauchen. Damit ist die Chance, daß anderer Code darauf zurückgreifen will, meines Erachtens recht klein und ich habe nicht einmal bei allen anderen Typen eine Vorstellung, wie die Strukturen aussehen sollten, auf die "p->config" am Ende zeigt (und worauf der gecastet werden muß).

    Also könntest Du wahrscheinlich tatsächlich den Rückschluß ziehen, daß der erste Eintrag, bei dem p->config NULL ist, auch derjenige ist, bei dem p->tag den (Integer-)Wert von "avm_kernel_config_tags_last" darstellt - aber dann kannst Du die Liste auch einfach beim ersten Auftreten eines NULL-Pointers in p->config mit zwei leeren Int32-Werten beschließen und mußt den Wert für "avm_kernel_config_tags_last" gar nicht mehr kennen. Der Test auf "avm_kernel_config_tags_undef" findet da ja gar nicht mehr statt, wenn das "p->config == NULL" schon vorher abbricht und wäre damit ebenfalls "unreachable", wenn Deine Annahme stimmen sollte und genauso wäre die Schleifenbedingung für das "while" in Zeile 26 obsolet.

    Mich überrascht da zwar auch nichts mehr wirklich, aber ich hätte hier eher den Verdacht, daß der Test auf NULL für p->config eine spätere (schnelle, vielleicht nicht bis zum Ende durchdachte/abgesprochene) Änderung bei AVM darstellt und daß da eher ein "{ p++; continue; }" anstelle des "return;" stehen sollte. Wenn dann nämlich mal eines der (angenommenen) Symbole nicht aufgelöst werden kann, geht die Verarbeitung der Liste trotzdem weiter ... aber ich kann auch nur spekulieren, wie das bei AVM "spezifiziert" wurde und welche Implementierung nun richtig/beabsichtigt ist.



    Wobei ich immer noch nicht so ganz überzeugt bin, was die "Einordnung" als "host tool" durch Dich angeht - da kann ich Deine Erklärungen zwar verstehen, aber nicht nachvollziehen, warum Du das nicht einfach als "ganz normalen Schritt" beim Linken (auch wenn es davor auszuführen ist - dann ist es halt "Vorbereitung für's Linken") eines eigenen Kernels (und auch nur in diesem speziellen Fall muß das Extrahieren, Generieren und Assemblieren überhaupt stattfinden) ansehen willst. Sogar das Ermitteln der Größe braucht man nur unmittelbar vor der Verwendung ausführen und wer niemals einen eigenen Kernel verwenden will oder kann, der käme niemals in die Verlegenheit, diese Tools überhaupt benutzen zu müssen (und muß sie deshalb auch nicht erstellen).

    Damit sind die für mich so weit von einem gemeinsamen Build mit den anderen "host tools" entfernt, daß ich das schon mental nicht zusammenkriege und wenn man den gesamten Ablauf zur Erstellung der Objekt-Datei einfach in ein passendes Skript-File verpackt, dann ist das auch nur ein zusätzlicher Aufruf dieses Skripts beim bzw. vor dem Linken eines eigenen Kernels.

    Das muß gar nicht in irgendeine Kernel-Struktur eingebunden werden und damit ist es dann auch egal, ob die nun für ein einziges Modell oder für alle VR9-Modelle auf einmal verwendet wird. Der Kernel muß ja irgendwann ohnehin mal gelinkt werden und das ist ein Vorgang, der bisher nicht von FREETZ-Variablen beeinflußt ist und es auch in Zukunft nur so weit würde, daß da quasi ein "eigenes Kernel-Module" (avm_kernel_config_area.o) statisch dazugelinkt würde. Dafür reicht es ja schon, wenn man der Auflistung (in der Make-Variablen) "obj-y" dessen (kompletten) Dateinamen hinzufügt - dann kann das auch alles außerhalb der Kernel-Sources ablaufen und "verschmutzt" damit die Sourcen nicht so weit, daß die für den nächsten Build irgendwie erneut angefaßt werden müßten.

    Das Patchen von Makefiles (und das geht dann ja auch komplett ohne irgendwelche Parametrierungen und damit ohne "modellspezifische" Patches, wenn man das alles in einer "geschlossenen Datei" laufen läßt und zwar inkl. der Ermittlung der korrekten Größe des Bereiches) ist ja nun gang und gäbe im Freetz, wenn ich mich in "make/linux/patches" so umsehe. Ich begreife ja in erster Linie nicht, warum da etwas "vorproduziert" werden muß und nicht einfach in dem Moment, wo man es braucht (und da ist dann das konkrete Modell auch genauso bekannt wie die aktuelle AVM-Firmware als Quelle der Daten) die Tools quasi "on the fly" erzeugt werden, die Datei generieren (ggf. inkl. Assembler-Lauf) und dann wieder komplett erledigt sind, bis man sie mal wieder braucht und dann werden sie eben erneut erstellt. Das kommt m.E. auch ihrem "Charakter" viel näher, als die irgendwo den "host tools" zuzuschlagen.



    Aber wie gesagt ... ich wollte eigentlich nur die Struktur "aufdecken" und erkunden, ob das berichtete Problem beim Bauen/Booten eines eigenen Kernels wirklich an diesen fehlenden AVM-Bestandteilen liegt oder nicht. Ob und wie Du das nun in die Freetz-Toolchain integrierst (das ist ja offenbar auch bei AVM im Build-Prozess automatisiert und die werden auch nicht für jedes Modell eine eigene Build-Umgebung pflegen, zumindest klingen einige Pfadnamen in den AVM-Komponenten nicht danach), entscheidest Du alleine ... ich gebe max. meinen Senf dazu, wenn ich Probleme mit mir bekanntem AVM-Code sehen sollte. Das ist beim "Listenende" nicht der Fall ... also mach' wie Du denkst.
    Geändert von PeterPawn (25.03.2017 um 21:50 Uhr)

  17. #57
    IPPF Fünfhunderter
    Registriert seit
    20.12.2005
    Beiträge
    881
    @Peter: ich habe mich a bißerl ausgetobt. Lass' mich wissen, ob es für Dich ok ist bzw. Du meine Pull-Requests akzeptieren würdest.

    Ansonsten ist mir aufgefallen, dass der zweite Kernel bei den beiden GRX5-Boxen absolut identisch ist und das sogar unabhängig von der Fritz!OS-Version:
    Code:
    455a59eccfcdecfe61cc5e560c6bcfcf *FRITZ.Box_7560.149.06.53.kernel.image.unpacked.2ND
    455a59eccfcdecfe61cc5e560c6bcfcf *FRITZ.Box_7560.149.06.81.kernel.image.unpacked.2ND
    455a59eccfcdecfe61cc5e560c6bcfcf *FRITZ.Box_7580.153.06.54.kernel.image.unpacked.2ND
    455a59eccfcdecfe61cc5e560c6bcfcf *FRITZ.Box_7580.153.06.81.kernel.image.unpacked.2ND
    FDT_MAGIC ist in diesen 2 Mal zu finden. Vor dem ersten ist auch ein ordentliches config-area-array zu finden mit den Tags: 1(modulememory), 2(version_info), 5(device_tree_subrev_0), 6(device_tree_subrev_1) und 262(last). extract_avm_kernel_config scheitert jedoch sowohl für die Größe 96KB als auch für 64KB. Habe allerdings noch nicht debuggt, woran genau es liegt.

    Edit: scheinbar stimmt beim 2.ten Kern die Annahme, dass die Config-Area an einer 4K Grenze liegt, nicht mehr. Der Offset lautet 0x0020ef70.
    Geändert von er13 (27.03.2017 um 01:41 Uhr)

  18. #58
    IPPF Achttausend-VIP Avatar von PeterPawn
    Registriert seit
    10.05.2006
    Ort
    Berlin
    Beiträge
    8.147
    @er13:
    Das erscheint mir als extreme Verniedlichung dessen, was Du mit dem Code gemacht hast.

    Ich will unsere Differenzen bzgl. der Design-Kriterien von wartbarem Code nicht erneut aufwärmen (auch nicht mehr in der Wunde der fehlenden "style guides" für Freetz herumbohren und die damit einhergehende Willkür, wann welche Art der Änderung nun besser wäre, erneut ausführlich diskutieren/thematisieren) ... ich hatte ja geschrieben: "Mach' was Du willst." Wenn es das ist, was Du willst (ich habe nach dem siebten Commit dann irgendwann aufgehört zu lesen), dann mach' es - aber erwarte bitte nicht, daß ich z.B. die Änderung der Schleifenbedingungen tatsächlich als "Verbesserung" sehe.

    Wenn der von Dir neu formulierte Code funktioniert und in der Freetz-Toolchain das leistet, was Du von ihm erwartest: Schön. Damit ist das Thema für mich dann aber auch durch und da ich ohnehin für meine eigenen Zwecke einen anderen Weg der Integration verfolgen will und werde (ich habe - wie gesagt - die Commits gar nicht bis zum Ende angesehen, gehe aber fest davon aus, daß Du irgendetwas in der von Dir bereits angedeuteten Richtung umgesetzt haben wirst), werde ich zwar Deinen Vorschlag beim Vereinheitlichen der "has..."-Funktionen vermutlich aufgreifen (und ggf. auch weitere - noch nicht gelesene - sinnhafte Änderungsvorschläge; bisher gab es für mich da einfach noch keinen Grund zu einem solchen "Review" und das ist alles mehr oder weniger "organisch gewachsen" bei den Bemühungen, eine 1:1-Kopie der AVM-Daten zu erhalten), aber eher keine Pull-Requests übernehmen.

    Das dabei notwendige "cherry picking" ist am Ende aufwändiger für mich, als eine eigene "Optimierung" - die ich sicherlich auch in Angriff genommen hätte, wenn mir jemand gesagt hätte, daß es für diese "Hilfsfunktion" (die nach meiner Erwartung immer noch eines Tages überflüssig werden sollte, wenn AVM dann wirklich komplette Quelltext-Pakete veröffentlicht) auch darauf ankommt, daß diese unbedingt ohne "code clones" auskommt und daß der Code unbedingt noch einer Optimierung unterzogen werden mußte, bevor er in Freetz Verwendung finden konnte.

    Da wären dann (begründete) "Änderungsvorschläge" Deinerseits vielleicht doch der bessere Weg gewesen - wenn man sich überhaupt der Mühe unterziehen will, an so einer völlig banalen Stelle weitere Arbeitszeit zu investieren. Dieser Code wird weder ständig ausgeführt (muß also nicht besonders performant sein) noch ständig geändert (muß also auch nicht besonders "wartbar" sein) noch irgendwo auf einem Gerät mit begrenzten Ressourcen ausgeführt (muß also auch nicht besonders klein sein). Das macht in meinen Augen > 90% Deiner Änderungen komplett überflüssig und Du hättest Dich problemlos auf die weiter oben diskutierte Änderung beim Abbruch der Schleife beschränken können - eigentlich hättest Du dazu praktisch gar keinen Code anfassen müssen, da hätte eine "statische" Include-Datei mit einer der beiden Enum-Versionen von AVM vermutlich bereits gereicht, max. noch mit einer Änderung des fprintf() für das Ende der Liste.

    Ich hatte mich mit dem "Mach' wie Du willst." vermutlich mißverständlich ausgedrückt (ich meinte "integriere wie Du willst") ... das war nicht unbedingt eine Aufforderung, den Code mal wieder um des reinen Änderns willen "auf links zu drehen" und anders kann ich das Ersetzen von "while"-Schleifen durch "for" und den Umbau der Schleifenbedingung beim Iterieren über die FDTs nicht bewerten. Ich kann es nicht verhindern ... aber ich muß darüber keineswegs "fröhlich" sein und schon gar nicht die komplette Liste an Commits in meine Version übernehmen. Wenn ich jemals in die Verlegenheit kommen sollte, den Code noch einmal anfassen zu müssen, dann ist es für mich eben entscheidend, daß der so aussieht, wie ich ihn geschrieben habe, wenn ich ihn ändern will oder soll - das macht es dann nämlich mir wieder einfacher, mir Funktion und Arbeitsweise ins Gedächtnis zu rufen.

    Solltest Du noch einmal in die Verlegenheit kommen, eine derartige Aktion "in Erwägung ziehen zu müssen" (das erinnert mich so fatal an unsere Auseinandersetzung beim "mksquashfs" für die AVM-Version, daß ich erneut restlos bedient bin), dann wäre ich jedenfalls dankbar, wenn Du solche Änderungen zuvor wenigstens "ausdiskutieren" würdest und dann auch eine (nachvollziehbare) Begründung für solche Aktionen abliefern kannst. Die alte Aussage "Style-Guide gibt es nicht und brauchen wir auch nicht, ich mache das 'frei Schnauze' (und am Ende auch noch von Fall zu Fall und nicht etwa so, daß man sich auf irgendetwas einstellen kann)." ist jedenfalls keinesfalls eine passende Begründung in meinen Augen.

    Auch hier würde ich wieder darum bitten, daß Du dann die Lizenz-Header der Dateien ergänzt, damit deutlich erkennbar wird, daß es sich hier nicht ausschließlich um etwas handelt, was ich geschrieben habe. Nicht jeder ist automatisch der Meinung, daß Dein Stil beim Schreiben von C-Programmen der bessere ist (vielleicht solltest Du "while" als Code-Konstrukt aus dem Standard streichen lassen?) und wenn Du den Code schon "verbesserst" (danke, daß es kein Rotstift war), dann stehe bitte auch zu Deinen Änderungen.

  19. #59
    IPPF Fünfhunderter
    Registriert seit
    20.12.2005
    Beiträge
    881
    Wow, so eine Antwort habe ich nicht erwartet, insbesondere den Ton zwischen den Zeilen. Nichtsdestotrotz schlucke ich das jetzt und versuche sachlich dagegen zu argumentieren bzw. meine Motivation darzulegen.

    Ich finde es sehr schade, dass Du die Commits (wie Du es sogar selber betont hast) nicht bis zum Ende angeschaut hast und auf Basis Deiner Annahmen, Schlussfolgerungen gezogen hast... Da wäre es besser mit der Antwort einige Zeit zu warten, die Commits bis zum Ende anzuschauen und ggf. explizit nachzufragen, um Deine Annahmen zu bestätigen oder vielleicht auch zu widerlegen.

    Zu meiner Motivation: alle meine Commits kann man in folgende Kategorien unterteilen:

    1. Whitespaces cleanups: 87aaad1, 9defda1 (wobei bei diesem Commit, die Änderungen streng genommen zu dem funktionalen Commit unmittelbar davor gehören und mit Absicht aus diesem ausgelassen wurden).

    2. Verbesserung der Verständlichkeit des Codes, diese halfen mir Deinen Code zu verstehen (der nun mal nicht an allen Stellen für sich sprechend ist) und teilweise, wenn ich mich nicht vertan habe, Fehler in diesem aufzudecken: 2b549ad, 1e43c07, eb8443c (mit Fehler aufdecken ist dieser Commit gemeint), aa4dc6d.
    Dein Argument, der Code "wird nicht so oft geändert, deswegen muss er auch nicht besonders wartbar sein" kann ich nicht nachvollziehen. Jetzt haben zwei Leute daran gearbeitet bzw. arbeiten müssen/wollen und der zweite kam nicht sofort damit zurecht (im Sinne brauchte Zeit, um den Code zu verstehen zwecks seine Anpassungen durchführen zu wollen). Allein das ist schon Grund genug, um etwas Zeit in die bessere Verständlichkeit und damit die Wartbarkeit zu investieren.

    3. Vereinfachung/Verschönerung des Codes (dienen am Ende auch ausschließlich der besseren Wartbarkeit): fa4d0e7, 7f77f2d,
    5e3304c. Der letzte Commit ist in der Tat subjektiv, ich finde die for-Schleifen an diesen Stellen leichter zu lesen. Man beachte, ich habe es nicht überall geändert, deswegen fand ich den Ton des folgenden Satzes von Dir völlig unangebracht: "vielleicht solltest Du "while" als Code-Konstrukt aus dem Standard streichen lassen".

    4. Fehler/typos korrigieren (die Fehler hinderten mich an meinem Endziel): 5e30001, 7e8c2cf

    5. Die wichtigsten Vorbereitungscommits: fd958f4, 24e847b, 89dee38, 734e467
    Das Ziel von diesen war, die Anzahl der Verwendungen von avm_kernel_config_tags_last zu minimieren. Dafür musste unter anderem die Anzahl der Schleifen, in denen über das Config-Area-Array iteriert wird, verkleinert wird. Man beachte, es geht um die Anzahl Vorkommnisse und nicht um die Performance-Optimierung, wie Du fälschlicherweise annimmst. Das Ändern des Abbruchkriteriums bei der Iteration half auch die Anzahl Vorkommnisse von avm_kernel_config_tags_last zu minimieren.

    6. Der Hauptcommit: df5c65d
    Die Anzahl der #ifdef's in diesem ist durch die Vorbereitungsmaßnahmen sehr gering und die Idee von diesem ist in der Commit-Messge beschrieben. Es kann durchaus sein, dass die Annahmen von diesem irgendwann mal nicht gelten, aber momentan ist es so.

    Warum Du plötzlich Style-Guides ansprichst, kann ich nicht nachvollziehen (Änderungen dieser Art hatte ich bei keinem Commit als Ziel). Es sei jedoch darauf hingewiesen, dass auch Du keine hast, die irgendwo aufgeschrieben wären. Mir sind beim Anpassen Deines Codes folgende Verstösse meinerseits gegen Deine (von mir aus Deinem Code abgeleitete) Style-Guides aufgefallen/bewusst. Die "{"-Klammer beginnt an einigen Stellen in derselben Zeile anstatt in der neuen (kann ich korrigieren). Manche "if (condition) return"-Zeilen habe ich vor dem "return" umbrochen. Bei mir ist der Umbruch vor dem return unabdingbar (denn genau in dieser Zeile wird dann der Breakpoint in dem Debugger gesetzt), aber auch das kann ich ändern.

    Die Freetz-C-Code-Style-Guides nehme aus dem gegebenen Anlass in Angriff. Mir ist erst vor kurzem ein Open-Source-Projekt aufgefallen, in dem es sehr gut beschrieben war, inkl. einer Konfiguration für ein Auto-(Re-)Format-Tool.

    Lizenz-Header passe ich auch an, i.e. trage da meinen Namen ein.

  20. #60
    IPPF Achttausend-VIP Avatar von PeterPawn
    Registriert seit
    10.05.2006
    Ort
    Berlin
    Beiträge
    8.147
    @er13:
    Nun steh' aber auch bitte dazu, was da (wieder einmal) passiert ist und auch wenn ich von
    Zitat Zitat von PeterPawn
    Aber wie gesagt ... ich wollte eigentlich nur die Struktur "aufdecken" und erkunden, ob das berichtete Problem beim Bauen/Booten eines eigenen Kernels wirklich an diesen fehlenden AVM-Bestandteilen liegt oder nicht. Ob und wie Du das nun in die Freetz-Toolchain integrierst (das ist ja offenbar auch bei AVM im Build-Prozess automatisiert und die werden auch nicht für jedes Modell eine eigene Build-Umgebung pflegen, zumindest klingen einige Pfadnamen in den AVM-Komponenten nicht danach), entscheidest Du alleine ... ich gebe max. meinen Senf dazu, wenn ich Probleme mit mir bekanntem AVM-Code sehen sollte. Das ist beim "Listenende" nicht der Fall ... also mach' wie Du denkst.
    geschrieben habe, war das wohl kaum als Bitte um das komplette Umschreiben und die Korrektur meiner "Fehler" mißzuverstehen.

    Du hast erneut(!) aus einer fremden Software ohne unmittelbare Notwendigkeit "Deine eigene" gemacht und anstatt solche Änderungen erst einmal vorzuschlagen und zu diskutieren, wolltest Du es erneut sofort "besser" machen. Das ist eben nicht nur ein "Vorschlag" Deinerseits, der sich in verschiedene Commits aufteilt und den man nun gar selektiv irgendwie per Pull-Request übernehmen könnte. An Selbstvertrauen und Ellenbogen mangelt es Dir an dieser Stelle ganz offensichtlich nicht ... ich persönlich finde es aber schon recht kühn, wenn man seine eigenen Commits als "improvement" oder "make something better" eincheckt und diese Einschätzung nur auf der eigenen Sichtweise basiert.

    Wie das vielleicht weniger "aufdringlich" geht, kannst Du Dir gerne bei diesem Patch meinerseits einmal ansehen: https://github.com/PeterPawn/freetz/...3bae4c3645db31 - ich halte auch diesen für "better" (und begründe das sogar noch im Commit-Text, warum ich das so sehe), aber eben nicht mit "improve" und "better", sondern als "different approach". Nenn' es Zurückhaltung (eigentlich so gar nicht eine meiner hervorstechendsten Eigenschaften) oder wie Du willst ... Fakt ist jedenfalls, daß Du in der Vergangenheit, als Du von mir auf diesen Patch angesprochen wurdest, nicht minder "erregt" reagiert hast und Deine Argumentation als "Es funktioniert doch auch in meiner Version, was willst Du eigentlich von mir?" zusammengefaßt werden kann.

    Wie auch immer, das ist alles meinerseits unter GPLv2 gestellt und Du darfst es ändern, wie Du willst. Bei meiner Reaktion spielte es aber durchaus auch eine Rolle, daß Du (wieder einmal, also kann ich das auch nicht als "Unfall" ansehen) Deinerseits sofort vollendete Tatsachen geschaffen hast (daran ändert es auch absolut nichts, ob man nun Deine Änderungs"vorschläge" als sinnvoll ansieht oder sie - zumindest in Teilen - ablehnt), denn die Uhrzeit von http://freetz.org/changeset/14205 liegt deutlich vor Deinem Beitrag von 01:33 Uhr. Damit wurden aber bereits "Fakten geschaffen" und Du hast erneut Deine eigene Version (ohne jede weitere Diskussion oder auch nur die Möglichkeit dazu) als "die bessere Alternative" eingeschätzt und in Freetz übernommen.

    Ich brauche - ehrlich gesagt - auch die nachgereichte Begründung für die einzelnen Commits nicht (lesen kann ich ja durchaus, wenn ich das auch will) ... trotzdem gerne meinerseits die eigenen Kommentare zu Deinen Commits:

    - Dein Punkt 4 oben ist - sogar in der "Begründung" - in meinen Augen eine Zumutung, wenn es um 5e30001 geht. Für die zwei Tippfehler im anderen Commit ist das "geschenkt" ... aber wieso Deine Änderung in 5e30001 ein "fix" ist, erschließt sich mir in der Begründung nicht. Das mag ein "change" sein, wenn man Deinen "Endsieg" Dein Endziel zugrunde legt, aber das ist eben keine "Reparatur" irgendeiner nicht funktionierenden Konstruktion. Nun kannst Du Dich nach der Korrektur meines Fehlers bei der Verwendung des Singulars von "go" im "past tense" auch nicht darauf herausreden, daß Dir derartige Unterschiede "nicht geläufig" wären.

    - Deine Commits bauen durchaus aufeinander auf, ohne daß es aus dem Begleittext ersichtlich wäre (z.B. ist fa4d0e7 ohne 2b549ab falsch) und damit bleibt/bliebe mir bei der Übernahme von Pull-Requests gar nichts anderes übrig, als das jeweils meinerseits noch einmal komplett zu "reviewen".

    - Nach Deinen Änderungen hat sich eben auch die Logik des Codes geändert. Während es für mich die oberste Priorität hatte, daß der Code (im Rahmen seiner Möglichkeiten, auf die fehlenden Informationen zu den anderen "tags"-Werten und den dabei verwendeten Strukturen habe ich schon hingewiesen) eine 1:1-Kopie des AVM-Formats erzeugen wird und kann (schon um Nachfragen oder Kritik an dieser Stelle zuvorzukommen), änderst Du das ebenfalls "mit einem Federstrich". Es steht meines Wissens nirgendwo geschrieben, daß die FDTs in diesem Bereich nur in streng aufsteigender Folge der "HWSubRevision" hinterlegt werden müssen - dank des Codes in "init/avm_kernel_config.c" (den Du auch kanntest bzw. kennen konntest, ich habe ihn oben komplett eingefügt) wird die jeweilige Adresse in ein Array unter dem richtigen Index eingetragen und auch eine Reihenfolge 0, 3, 1 läge im Rahmen der Möglichkeiten bzw. würde mit dem veröffentlichten AVM-Code funktionieren. Das ist bei Deinem Iterieren über die FDTs aber nicht mehr der Fall ... und selbst wenn es das bei AVM gar nicht geben sollte (ich weiß es nicht, aber Du kannst es eigentlich auch nicht wissen) oder es bei den Teilen, die AVM veröffentlicht, vermutlich auch gar keine Rolle spielt (auch hier weiß keiner von uns, was in den LKM von AVM ggf. noch passiert), ist das eine Änderung meines Paradigmas, daß eine 1:1-Kopie erzeugt werden soll.

    - Die Frage, ob eine Formulierung:
    Code:
    if (!(avm_kernel_config_tags_undef < tag && tag <= avm_kernel_config_tags_last))
    		return false;
    besser und leichter zu lesen ist, als es
    Code:
    if (tag != 0 && tag > avm_kernel_config_tags_last) return false;
    wäre (die 0 hätte ich tatsächlich gegen die Enum-Variable für "undef" tauschen können, das wäre die einzige von mir "akzeptierte" Änderung), liegt sicherlich auch im Auge des Betrachters ... Negation und Klammerung machen es eben gerade nicht einfacher, den Sinn nachzuvollziehen, solange man sich nicht ständig damit befaßt. Auch an anderen Stellen bist Du offenbar "Fan" von Ausdrücken, an denen sich "Nicht-Programmierer" (und nicht jeder hat Boolesche Algebra resp. die "De Morganschen Regeln" mit der Muttermilch eingesogen oder hat das Bedürfnis, "Klammern auszuzählen") das Hirn verrenken können:
    Code:
    	if (!((avm_kernel_config_tags_device_tree_subrev_0 <= entry->tag) && (entry->tag <= avm_kernel_config_tags_device_tree_subrev_last)))
    return;
    ... aber das ist tatsächlich eine Frage des eigenen Stils und der eigenen Erwartungshaltung, an wen sich diese Zeilen am Ende richten und wer sich einem "Review" widmen wird. Nur Deine Haltung, daß Deine Art der Formulierung die einzig richtige ist und daher diese auch "durchzudrücken" wäre, geht mir auf den Zeiger.

    - Das gilt genauso für Deinen Commit 9defda1 ... wenn ich hingehe und in meinem Code die lokalen Definitionen so formatiere, daß nach der längsten Typ-Definition die Namen an einer einheitlich eingerückten Stelle stehen (und die Anzahl der Tabulatoren war ja nicht ausgewürfelt, die hatten ihren Sinn), dann empfinde ich diesen Commit als "äußerst aufdringlich", weil auch hier wieder der Impetus anklingt: "Ich weiß es viel besser als Du, wie man so etwas richtig formatiert.". Die Datei enthielt eine "modeline" für die unter Linux üblichen Editoren in Zeile 1 und damit wäre es eben an Dir gewesen, Deinen Editor auf 4 Zeichen Tabulator-Breite einzustellen (wenn er das nicht automatisch auf die Reihe kriegt dank der "modeline") und nicht, mir mal zu zeigen, wie man "richtig formatiert" (daher mein Verweis auf "style guides"). Immerhin beruhigt mich aber Dein Tippfehler mit dem doppelten "i" im Commit-Text dann dahingehend, daß auch Du nicht vor "typos" gefeit bist.

    - Wenn Du tatsächlich erkannt haben solltest, daß Deine Änderungen der "while"- in "for"-Schleifen "rein subjektiv" waren, erklärt das aber immer noch nicht, warum nun Dein (subjektives) "Schönheitsempfinden" (das gilt auch für die Formulierung "Vereinfachung/Verschönerung des Codes") das sein sollte, was hier "gewinnt". Auch hier komme ich wieder auf "style guides" zurück und Dir ist sicherlich nicht entfallen, daß wir bereits in der Vergangenheit an dieser Stelle ernsthafte und erbitterte Debatten hatten. Ich empfinde es in der Tat als äußerst "ungehörig", wenn jemand stets und ständig in den Quelltexten anderer "herumändert", nur um seine eigenen Vorstellungen (und die sind eben weder "festzumachen" noch irgendwo niedergeschrieben oder gar "abgestimmt") obsiegen zu lassen. Das ist für mich keine "Zusammenarbeit", wie sie nun einmal in Community-Projekten notwendig ist (da muß man auch die Arbeitsweise von anderen akzeptieren oder man einigt sich eben auf solche "style guides") und unsere Meinungsverschiedenheiten an dieser Stelle waren ja auch der Auslöser dafür, daß ich meinen Trac-Account gelöscht habe und dort gar nichts mehr schreibe. Ich hatte die Hoffnung, daß es Dir gelingen würde, Dich in dieser Richtung auch etwas zurückzunehmen ... nach dem, was Du hier gezeigt hast, war das offensichtlich ein Irrtum meinerseits.

    Aber das ist mir am Ende auch egal ... ich wollte nur eine Erklärung/Begründung geben, warum ich nicht voller Euphorie auf Deinen Fork und Deinen Text in #57 reagierte. Noch einmal: Das steht alles unter GPLv2, Du kannst das forken und ändern, wie Du möchtest ... ich bin allerdings nicht bereit, bei künftigen Änderungen durch AVM und an mich "delegierten" Recherchen/Änderungen an dieser Stelle, auf der Basis Deiner Änderungen fortzufahren - mich "überzeugen" eben lange nicht alle Deine Commits und das Lesen wird (für mich jedenfalls) dadurch auch nicht zwangsläufig einfacher. Solange es nicht einen Dritten in der Rolle des "Schiedsrichters" gibt (oder eben abgestimmte(!) "style guides" und insofern bin ich bei "Die Freetz-C-Code-Style-Guides nehme aus dem gegebenen Anlass in Angriff." auch ein wenig skeptisch, inwieweit diese dann die Auffassung mehrerer oder doch nur eines einzelnen wiedergeben werden), ist das aber auch alles Spiegelfechterei, was wir hier betreiben und ehe es wieder zu "richtig schlechter Stimmung" kommt, würde ich das Thema dann auch begraben wollen.

Seite 3 von 4 ErsteErste 1234 LetzteLetzte

Ä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
  •