[Info] Fehlende Bestandteile im OpenSource-Paket von AVM

Ich behaupte ja immer wieder gerne, daß die von AVM für die Kernel-Versionen ab 03.xx veröffentlichten Quelltext-Pakete unvollständig sind, weil bereits für den Start des Systems ein entscheidender Bestandteil fehlt (der FDT mit der Hardware-Beschreibung nach OF-Spezifikation).

Ich habe mich jetzt mal des Themas angenommen und einen Weg bis zum Ende umgesetzt, wie man einen eigenen lauffähigen Kernel (zumindest hat der bei mir beim Schreiben des Systems in den Flash funktioniert - das System startete also auf jeden Fall und das ist schon mal mehr, als man sonst mit einem eigenen Kernel auf der Basis der AVM-Quellen erreichen kann) erzeugen kann.

Es braucht ein paar Programme und Shell-Skripte, die habe ich in meinem GitHub-Repository unter https://github.com/PeterPawn/YourFritz/tree/master/avm_kernel_config abgelegt habe.

Ausgangspunkt ist ein Dump des Bereiches zwischen den Symbolen __avm_kernel_config_start und __avm_kernel_config_end, wo AVM in 64 KB irgendwelche modell- und versionsspezifischen Konfigurationen unterbringt. Diesen Dump kann man auf mehreren Wegen erzeugen, dazu komme ich später.

Aus dem Dump des Bereiches wird dann mittels "gen_avm_kernel_config(.c)" (mit "-m32 -std=c99" übersetzen) ein Quelltext-File in Assembler generiert, dabei wird der Inhalt der FDT-Bereiche gleich direkt aus dem Dump verwendet und nicht aus den übersetzten dts-Dateien von AVM (in arch/mips/boot/dts) zusammengestellt.

Um das etwas flexibler zu gestalten, werden anstelle direkter Assembler-Anweisungen (es sind ja ohnehin nur Datendefinitionen) ein paar Makros verwendet, diese finden sich in "avm_kernel_config_macros.h" - damit muß diese Datei dann auch in das Verzeichnis mit dem generierten Assembler-Quelltext kopiert werden; beide Dateien gehören in das Verzeichnis "linux-3.10/arch/mips/kernel", wobei das Include-File mit den Makros statisch ist, während der Assembler-Quelltext zumindest für jedes Modell und wohl auch für jede AVM-Firmware-Version neu generiert werden muß (weil sich die "size"-Angaben bei den LKM jederzeit ändern können).

Im Anschluß braucht es noch die drei Patches für Freetz (die 90x-Dateien im Repository, wobei eine davon die "avm_kernel_config_macros.h" erzeugt), um das Übersetzen des Assembler-Files und das Linken mit dem Kernel zu veranlassen.

Wie kommt man denn nun an den Dump dieses Bereiches?

Es gibt m.E. zwei (oder drei) denkbare Wege ... einer besteht im Kopieren des Bereiches aus einem laufenden System heraus (damit natürlich auf einer FRITZ!Box, wo das originale System von AVM läuft), dafür habe ich das Skript "dump_kernel_config.sh" erstellt.

Nun ist das aber ein denkbar undankbares Unterfangen, wenn man das (wie bei Freetz zu erwarten) im Build-Prozess automatisieren will. Also gäbe es noch die Möglichkeit, den originalen Kernel von AVM zu entpacken und in dieser Datei dann nach dem Abbild dieses Bereiches zu suchen.

Da dort ja der Inhalt des FDT für die Hardware-Beschreibung zu finden ist, kann man auch den binären Inhalt eines solchen FDT (der kann mittels "dtc" aus den Dateien in "arch/mips/boot/dts" erzeugt werden) als "Anker" für das Suchen des richtigen Bereiches im entpackten Kernel verwenden. Das setzt das C-Programm "extract_avm_kernel_config(.c)" um ... es braucht neben dem bereits entpackten Kernel (entweder mit "unpack_kernel.sh" aus meinem Repository oder auch mit dem "unpack-kernel" aus den Freetz-Tools aus dem gepackten AVM-Kernel erzeugt) noch die "dtb"-Datei für den ersten FDT (der für HWSubRevision 0, falls es mehrere für ein Modell gibt), damit dieser Inhalt im Image gesucht werden kann.

Dabei habe ich dann irgendwann festgestellt, daß es sogar recht einfach machbar ist, mit der Signatur "d0 0d fe ed" für einen FDT bei der Suche über den entpackten Kernel den Bereich ebenfalls zu lokalisieren. Das habe ich allerdings nicht mehr als Programm umgesetzt, man müßte vermutlich noch ein paar zusätzliche Plausibilitätsprüfungen für so eine Fundstelle einbauen, damit man sich dabei nicht irgendwann doch mal mächtig verzockt, weil ein "false positive" als Fundstelle auftaucht.

Wie man das jetzt in den Build-Prozess von Freetz integrieren könnte, weiß ich auch nicht genau bzw. vermutlich sind da die Vorstellungen recht unterschiedlich.

