[Info] Fehlende Bestandteile im OpenSource-Paket von AVM

PeterPawn

IPPF-Urgestein
Mitglied seit
10 Mai 2006
Beiträge
15,138
Punkte für Reaktionen
1,703
Punkte
113
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.
 
Zuletzt bearbeitet:
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 ...
 
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).
das der dsl treiber ne eigenes bin file als firmware benötigt das unter ( aus kopf ) /lib/modules/firware/(-s)kernel liegt, das auch zur kernel versionpassen muss, hast du brücksichtig???
 
Zuletzt bearbeitet:
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.
 
nen eigen kompilierter kernel hat immer vorteile, wenn man *.ko's verwenden möchte, die avm nicht beinhaltet...
z.b verwende ich gern nen pl2303 usb wnadler an der kiste um ne saubere externe serielle zu haben...
auch würde micht eine möglickeit interressieren, ibsss oder 802.11s mit der kiste zu machen
 
Zuletzt bearbeitet:
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ß.
 
war bislang meine erfahrung. selbstgebaute *.ko's liefen nur, wenn ich den kernel selbst gebaut hatte. bin halt nur blödr elektiker mit kurzen in der hose.
aber mann lernt ja nie aus. :p
 
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.

Code:
141 void __init plat_device_tree_setup(void) {
142     struct boot_param_header *dtb;
143     if (IS_ENABLED(CONFIG_AVM_ENHANCED)) {
144         char *subrev_str;
145         int subrev = 0;
146
147
148
149         subrev_str = prom_getenv("HWSubRevision");
150         if (subrev_str) {
151             if (sscanf(subrev_str, "%u", &subrev) != 1)
152                 subrev_str = NULL;
153         }
154         if (!subrev_str) {
155             prom_printf("%s: Unable to read AVM hardware "
156                  "subrevision! Identity crisis... who am I?",
157                  __func__);
158         }
159
160         prom_printf("%s: AVM hardware subrevision %d\n", __func__,
161              subrev);
162
163         if (subrev > avm_subrev_max) {
164             prom_printf("%s: Too many hardware subrevisions!\n", __func__);
165             panic("%s: Too many hardware subrevisions!\n", __func__);
166         }
167
168         dtb = (struct boot_param_header *)avm_kernel_config_device_tree[subrev];
169
[COLOR="#008000"]170         if(!dtb) { /* fallback auf nächst kleine SubRev */
171             int i;
172             for(i = subrev - 1; i >= 0; i--){
173                 if(avm_kernel_config_device_tree[i]){
174                     dtb = (struct boot_param_header *) avm_kernel_config_device_tree[i];
175                     prom_printf("%s: using Fallback device-tree of AVM hardware "
176                             "subrevision %d \n",
177                             __func__, i);
178                     break;
179                 }
180             }
181         }[/COLOR]
182
183         if (!dtb) {
184             prom_printf("%s: Missing device-tree for AVM hardware "
185                  "subrevision %d\n", __func__, subrev);
186             panic("%s: Missing device-tree for AVM hardware "
187                  "subrevision %d\n", __func__, subrev);
188         } else {
189             extern struct boot_param_header *initial_boot_params;
190             initial_boot_params = dtb;
191             prom_printf("DT: %02x %02x %02x %02x %02x %02x %02x %02x\n",
192                     ((unsigned char *)dtb)[0],
193                     ((unsigned char *)dtb)[1],
194                     ((unsigned char *)dtb)[2],
195                     ((unsigned char *)dtb)[3],
196                     ((unsigned char *)dtb)[4],
197                     ((unsigned char *)dtb)[5],
198                     ((unsigned char *)dtb)[6],
199                     ((unsigned char *)dtb)[7]);
200         }
201
202     }
203
204     __dt_setup_arch(dtb);
205 }
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:
Code:
 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;
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.
 
Hallo Peter,

zunächst mal - vielen Dank für all die Informationen/Analysen, die Du in diesem Thread mit uns geteilt hast. Eine echt große Leistung!

Ich überlege gerade, wie das Ganze am besten in Freetz integriert werden könnte und hätte folgende Fragen.

1. Ich nehme mal an, dieser 64KB große Config-Bereich unterscheidet sich von Box zu Box (inhaltstechnisch) - er beinhaltet ja (Zitat) "modell- und versionsspezifischen Konfigurationen". Ist die Größe des Bereichs über alle Boxen hinweg aber konstant, sprich immer 64KB (oder zumindest über alle Boxen desselben "Typs" hinweg, e.g. VR9)?
2. Ist es wirklich notwendig den gedumpten Bereich in eine Assembler-Datei umzuwandeln?