Es ist jedenfalls schon mal ein Paradigmenwechsel, wenn vor der Übersetzung der Kernel-Quellen noch aus dem jeweiligen AVM-Kernel für das Zielsystem etwas zu extrahieren ist ... im Normalfall ist bei der bisherigen Reihenfolge der Abarbeitung in der Freetz-Toolchain zu diesem Zeitpunkt noch nicht einmal der Download des AVM-Images erfolgt, geschweige denn, daß dieses Image oder der dort enthaltene Kernel entpackt wäre. Aber ich sehe praktisch keinen anderen Weg, außer es wird für jeden Kernel von AVM bereits vorher die Assembler-Datei erzeugt und als Quelltext in Freetz "mitverwaltet" - spätestens bei Labor-Versionen ein Schrecken ohne Ende.

Ich habe die Lösung bisher nur mit der 113.06.60 von AVM ausprobiert - da mein Freetz-Fork im Moment etwas mit dem Original auseinandergelaufen ist, weiß ich auch nicht, wie weit die 06.60 derzeit im Trunk funktioniert ... als Firmware-Version ist die ja bereits seit CS 13814 drin, aber die Kernel-Quellen der 06.60 sind wohl noch nicht integriert. Da die auch für Freetz "aufbereitet" werden müssen (und der Download dann auch nicht mehr direkt bei AVM erfolgt) und das in Anbetracht des "delta concepts" nicht "von außen" machbar ist, habe ich dafür ein eigenes Archiv der Kernel-Quellen von AVM erstellt und unter http://yourfritz.de/7490/linux-7490-06.60.tar.xz abgelegt (md5sum: 6cc063e4f4c1d9c93e1c68d7f2c2e832).

Wer das also ohne Vorarbeiten von @er13 (oder wer auch immer das integrieren will oder wird) selbst umsetzen will, muß unter "Override options" entsprechende Einstellungen vornehmen und zusätzlich die ganzen Anpassungen für die Unterstützung der 06.60-Quellen im Trunk nachrüsten. Da das nicht ganz so einfach ist, würde ich das nur jemandem empfehlen, der sich damit wirklich auskennt ... vielleicht läßt sich ja auch @er13 entsprechend erweichen und investiert die knappe Zeit an dieser Stelle, damit wieder eigene Kernel mit den auf Linux 3.xx basierenden Firmware-Versionen von AVM verwendet werden können (zumindest nicht mehr an der fehlenden Konfiguration in init_avm_kernel_config() scheitern).

Wenn in Freetz die Entscheidung für den "dritten Weg" bei der Suche nach dem AVM-Bereich im entpackten Kernel fallen sollte (wobei das Übersetzen des passenden FDT für die Suche sicherlich auch keine so ganz schlechte Idee ist), dann würde ich ggf. noch einmal mit anpacken und die Prüfung der Plausibilität gefundener Daten nachrüsten.

Wenn ich das auf die Schnelle richtig sehe in den Quellen für 06.61, ist da in Bezug auf "avm_kernel_config" nichts Neues enthalten - das sind fast alles Änderungen, die mit dem Event-Handling im "avm_new"-Verzeichnis zusammenhängen und ein paar Events neu einführen bzw. alte umbenennen oder auch die verteilte Verwaltung solcher Events unterstützten, sowie deren Auswertung (wohl aus irgendwelchen Log-/Trace-Quellen, die dem normalen Benutzer dann ohnehin nicht zur Verfügung stehen).

Das hätte ich dann auch fast als Vorsatz definiert, wenn ich wochenlang bei AVM anfrage, ob man nicht mal funktionierende Quellen veröffentlichen will und innerhalb der Woche nach dem ersten Einchecken einer Version in GitHub tut sich da doch noch etwas. Ich habe zwar nichts dagegen, daß/wenn das von AVM tatsächlich mal ordentlich veröffentlicht wird, aber wenigstens eine Woche "Nützlichkeit" würde ich mir schon wünschen. Wenn es ohne weiteres von AVM "glattgezogen" werden kann/könnte, hätte man das ja freundlicherweise bereits vorher mal tun können.

Ich bleibe ohnehin dabei, daß dort die Trennung zwischen "closed source" und "open source" etwas verschwommen ist ... das "Zählen" des Speicherbedarfs so eines LKM, das gar nicht in Quelltext- oder Objekt-Format vorliegt, dürfte nicht so einfach zu machen sein - damit ist zumindest das Erstellen der avm_modulmemory-Struktur vermutlich etwas problematisch.

Weil die ohnehin aus dem originalen AVM-Bereich ausgelesen werden muß, verzichte ich auch bei den FDT-BLOBs auf das Einbinden über ".incbin" o.ä. (wenn das überhaupt funktionieren würde, habe ich nicht einmal richtig getestet) - solange die veröffentlichten Pakete keine Auswahl des korrekten Modells möglich machen (es gibt ja nicht einmal die Dateien unter "arch/etc/init.d/rc.$(KERNEL_CONFIG).init", mit denen der Inhalt von "AVM_NEW_HWREV_LIST" gesteuert würde in "drivers/char/avm_new/init_avm"), müßte man da auch für das Einbinden des richtigen "dtb"-Files immer von Hand ändern.