Mir schwebt nämlich folgender "Binary Patch"-Integrationsweg vor:
1. Man baue einen Freetz-Kernel, in dem dieser 64KB Bereich mit irgendwelchen per hex-find leicht auffindbaren Dummy-Werten vorbelegt wird (sprich der Bereich wird reserviert, ist aber noch nicht richtig initialisiert).
2. Man dumpe den 64KB Bereich aus dem boxspezifischen originalen AVM-Kernel raus.
3. Man ersetze per "hex-find und replace" den Dummy-Bereich mit dem rausgedumpten Inhalt.

Würde es funktionieren? Oder sind da irgendwelche Adressen/Referenzen enthalten, die dann beim selbstgebauten Kernel zwangsweise anders sind.

Danke!

VG, Gene
 
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:
Code:
--- linux-3.10/arch/mips/kernel/vmlinux.lds.S
+++ linux-3.10/arch/mips/kernel/vmlinux.lds.S
@@ -103,7 +103,9 @@
 		CONSTRUCTORS
 		. = ALIGN(4 * 1024);
 		__avm_kernel_config_start = .;
[COLOR="#FF0000"][B]-		. += 64 * 1024;[/B][/COLOR]
+		arch/mips/kernel/avm_kernel_config_area.o(configarea)
+		arch/mips/kernel/avm_kernel_config_area.o(configareastrings)
+		. = __avm_kernel_config_start + (64 * 1024);
 		__avm_kernel_config_end = .;
 	}
_gp = . + 0x8000;
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.
 
Hi Peter,

der Grund ist ein anderer: Stand jetzt ist der in Freetz gebaute Kernel nur Typ/(eventuell Language)/FritzOS!Version spezifisch und nicht Box/Language/FritzOS!Version. Sprich für alle VR9-Boxen und Fritz!OS-Version-XY wird derselbe Kernel verwendet - sieht man z.B. hier. Der Grund dafür war zum einen der, dass die von AVM veröffentlichten Kernel-Quellen für verschiedene Boxen identisch waren (dies allerdings wahrscheinlich deswegen, weil diese genau den für diesen 64KB Bereich zuständigen Teil nicht enthielten), zum anderen der, dass es für manche Boxen am Ende gar keine Quellen veröffentlicht wurden (z.B. für die international Boxen gibt es in der Regel gar keine Quellen).

Mit meiner Methode habe ich gehofft, einen für alle VR9-Boxen identischen Common-Teil bauen zu können und erst ganz spät den unterschiedlichen Teil rauszudumpen und zu injecten. "Geht nicht" ist auch ok, bedeutet nur, dass es für jede Box dann einen eigenen Eintrag in der bereits genannten config/avm/source.in geben muss => aufwendigeres Testen für mich, größerer Implementierungsaufwand (weil eben für jede Box).

Der Weg des Binären-Patchens wäre auch von der Umsetzung her gesehen (zumindest auf den ersten Blick) einfacher.

Den Prozess des Rausdumpens muss ich noch selbst ausprobieren (bisher nur Deine Beschreibung gelesen). Mit Make-Kette hast Du den richtigen Punkt angesprochen, das muss ich mir noch durch den Kopf gehen lassen. Am Anfang kann ich mir vorstellen, das Ganze nur für 7490.06.60-Release umzusetzen, indem die Assembler-Datei irgendwie manuell außerhalb der Build-Kette erzeugt wird und als "Freetz-Patch zu AVM-Kernel-Quellen" aufgenommen wird... um einfach mal einen Schritt weiter zu gehen, um schauen zu können, welche anderen Überraschungen AVM uns da vorbereitet hat bzw. was mit dem selbst gebauten Kernel alles geht und was nicht (weil z.B. AVM ihn bzw. Teile davon tot-gepatcht hat, wie es z.B. mit IPTables und AVM_PA der Fall ist).

VG, Gene
 
Hallo Peter,

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).
wüsstest Du, um was für "size"-Angaben es sich dabei genau handelt? Ich habe die Angaben aus der generierten Assembler-Datei mit den Größen der .ko-Dateien verglichen (s. die Tabelle am Ende) - und werde daraus nicht schlau. Diese unterscheiden sich nämlich und zwar in beide Richtungen, mal ist der AVM_MODULE_MEMORY-Wert größer, mal der .ko-size. Zumindest stimmt die Anzahl der Einträge in der Assembler-Datei mit der Anzahl der in der Firmware enthaltenen .ko-Dateien überein.

Im Zusammenhang mit den AVM_MODULE_MEMORY-Einträgen stelle ich folgende Fragen (bitte als lautes Denken zu verstehen):

  1. Inwieweit sind diese wirklich relevant? Können sie vielleicht in Gänze weggelassen werden? Sprich die entsprechende Sektion auf "AVM_MODULE_MEMORY 0" reduziert werden. Der Vorteil davon wäre, man müsste sich nicht darum kümmern (im Sinne der nächsten Frage).
  2. Wenn diese doch relevant sind (im Sinne "für jedes Modul muss es einen Eintrag geben, weil an irgendeiner Stelle über diese iteriert wird"), inwieweit sind dann die Größen relevant. Wenn Freetz irgendwelche Module entfernt/hinzufügt/ersetzt, müssen dann auch entsprechende Einträge entfernt/hinzugefügt/korrigiert werden?

Weitere Erkenntnisse (um diese einfach mal zu dokumentieren):
  • Die Sektion "L_avm_device_tree_subrev_0/AVM_DEVICE_TREE_BLOB" für 06.60release ist identisch mit der für 06.69rev42725.

VG, Gene

Code:
                     AVM_MODULE_MEMORY-size     .ko-size        Delta
aae                                  234972       217356        17616
adf                                  258836       274940       -16104
atd                                  266620       318256       -51636
athlogger                             21120        21580         -460
avm_dect                             446504       483660       -37156
avm_pa_fusiv                           6400         1895         4505
capi_codec                           515356       557736       -42380
cdc-acm                               48128        57092        -8964
cdc_ether                             22016        19220         2796
cls_basic                             12928        11296         1632
cls_tcindex                           17792        17740           52
cls_u32                               14336        17384        -3048
crc-ccitt                              8192         3452         4740
crc-itu-t                              8192         3468         4724
dect_io                               18944        19744         -800
dsl_vr9                              529104       555128       -26024
fat                                  104104       121388       -17284
flash_update                          57776        55992         1784
fwd                                   35072        32552         2520
hif_gmac                              29824        28320         1504
ifxmips_ppa_datapath_vr9_a5          233180       272960       -39780
ifxmips_ppa_datapath_vr9_e5          171112       217160       -46048
ifxmips_ppa_hal_vr9_a5                85144       123600       -38456
ifxmips_ppa_hal_vr9_e5                83904       123112       -39208
ifx_ppa_mini_qos                      13568         9896         3672
ifx_ppa_mini_sessions                 49536        60528       -10992
isdn_fbox_fon5                      1108848      1148184       -39336
kdsldmod                            3080913      3092828       -11915
krtp                                 235552       260860       -25308
kspeedtest                            28800        37168        -8368
led_module                           187900       219348       -31448
libcrc32c                              9216         3976         5240
libphy                                55276        55100          176
ltq_eth_oam_handler                   14080        10636         3444
mei_vr9                              350480       322860        27620
msdos                                 14720        18284        -3564
mtdram                                12288         7372         4916
nlaudio                               66740        67456         -716
nls_ascii                              9216         6168         3048
nls_cp437                              9984         7888         2096
nls_cp850                              9600         7028         2572
nls_iso8859-15                         9472         6752         2720
nls_iso8859-1                          9216         6176         3040
option                                13824         9936         3888
pcmlink                              577880       544032        33848
Piglet_noemif                         54528        94804       -40276
rndis_host                            19456        18568          888
rtc-avm                               17408        15280         2128
sch_cbq                               24448        37120       -12672
sch_hfsc                              23680        38128       -14448
sch_htb                               22016        36148       -14132
sch_llq                               19200        22588        -3388
sch_prio                              15360        13848         1512
sch_red                               15104        15288         -184
sch_sfq                               16128        20760        -4632
sch_tbf                               14336        14016          320
scsi_mod                             299375       279692        19683
sd_mod                                68008        78212       -10204
ulpcmlink                             68860        80144       -11284
usb-common                             9728         4672         5056
usbcore                              421807       384116        37691
usblp                                 26240        32688        -6448
usbnet                                58345        67984        -9639
usbserial                             72309        80992        -8683
usb-storage                          110680       120652        -9972
usb_wwan                              21248        21172           76
userman_mod                          175764       194632       -18868
vfat                                  16640        23904        -7264
xhci-hcd                             167052       184888       -17836
 
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.
 
Holen Sie sich 3CX - völlig kostenlos!
Verbinden Sie Ihr Team und Ihre Kunden Telefonie Livechat Videokonferenzen

Gehostet oder selbst-verwaltet. Für bis zu 10 Nutzer dauerhaft kostenlos. Keine Kreditkartendetails erforderlich. Ohne Risiko testen.

3CX
Für diese E-Mail-Adresse besteht bereits ein 3CX-Konto. Sie werden zum Kundenportal weitergeleitet, wo Sie sich anmelden oder Ihr Passwort zurücksetzen können, falls Sie dieses vergessen haben.