Wenn man sich das OpenSource-Paket mal wirklich richtig zu Gemüte führt, ist es schon ziemlich dreist, wie AVM hier auf die GPL pfeift - eigentlich ist es ein Skandal, der interessiert nur niemanden so richtig. Von der Möglichkeit, mit den veröffentlichten Paketen tatsächlich eine eigene Firmware zu erzeugen (wie es die GPLv2 eigentlich verlangt, wenn man den Kernel mit dem Rest der Firmware untrennbar verbunden - zumindest für den normalen Nutzer - ausliefert), ist man so meilenweit entfernt, daß nicht einmal pro forma den Lizenzbestimmungen entsprochen wird. Weder ist das Komprimieren des Kernels für die Verwendung mit dem Bootloader der FRITZ!Box in den Quellen enthalten, noch wird irgendwo das Programm zum Erstellen des SquashFS-Images (mit "AVM-Geschmack") im Build-Prozess erzeugt. Angesichts der Tatsache, daß so ein SquashFS-Image und der Kernel bei einigen Modellen sogar als einzelne Datei "kernel.image" von AVM "vertrieben" werden, ist das ein ziemlich starkes Stück ... vermutlich wird man sich dann auf Unkenntnis oder Unfähigkeit herausreden, wenn das wirklich irgendwann mal zur Sprache kommt.

Abgesehen davon findet sich in den Quellen der 06.61, die am 06.10.2016 zusammengepackt wurden, noch keinerlei Hinweis auf die Korrektur eines Problems durch das Schreiben "out of bounds" unter bestimmten Umständen in einem AVM-Kerneldriver ... und das, obwohl ich hier eine E-Mail vom 23.09.2016 habe, in der das Problem bestätigt wurde und gleichzeitig angekündigt wird, das in der nächsten Labor-Version bereits zu beheben. Nun werden diese Quellen wohl nicht für die Labor-Version sein und ich habe tatsächlich bisher keine Lust gehabt, das im Laborzweig erneut zu überprüfen (das geht ohne Kernel-Debugger und serielle Schnittstelle ohnehin fast nicht), aber ich hätte in meiner Einfalt eben auch erwartet, daß das Problem in anderen Versionen als dem Labor auch behoben wird. Angesichts der Tatsache, daß da (mit entsprechendem Aufwand) auch das Einbringen von fremdem Code möglich sein dürfte/sollte (auch wenn das im Moment immer noch einfacher geht), sollte das auch nicht auf die lange Bank geschoben werden - 14 Tage sind seit dieser Bestätigung nun auch schon wieder um (meine Meldung zur Lücke war bereits vom 13.09.2016).

Irgendwie kann ich mich ohnehin des Eindrucks nicht erwehren, daß AVM entweder mit dem Fixen von Lücken gar nicht hinterherkommt oder das als "geplant in Q3/2016" mal avisierte nächste "major release" noch nicht einmal Einzug in die derzeit aktuelle Labor-Reihe der 7490 gefunden hat. Bis zur vorhergehenden Version (41222) konnte ich jedenfalls noch so ziemlich jedes seit Juni von mir gemeldete Problem (inzwischen sind es 7, die nicht unter NDA fallen) auch weiterhin in den Labor-Versionen entdecken - da tut sich praktisch gar nichts bei deren Behebung.

- - - Aktualisiert - - -

@opto:
Mach mal ein "objdump -x avm_kernel_config_area.o" ... ich hatte am Beginn auch das Problem (obwohl ich es kannte und im anderen Thread mal angerissen hatte, bin ich erst einmal in diese Falle gelaufen), daß der x86-Assembler und die MIPS-Variante das ".align" tatsächlich anders behandeln (das x86-Listing sah gut aus, bei MIPS hatte ich immer 256 KB) und das ".align 16" zu einem ".align 2**16" ausartete, was dann zu einem zu großen Object-File führte.

Die zwei Definitionen in der Makro-Datei (bzw. im Patch dafür) sind harmlos - nichts weiter als ein Überbleibsel aus der Zeit, als ich das noch als ".data"-Section erzeugen wollte und entsprechende IDs für die "subsections" brauchte.

- - - Aktualisiert - - -

Das Rücksetzen des "location counters" auf kleinere Werte beim Linken resultiert natürlich auch aus der Überlänge des erzeugten Bereiches ... ist der kleiner als 64K, geht das dort auch vorwärts und nicht nach hinten.

- - - Aktualisiert - - -

Argh ... ich hatte noch eine Stelle in "gen_avm_kernel_config.c" nicht an das richtige Alignment angepaßt (da stand noch "16" anstelle von "4"), ist jetzt korrigiert, mußt Du die Assembler-Datei noch einmal erstellen lassen. Eigentlich Schwachsinn meinerseits, da ein ".align" in das C-Programm einzubauen, ändere ich vermutlich noch einmal - aber erst im Laufe des Tages und nicht sofort. Mit dem ".align 4" sollte die Größe dann auch wieder stimmen.

Die Änderung ist komplett eingecheckt inzwischen (das Alignment findet jetzt nur noch in den Makros statt) -> und ja, 2**16 == 64 K und damit ist auch klar, warum bei Dir als Offset 0x10000 steht.

Das Thema mit AVM und der GPL ist mir ja durchaus auch bekannt ... es kann trotzdem nichts schaden, das auch ab und an noch einmal ins Gedächtnis zu rufen, schon damit hinterher niemand sich herausreden kann (auch AVM ist von mir auf den betreffenden Thread hingewiesen worden), er/sie hätte ja davon gar nichts ahnen können und wenn man davon gewußt hätte, wäre eine Korrektur ja selbstverständlich schon vor langer Zeit erfolgt.

Wie geschrieben ... bei mir wurde dann das so erzeugte Freetz-Image (ich habe einfach die "kernel.raw" und "kernelsquashfs.raw" hintereinander kopiert und in den Speicher geladen, also nichts bei "/sbin/flash_update" im Wrapper angepaßt) ins Flash geschrieben, der Kernel ist also erfolgreich gestartet und daß es ein Freetz-Image war beim nächsten Start, habe ich an der Versionsnummer und beim Versuch des Telnet-Logins dann gesehen, wo der Prompt den Hostnamen enthielt (beim AVM-Telnet ist das nicht der Fall).

Ansonsten habe ich ja keine Freetz-Konfiguration in der Box und so habe ich dann auch ganz schnell wieder auf das alternative System zurückgeschaltet.

Aber mit der .config aus meinem Quelltext-Archiv auf yourfritz.de wurde zumindest ein funktionierender Kernel gebaut ... nun werde ich mal bei Gelegenheit sehen, daß ich da das "overlayfs" als Backport hineinbekomme und auch die NFS-Unterstützung wieder ins Laufen kommt - das sind die Stellen, wo ich einen eigenen Kernel benutzen würde.

Das Aufteilen in mehrere Patch-Dateien ist dann auch wieder Absicht ... i.d.R. nimmt das sonst @er13 erst wieder auseinander, hier muß er nur darüber nachdenken, was er zu einem gemeinsamen Patch zusammensetzen will.

Die passende Konfiguration fehlte wirklich, habe mal eine ins Repo eingecheckt.

Ich hatte schon überprüft, daß es auch wirklich mein Kernel war, der da startete ... ich habe den mal unter http://yourfritz.de/7490/kernel_06.60.bin bereitgestellt, kannst ja selbst damit probieren.

Die simplen Sachen wie Mounten des Root-FS und das Starten der Einträge in der /etc/inittab kann man ja ziemlich leicht prüfen, wenn man sein Dateisystem entsprechend anpaßt.

Ich hatte nur das Problem, daß mit diesem Kernel das DSL nicht synchronisieren wollte ... woran das nun wieder liegen könnte, hat mich erst einmal nicht weiter interessiert, weil es mit einiger Sicherheit eine vollkommen andere Baustelle ist (schon die 300 KB, die der Kernel kleiner ist als der von AVM, brauchen ja einen Grund).

Mach Dir doch einfach ein Dateisystem, wo ein externer Syslog-Server benutzt wird und auch /dev/debug ins Netz geschrieben wird (ggf. noch ein "echo AVM_DBGEOF 0 >/dev/debug" vorneweg, damit das durchläuft als Prozess), notfalls noch ein "dmesg" mit Ausgabe ins Netz alle 10 Sekunden, usw. ... nur rein deduktiv wird man so einem Problem kaum auf die Schliche kommen.

Bei mir ist WLAN an (kein Gastnetz) und das ging (aus der Erinnerung, weil ich mich bei der "Netzwerkbereitschaft" immer an der WLAN-LED orientiere) auch ... allerdings habe ich es nicht bewußt genutzt.

Ich würde erst einmal sauber die Probleme trennen ... die erste Frage wäre halt, ob es an der Struktur des erzeugten Bereiches im Kernel liegt und die vergleicht man wohl am besten, indem man einen neuen Dump des Bereiches mit dem Konifgurationsdaten macht (gleich wieder ins Netz, aus der /etc/inittab heraus) und die beiden Inhalte (den von AVM und den eigenen) miteinander vergleicht - bis auf die ggf. abweichenden Ladeadressen sollte der Inhalt übereinstimmen.

Was dann ggf. den Kernel ansonsten noch vom sauberen Start abhalten könnte, ist wieder eine vollkommen neue Fragestellung - bisher kommt er ja nicht einmal bis zum Laden der LED-Treiber, wenn der Bereich im Kernel nicht passend befüllt ist.

Noch mal ... die Änderung soll nur den richtigen Inhalt des Bereiches zwischen den Symbolen __avm_kernel_config_start und __avm_kernel_config_end reproduzieren - für andere Probleme ist sie nicht zuständig.

Ob sie wirksam ist und das erwartete Ergebnis abliefert, kann man auch einfach bereits im Freetz-Buildsystem überprüfen ... die "System.map" sollte die Adresse von __avm_kernel_config_start wiedergeben und wenn man dann die 0x2000 Byte Verschiebung (von der Lade-Adresse des Kernels bei 0x80002000 ausgehend, wobei die Adresse wieder KSEG0 ist und die höchstwertigen Bits im Geiste maskiert werden müssen) noch dazurechnet (bzw. hier eher abzieht), dann findet man die Verschiebung im entpackten Kernel, an der man genau den replizierten Speicherinhalt wiederfinden sollte.

Ist das der Fall, liegt ein nachfolgendes Problem beim Starten eher nicht mehr an diesen fehlenden Daten ... hier vom anderen Ende her (der Kernel läuft nicht) auf ein Problem mit dem Inhalt des Bereiches zu schließen, ist etwas weit hergeholt - dann muß man eben Schritt für Schritt vorangehen und dazu gehört es, daß man für den eigenen Kernel die Änderungen erst einmal so klein wie möglich hält.

Ich traue mich jedenfalls keinesfalls, hier auch nur im Ansatz realistisch einzuschätzen, welche der bei Dir als LKM erzeugten Crypto-Funktionen nun vom WLAN benötigt wird und hier ggf. einfach noch nicht geladen wurde - das würde zumindest erklären, warum die WLAN-LED mit schnellem Blinken ein Problem bei der Initialisierung des WLAN verkünden könnte.

Wenn die LKM ohnehin alle gleich beim Start geladen werden sollten (keine Ahnung, ob nun zuerst Freetz oder das WLAN startet), dann kann man sie auch gleich mit einlinken lassen und auf den Bau als LKM verzichten. Für mich ist der Gaul hier etwas vom verkehrten Ende her aufgezäumt ...

Es ging bei dieser Änderung nur darum, daß da überhaupt ein eigener Kernel startet ... alles andere war mir vollkommen unwichtig bei diesem Test. Wenn man das systematisch untersuchen will, muß man erst mal wieder nachsehen, wie sich z.B. die Kernel-Symbole beim AVM-Kernel und beim eigenen unterscheiden und was AVM da ggf. noch "unterschlagen" hat in den Quellen und was damit noch fehlen könnte.

Das war ja für 2.6 alles recht gut untersucht und nachgebaut in Freetz ... seitdem AVM den 3.10-Kernel verwendet, fehlen eben neue oder andere Komponenten und das hier sollte nur ein erster Schritt sein, dem entgegenzuwirken.

Das heißt noch lange nicht, daß jetzt ein eigener Kernel in allen Punkten funktionieren wird ... es wurde nur (auch nur auf einem denkbaren Weg, man hätte auch das Fallback auf einen fest eingelinkten FDT einbauen können, anstatt den AVM-Ansatz nachzuentwickeln) erst einmal die erste Hürde dabei genommen, an der ansonsten bereits der Start des Systems scheiterte (siehe der andere Thread, den ich in #1 verlinkt habe).

Ich persönlich habe ohnehin wenige Berührungspunkte mit einem eigenen Kernel und daß ich das hier überhaupt in Angriff genommen habe, lag nur daran, daß es sonst niemand (zumindest nicht bis zum Ende und bis zu einem startenden Kernel) gemacht hatte.

Nur für das Kompilieren eigener LKM braucht man ja noch keinen eigenen Kernel, mit dem das Gerät wirklich läuft - nur die passende Konfiguration des Kernels für das Erstellen des LKM.

Ansonsten müßte man ja auch bei "normalen Distributionen" für jedes neue LKM (und es gibt ja noch genug Hersteller, die nur Source-Pakete bereitstellen, die der Kunde/Besitzer einer Hardware selbst übersetzen muß) den kompletten Kernel neu kompilieren und vielleicht sogar ersetzen.

Erst dann, wenn eine zusätzliche Option auch Auswirkungen außerhalb so eines LKM hat (z.B. muß beim "overlayfs" der passende Hook im Code für den Filesystem-Zugriff erst einmal vorhanden sein, sonst würde auch ein "overlayfs.ko" nie benutzt nach dem Laden), muß man auch den Kernel ersetzen - ähnliches gilt dann für NFS und vieles andere, was etwas tiefer im Kernel verankert ist, dort führt eine zusätzliche Option in aller Regel auch zu zusätzlichem Code im Kernel, der natürlich dann auch mit übersetzt werden muß.

opto schrieb:

Nicht immer! Für NFS Support als modul muss der Kernel vorher schon konfiguriert sein

Zum Vergrößern anklicken....

Habe ich doch genauso auch geschrieben am Nachmittag? :gruebel:

Mehr Input ... ich brauche Input. (Man kommt sich vor, wie in einem älteren Film mit einem niedlichen Roboter.)

Gesetzt den Fall, das erste ist der Versuch mit dem eigenen Kernel und das am Ende einer mit dem von AVM, dann stellt sich trotzdem die Frage, was die ganzen "REJECTED"-Meldungen da zu suchen haben ... das liest sich für mich mehr wie ein Problem beim Entpacken des Kernels und da stellt sich dann die Frage, woher das kommen könnte. Eigentlich kann das bei LZMA-Kompression nur dann passieren (es fehlen ja sämtliche redundanten Informationen im Kernel, die kleinere Fehler glattbügeln könnten), wenn da ungültige Daten vorliegen und die "state machine" beim Entpacken den Baum nicht korrekt absuchen kann, um den dekomprimierten Inhalt zu finden.

Wenn ich mal davon ausgehe, daß es sich um einen in den Speicher geladenen Kernel handelt, dann kann es auch kein Fehler im (NAND-)Flash sein. Also "back to the roots" und den eingepackten Kernel noch einmal entpacken und - wenn dabei nicht bereits Fehler auftauchen - mit dem originalen Kernel vor dem Einpacken vergleichen. Das "fallback" auf HWSubrevision 0 sollte jedenfalls auch stattfinden können ... wenn da die "Missing"-Meldung kommt, hat er eher gar keinen FDT im fraglichen Bereich gefunden, was mich dann wieder am korrekten Linken zweifeln läßt.

Im grünen Teil wird solange in Richtung "HWSubRevision 0" gesucht, bis kein Eintrag mehr vorhanden ist oder die nächstkleinere Subrevision gefunden wurde. Das Problem dürfte hier eher sein, daß das Array bei "avm_kernel_config_device_tree" nicht richtig befüllt ist und da das normalerweise in "avm_init_kernel_config()" passiert, sollte das eigentlich nicht vorkommen:
Wenn man dann allerdings etwas nachdenkt und einem wieder einfällt, daß der Aufruf dieser Funktion in den 2.6er-Versionen im Trunk auskommentiert wurde (http://freetz.org/browser/trunk/make/linux/patches/3.10.73/170-init_avm_kernel_config.patch), dann stellt sich die Frage, ob Du ggf. vergessen haben könntest, diesen Patch zu deaktivieren.

Danke für den Test ... dann ist das Thema mit der "avm_kernel_config" für mich erst einmal durch, bis sich ggf. @er13 meldet und doch das Extrahieren der Daten mit Signatur und Gültigkeitsprüfung verwenden will anstelle der Suche nach dem kompletten übersetzten FDT für HWSubRevision 0.

- - - Aktualisiert - - -

So, ich habe nun doch noch ein paar Änderungen vorgenommen und einige Gültigkeitsprüfungen und die automatische Endianess-Erkennung nachgerüstet.

Mit der Möglichkeit der Kontrolle des FDT-Aufbaus (über die "libfdt", die beim "dtc" in den Kernel-Quellen existiert) war dann die Suche im entpackten Kernel auch ohne "dtb"-Datei keine wirkliche Hürde mehr, das kann einen Arbeitsschritt in der Freetz-Toolchain sparen - wenn meine Annahme stimmt, daß die HWRevision gar nicht ohne weiteres in Freetz verfügbar ist, dann wäre das sogar recht haarig geworden, da das richtige "dtb"-File für die Suche auszuwählen.

Beim Erstellen der beiden Tools für den Build-Host (extract_avm_kernel_config und gen_avm_kernel_config) muß u.U. im "Makefile" der Pfad zum Verzeichnis "scripts/dtc/libfdt" innerhalb der Kernel-Quellen richtig gesetzt werden ... das hängt ja dann auch davon ab (zumindest bei relativen Pfaden), wo man diese Tools in der Verzeichnisstruktur erstellen läßt.

Jetzt ist dann aber wirklich Schicht im Schacht bei dieser Geschichte ... solange sich nicht noch irgendwelche katastrophalen Fehler einfinden, sollte das Thema (zumindest bis zur nächsten Änderung bei AVM) erst einmal durch sein.

Ich hatte noch kurz überlegt, ob man auf das externe Entpacken des Kernels verzichten könnte und gleich den gepackten als Eingabe akzeptiert und ihn nur intern entpackt - auf der anderen Seite ist das dann auch wieder redundanter Code, denn das gibt es ja alles bereits und das jetzt zur Vermeidung solcher Redundanzen durch internen Aufruf irgendeines anderen "Entpackers" umzusetzen, muß sicherlich auch nicht sein. Auf dem Build-Host sollte es kein Ressourcen-Problem geben, wenn es um das Entpacken des Kernels geht und zeitkritisch ist das ganz sicherlich auch nicht.

Der Bereich enthält selbst wieder Adressen, ist damit also von der absoluten Adresse im Speicher abhängig. Jede Änderung am Kernel, die eine Verschiebung der Startadresse dieses Bereiches verursacht, führt damit automatisch zu einem abweichenden binären Inhalt.

Zwar könnte man den auch "relozieren" (wie es beim Suchen im entpackten Kernel von mir gemacht wird), aber ich würde keinesfalls in irgendwelchen binären Daten herumpatchen ... das ist dann wirklich "nicht sauber".

Wie weit die Größe des Bereiches tatsächlich über die VR9-Modelle konstant ist, weiß ich auch nicht genau ... ich sehe mir die Quellen für andere Boxen als die 7490 nur selten an. Die entscheidende Datei (arch/mips/kernel/vmlinux.lds.S) wrd ja gepatcht und wenn es da bei einem Modell Abweichungen im Original geben sollte:
dann funktioniert es bereits beim Patchen nicht.

Der Konfigurationsbereich steht jedenfalls schon bei ein und demselben Modell (hier eben der 7490) (fast) ständig an anderer Stelle und hat damit in wirklich (fast) jedem AVM-Image auch einen anderen Inhalt - abgesehen davon, daß da auch noch (abweichende) Versionsinformationen zum FRITZ!OS in diesem Konfig-Bereich liegen.

Wenn Du wiederholte Schritte vermeiden möchtest, könnte ich mir höchstens vorstellen, daß Du die generierte Assembler-Datei oder auch die daraus erzeugte Objekt-Datei in die Freetz-Quellen mit aufnimmst. Ob das aber eine gute Idee wäre, weiß ich auch nicht ... was stört Dich denn konkret an der Verwendung von Assembler an dieser Stelle? M.E. führt kein Weg daran vorbei, wenn man denselben Aufbau des Bereiches rekonstruieren will ... das wird in C (oder anderen "Hochsprachen") dann sehr undurchsichtig bzw. es wird wohl nur mit erheblichen Kopfständen überhaupt funktionieren.

Der in der Toolchain erzeugte "gcc" kann ja auch problemlos Assembler-Code übersetzen ... ich hätte eher vermutet, daß Dir die Integration "des Extrahierens" des Konfig-Bereiches aus dem Kernel Kopfschmerzen bereitet, weil eben die Zeitpunkte nicht unbedingt optimal sind in der "make"-Kette. Für das Extrahieren braucht es den aus dem AVM-Image extrahierten und entpackten Kernel und der steht m.W. bisher noch nicht zur Verfügung, wenn der (Freetz-)Kernel für die Box übersetzt wird.

Wenn es "nur" um das Vermeiden einer weiteren Sprache (also MIPS-Assembler) im Projekt geht ... da sehe ich eher schwarz (s.o.), weil das zwar sicherlich machbar ist, aber erheblichen (m.E. unnötigen) Aufwand und wahrscheinlich viele undurchsichtige C-Spielereien (für das passende Layout des gelinkten Bereiches) erfordern würde.

Daß die FDTs (flattened device trees - also die "Hardwarebeschreibung" der Boxen nach OpenFirmware-Standard -> siehe "dtc" in den Kernel-Sources) bei verschiedenen Firmware-Versionen für dasselbe Modell identisch sind, ist eher zu erwarten ... die Hardware ändert sich ja nicht. AVM hat selbst einen Fallback-Mechanismus vorgesehen ... wenn eine neue Hardware-Subrevision keine neue Beschreibung erfordert, sucht der Code selbstständig nach der nächstkleineren Revision (siehe auch #22). Sollte sich die Hardware bei zwei Subrevisionen eines Modells allerdings tatsächlich unterscheiden, wird das AVM sicherlich in seinem Konfig-Bereich entsprechend berücksichtigen ... daher halte ich einen "generellen Rückgriff" auf den FDT für Subrevision 0 (der muß mindestens existieren) im Freetz auch für wenig zielführend ... das kann bei einer tatsächlichen Änderung (z.B. der GPIO-Pins wegen eines neuen PCB-Layouts) mächtig ins Auge gehen.

Es gibt - nur nebenbei - auch Modelle, wo der Bootloader den FDT bereitstellt (die GRX-basierten Boxen sollten dazugehören ... die haben auch einen entsprechend großen Bootloader (8 MB sind bei der 7580 reserviert, wenn ich das richtig in Erinnerung habe), dafür gibt es da natürlich keine Notwendigkeit für so ein "fallback", da ja der Bootloader immer den passenden FDT bereitstellt) und wo der Konfig-Bereich dann wohl nur die anderen Daten enthält.

Der hier für die Module reservierte Speicher hat bestimmte Eigenschaften (er darf z.B. nicht ausgelagert werden) ... wie das genau abläuft mit dieser Reservierung bei der Initialisierung des Systems, kannst Du Dir in der Datei "arch/mips/avm_enh/kseg0_module.c" ansehen - besonders der Kommentar vor der Funktion "module_alloc_bootmem_init" ist aufschlußreich, wenn man sich hinterher noch diese ominöse "Yield"-Implementierung ansieht. Was das (nach meiner Spekulation) sein könnte, habe ich irgendwo auch mal geschrieben ... anhand von "yield" sollte sich das im IPPF leicht finden lassen.

Der alte Mechanismus über "modulemem" im Environment reserviert/blockiert meines Erachtens unnötig viel Speicher mit KSEG0-Attribut ... dort wird ja der gesamte Speicherbedarf der Module anhand von "lsmod" zusammengerechnet und für den nächsten Start ins Environment geschrieben. Sollte dann irgendwann tatsächlich mal die Box wegen einer TLB-Exception (also ausgelagertem Speicher im falschen Moment) abstürzen, weil die vorhergehende Reservierung nicht ausreichend groß war, ist das beim daraus resultierenden Restart (über irgendeinen Watchdog oder eine "kernel panic") ja wieder behoben (sofern das System die 10 Minuten bis zum Zusammenrechnen der Größen überlebt).

Ich nehme einfach an, daß beim neuen Mechanismus der für die relevanten Module angeforderte Speicher mehr dem tatsächlichen Bedarf entspricht und entweder direkt als Angabe per Inline-Definition irgendwo im Module steht und für die Liste im Konfig-Bereich ausgelesen wird oder daß das gleich ein gesondertes (quasi statisches) Speichersegment im Objekt-File ist und dessen Größe entsprechend ausgelesen wird - da gäbe es ja viele Möglichkeiten. Daß die Größe des LKM-Files nicht mit dem tatsächlich benutzten Speicherplatz für so ein LKM korrespondiert, ist ebenfalls klar ... jedes "uninitialized data segment" steht da z.B. nur als Größenangabe im ko-File und event. noch vorhandene Symbole (weil ggf. nicht ge"stripped" wurde) werden per se erst einmal nicht sofort in den Speicher geladen. Damit ist also dort eine Differenz auch nicht verwunderlich ... insgesamt sollte es aber für die von AVM bereitgestellten LKM jeweils weniger sein, als man per "lsmod" auslesen würde; das darf man m.E. jedenfalls unterstellen, solange dann nicht wirklich das komplette LKM in KSEG0-Memory geladen werden soll oder muß. Im statischen char-Array "module_load_black_list" kann man nebenbei bemerkt sehen, welche Module AVM da "ausnehmen" könnte (oder zumindest wohl früher mal konnte) von der Laderei in "non-pageable memory" - inzwischen ist das nur noch ein leeres Array (bzw. mit einem NULL-Entry als Ende-Markierung).

Jedenfalls würde ich diese Liste nicht "frei Schnauze" ändern ... das Ergebnis können schwer zu lokalisierende Probleme mit SEGV-Exceptions im Kernel sein und dann sucht man sich einen Wolf. Für eigene Module ist das mit einiger Wahrscheinlichkeit aber nicht relevant, da diese nur selten die "Yield"-Funktionen von AVM nutzen dürften - habe ich m.E. auch schon irgendwo bei der Diskussion (überwiegend mit mir selbst, was dieses Yield() nun sein mag) angetextet. Damit brauchen die eher keinen KSEG0-Speicher und wenn der Kernel da tatsächlich mal auf eine ausgelagerte Seite treffen sollte für so ein eigenes LKM, dann sollte der normale Paging-Mechanismus diese einlagern können und gut ist's.

Da diese Angaben eben auch von Build zu Build veränderlich sind (kann man bei verschiedenen Labor-Versionen ja auch vergleichen), ist auch hier eine statische Lösung eher wenig hilfreich ... das einzige, was einigermaßen statisch bzw. vorhersagbar ist, wäre die Versionsangabe und die macht dann den Kohl auch nicht mehr fett.

Ich kann ja (in Grenzen) verstehen, daß die Notwendigkeit des (dynamischen) Auslesens aus dem AVM-Kernel die Abläufe im Freetz ggf. etwas durcheinander wirft ... ich sehe aber tatsächlich keine echte Alternative zu dem Weg, das auslesen zu lassen und mit diesen Daten dann ein passendes Objekt-File zu erstellen, welches mit dem eigenen Kernel gelinkt werden kann. Ich würde da auch nichts mit statischen Dateien zaubern, die bei der Integration einer neuen Labor- oder Release-Version dann in den Freetz-Trunk aufgenommen werden ... da ist auf Dauer garantiert der Aufwand wesentlich höher als bei einer (mehr oder weniger einmaligen) Integration des von mir verwendeten/vorgeschlagenen Ablaufs.

Wenn Du vorher abklärst, daß die anderen VR9-Modelle ebenfalls eine feste Größe von 64KB für diesen Bereich verwenden (das müßtest Du in den Deltas für die verschiedenen Modelle ja sofort feststellen können), dann kannst Du auch weiterhin bei der "typbezogenen" Zuordnung (siehe #28) bleiben ... dann muß eben nur vor dem Linken des eigenen Kernels aus der verwendeten Basis-Firmware der Konfig-Bereich ausgelesen und in eine Objekt-Datei umgewandelt werden, die dann beim Linken verwendet wird. Erst wenn es da wirklich Unterschiede geben sollte, müßte man über eine modellspezifische Variable mit der Größe dieses Bereiches nachdenken.

Das spielt ja auch nur dann eine Rolle, wenn jemand einen eigenen Kernel verwenden will ... für eigene LKM ist das vollkommen egal. Wie das bei anderen "Typen" nun aussehen mag, weiß ich nicht und habe ich auch nicht geprüft - aber das gilt ja ohnehin nur für die Boxen, die mit einem 3er-Kernel antreten. Für die 7390 (oder die 6490, um mal auf die E-Mail anzuspielen) ist das dann irrelevant, weil der betreffende Code m.W. erst mit dem 3er-Kernel "scharfgeschaltet" wurde und man nicht mehr einfach das "init_avm_kernel_config()" auskommentieren kann, wie es für die 2.6-Versionen der Fall war im Freetz.