Seite 1 von 4 1234 LetzteLetzte
Ergebnis 1 bis 20 von 65

Thema: Fehlende Bestandteile im OpenSource-Paket von AVM

  1. #1
    IPPF Achttausend-VIP Avatar von PeterPawn
    Registriert seit
    10.05.2006
    Ort
    Berlin
    Beiträge
    8.179

    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/YourFri..._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.
    Geändert von PeterPawn (07.10.2016 um 02:37 Uhr) Grund: URL korrigiert

  2. #2
    IPPF-Fan
    Registriert seit
    27.05.2010
    Beiträge
    170
    Cool, gleich mal ausprobieren. Auf 6.60 Sourcen hatte ich schon umgebaut, hättest fragen sollen
    Hast du schon geschaut was die 7490 06.61 Sourcen neues haben? Ist vermutlich das erste mal dass es Quellcode vor dem Image gibt.

    Zitat Zitat von PeterPawn Beitrag anzeigen
    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.
    Labors sind kein Problem, da AVM dafür (fast) nie den Quellcode herausrückt. Falls replace Kernel angeboten, werden bei Freetz Quellen von der letzten Release genommen. Das geht solange gut, wie es keine größeren Änderungen AVMs gibt. Wenn die Quellen nicht zum Image passen, erkennt man dies an hervorgehobenen Meldungen über fehlende Symbole im Log von Freetz (dann geht zB Dect nicht richtig)

    - - - Aktualisiert - - -

    Idee was hier nicht passt? -> S, nicht c ^^
    Code:
    $make kernel-precompiled
    ...
    In file included from arch/mips/kernel/avm_kernel_config_area.c:1:0:
    arch/mips/kernel/avm_kernel_config_macros.h:8:2: error: expected identifier or '(' before '.' token
      .macro AVM_KERNEL_CONFIG_START
      ^
    arch/mips/kernel/avm_kernel_config_macros.h:23:3: error: stray '\' in program
       .int  \tag
       ^
    arch/mips/kernel/avm_kernel_config_macros.h:24:3: error: stray '\' in program
       .ifeq  \tag
       ^
    ...
    - - - Aktualisiert - - -

    Die "avm_kernel_config_macros.h" aus dem Patch und von GitHub sind übrigens nicht gleich:
    Code:
    @@ -2,6 +2,9 @@
     #ifndef _AVM_KERNEL_CONFIG_MACROS_H
     #define _AVM_KERNEL_CONFIG_MACROS_H
    
    +#define        data    10
    +#define        string  11
    +
            .macro  AVM_KERNEL_CONFIG_START
                    .section        "configarea", "a", %progbits
    - - - Aktualisiert - - -

    Bekomme es noch immer nicht hin:
    Code:
    + kallsymso=
    + kallsyms_vmlinux=
    + '[' -n y ']'
    + kallsymso=.tmp_kallsyms2.o
    + kallsyms_vmlinux=.tmp_vmlinux2
    + vmlinux_link '' .tmp_vmlinux1
    + local lds=/home/freetz/freetz/source/kernel/ref-vr9-7490_06.60/linux-3.10/arch/mips/kernel/vmlinux.lds
    + '[' mips '!=' um ']'
    + mips-unknown-linux-gnu-ld -m elf32btsmip -G 0 -static -n -nostdlib --build-id -o .tmp_vmlinux1 -T /home/freetz/freetz/source/kernel/ref-vr9-7490_06.60/linux-3.10/arch/mips/kernel/vmlinux.lds arch/mips/kernel/head.o init/built-in.o --start-group usr/built-in.o arch/mips/built-in.o kernel/built-in.o mm/built-in.o fs/built-in.o ipc/built-in.o security/built-in.o crypto/built-in.o block/built-in.o lib/lib.a arch/mips/fw/lib/lib.a arch/mips/avm_enh/lib.a arch/mips/lib/lib.a lib/built-in.o arch/mips/fw/lib/built-in.o arch/mips/avm_enh/built-in.o arch/mips/lib/built-in.o drivers/built-in.o sound/built-in.o firmware/built-in.o arch/mips/pci/built-in.o net/built-in.o --end-group
    /home/freetz/freetz/source/kernel/ref-vr9-7490_06.60/linux-3.10/arch/mips/kernel/vmlinux.lds:304 cannot move location counter backwards (from ffffffff807c0320 to ffffffff807a9000)
    Makefile:790: die Regel für Ziel „vmlinux“ scheiterte
    Auslöser scheint
    Code:
      . = __avm_kernel_config_start + (64 * 1024);
    wo mögleicherweise ein "+" vorm = fehlt

    - - - Aktualisiert - - -

    Ich versteh das nicht, die config_area scheint bei mir mit 156kB erzeugt worden zu sein
    Geändert von opto (07.10.2016 um 07:01 Uhr)

  3. #3
    IPPF Achttausend-VIP Avatar von PeterPawn
    Registriert seit
    10.05.2006
    Ort
    Berlin
    Beiträge
    8.179
    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.

  4. #4
    IPPF-Fan
    Registriert seit
    27.05.2010
    Beiträge
    170
    Die .o Datei ist jedenfalls 194kB groß, der letzte Offset ist bei 69kB, configareastrings Offset bei 192kB. Was soll den statt dem ".align 16" hin? Ist "2**16" gleich "2^16"?
    Code:
    $l ./kernel/ref-vr9-7490_06.60/linux-3.10/arch/mips/kernel/avm_kernel_config_area.o
    -rw-r--r-- 1 198696  7. Okt 07:54 ./kernel/ref-vr9-7490_06.60/linux-3.10/arch/mips/kernel/avm_kernel_config_area.o
    
    
    $ objdump -x ./kernel/ref-vr9-7490_06.60/linux-3.10/arch/mips/kernel/avm_kernel_config_area.o
    
    ./kernel/ref-vr9-7490_06.60/linux-3.10/arch/mips/kernel/avm_kernel_config_area.o:     file format elf32-big
    ./kernel/ref-vr9-7490_06.60/linux-3.10/arch/mips/kernel/avm_kernel_config_area.o
    architecture: UNKNOWN!, flags 0x00000011:
    HAS_RELOC, HAS_SYMS
    start address 0x00000000
    
    Sections:
    Idx Name          Size      VMA       LMA       File off  Algn
      0 .text         00000000  00000000  00000000  00000040  2**4
                      CONTENTS, ALLOC, LOAD, READONLY, CODE
      1 .data         00000000  00000000  00000000  00000040  2**4
                      CONTENTS, ALLOC, LOAD, DATA
      2 .bss          00000000  00000000  00000000  00000040  2**4
                      ALLOC
      3 .reginfo      00000018  00000000  00000000  00000040  2**2
                      CONTENTS, ALLOC, LOAD, READONLY, DATA
      4 .pdr          00000000  00000000  00000000  00000058  2**2
                      CONTENTS, READONLY
      5 configarea    00020000  00000000  00000000  00010000  2**16
                      CONTENTS, ALLOC, LOAD, RELOC, READONLY, DATA
      6 configareastrings 00000320  00000000  00000000  00030000  2**2
                      CONTENTS, ALLOC, LOAD, READONLY, DATA
    SYMBOL TABLE:
    00000000 l    d  .text  00000000 .text
    00000000 l    d  .data  00000000 .data
    00000000 l    d  .bss   00000000 .bss
    00000000 l    d  configarea     00000000 configarea
    00000000 l    d  configareastrings      00000000 configareastrings
    00000000 l    d  .reginfo       00000000 .reginfo
    00000000 l    d  .pdr   00000000 .pdr
    
    
    RELOCATION RECORDS FOR [configarea]:
    OFFSET   TYPE              VALUE
    00000000 UNKNOWN           configarea
    00000014 UNKNOWN           configarea
    0000001c UNKNOWN           configarea
    00000024 UNKNOWN           configarea
    000114f8 UNKNOWN           configareastrings
    00011500 UNKNOWN           configareastrings
    00011508 UNKNOWN           configareastrings
    00011510 UNKNOWN           configareastrings
    00011518 UNKNOWN           configareastrings
    00011520 UNKNOWN           configareastrings
    00011528 UNKNOWN           configareastrings
    00011530 UNKNOWN           configareastrings
    00011538 UNKNOWN           configareastrings
    00011540 UNKNOWN           configareastrings
    00011548 UNKNOWN           configareastrings
    00011550 UNKNOWN           configareastrings
    00011558 UNKNOWN           configareastrings
    00011560 UNKNOWN           configareastrings
    00011568 UNKNOWN           configareastrings
    00011570 UNKNOWN           configareastrings
    00011578 UNKNOWN           configareastrings
    00011580 UNKNOWN           configareastrings
    00011588 UNKNOWN           configareastrings
    00011590 UNKNOWN           configareastrings
    00011598 UNKNOWN           configareastrings
    000115a0 UNKNOWN           configareastrings
    000115a8 UNKNOWN           configareastrings
    000115b0 UNKNOWN           configareastrings
    000115b8 UNKNOWN           configareastrings
    000115c0 UNKNOWN           configareastrings
    000115c8 UNKNOWN           configareastrings
    000115d0 UNKNOWN           configareastrings
    000115d8 UNKNOWN           configareastrings
    000115e0 UNKNOWN           configareastrings
    000115e8 UNKNOWN           configareastrings
    000115f0 UNKNOWN           configareastrings
    000115f8 UNKNOWN           configareastrings
    00011600 UNKNOWN           configareastrings
    00011608 UNKNOWN           configareastrings
    00011610 UNKNOWN           configareastrings
    00011618 UNKNOWN           configareastrings
    00011620 UNKNOWN           configareastrings
    00011628 UNKNOWN           configareastrings
    00011630 UNKNOWN           configareastrings
    00011638 UNKNOWN           configareastrings
    00011640 UNKNOWN           configareastrings
    00011648 UNKNOWN           configareastrings
    00011650 UNKNOWN           configareastrings
    00011658 UNKNOWN           configareastrings
    00011660 UNKNOWN           configareastrings
    00011668 UNKNOWN           configareastrings
    00011670 UNKNOWN           configareastrings
    00011678 UNKNOWN           configareastrings
    00011680 UNKNOWN           configareastrings
    00011688 UNKNOWN           configareastrings
    00011690 UNKNOWN           configareastrings
    00011698 UNKNOWN           configareastrings
    000116a0 UNKNOWN           configareastrings
    000116a8 UNKNOWN           configareastrings
    000116b0 UNKNOWN           configareastrings
    000116b8 UNKNOWN           configareastrings
    000116c0 UNKNOWN           configareastrings
    000116c8 UNKNOWN           configareastrings
    000116d0 UNKNOWN           configareastrings
    000116d8 UNKNOWN           configareastrings
    000116e0 UNKNOWN           configareastrings
    000116e8 UNKNOWN           configareastrings
    000116f0 UNKNOWN           configareastrings
    000116f8 UNKNOWN           configareastrings
    00011700 UNKNOWN           configareastrings
    00011708 UNKNOWN           configareastrings
    00011710 UNKNOWN           configareastrings
    00011718 UNKNOWN           configareastrings
    Das mit AVM und der GPL bleibt so, solange niemand was ernsthaft dagegen unternimmt. Gab hier schon oft Meinungen dazu, nur das ändert halt nichts

    - - - Aktualisiert - - -

    Hab ".align 3" gesetzt, versteh es nicht aber das ergibt
    Code:
    $ objdump -x ./kernel/ref-vr9-7490_06.60/linux-3.10/arch/mips/kernel/avm_kernel_config_area.o
    
    ./kernel/ref-vr9-7490_06.60/linux-3.10/arch/mips/kernel/avm_kernel_config_area.o:     file format elf32-big
    ./kernel/ref-vr9-7490_06.60/linux-3.10/arch/mips/kernel/avm_kernel_config_area.o
    architecture: UNKNOWN!, flags 0x00000011:
    HAS_RELOC, HAS_SYMS
    start address 0x00000000
    
    Sections:
    Idx Name          Size      VMA       LMA       File off  Algn
      0 .text         00000000  00000000  00000000  00000040  2**4
                      CONTENTS, ALLOC, LOAD, READONLY, CODE
      1 .data         00000000  00000000  00000000  00000040  2**4
                      CONTENTS, ALLOC, LOAD, DATA
      2 .bss          00000000  00000000  00000000  00000040  2**4
                      ALLOC
      3 .reginfo      00000018  00000000  00000000  00000040  2**2
                      CONTENTS, ALLOC, LOAD, READONLY, DATA
      4 .pdr          00000000  00000000  00000000  00000058  2**2
                      CONTENTS, READONLY
      5 configarea    00001760  00000000  00000000  00000060  2**4
                      CONTENTS, ALLOC, LOAD, RELOC, READONLY, DATA
      6 configareastrings 00000320  00000000  00000000  000017c0  2**2
                      CONTENTS, ALLOC, LOAD, READONLY, DATA
    SYMBOL TABLE:
    00000000 l    d  .text  00000000 .text
    00000000 l    d  .data  00000000 .data
    00000000 l    d  .bss   00000000 .bss
    00000000 l    d  configarea     00000000 configarea
    00000000 l    d  configareastrings      00000000 configareastrings
    00000000 l    d  .reginfo       00000000 .reginfo
    00000000 l    d  .pdr   00000000 .pdr
    
    
    RELOCATION RECORDS FOR [configarea]:
    OFFSET   TYPE              VALUE
    00000000 UNKNOWN           configarea
    00000014 UNKNOWN           configarea
    0000001c UNKNOWN           configarea
    00000024 UNKNOWN           configarea
    00001528 UNKNOWN           configareastrings
    00001530 UNKNOWN           configareastrings
    00001538 UNKNOWN           configareastrings
    00001540 UNKNOWN           configareastrings
    00001548 UNKNOWN           configareastrings
    00001550 UNKNOWN           configareastrings
    00001558 UNKNOWN           configareastrings
    00001560 UNKNOWN           configareastrings
    00001568 UNKNOWN           configareastrings
    00001570 UNKNOWN           configareastrings
    00001578 UNKNOWN           configareastrings
    00001580 UNKNOWN           configareastrings
    00001588 UNKNOWN           configareastrings
    00001590 UNKNOWN           configareastrings
    00001598 UNKNOWN           configareastrings
    000015a0 UNKNOWN           configareastrings
    000015a8 UNKNOWN           configareastrings
    000015b0 UNKNOWN           configareastrings
    000015b8 UNKNOWN           configareastrings
    000015c0 UNKNOWN           configareastrings
    000015c8 UNKNOWN           configareastrings
    000015d0 UNKNOWN           configareastrings
    000015d8 UNKNOWN           configareastrings
    000015e0 UNKNOWN           configareastrings
    000015e8 UNKNOWN           configareastrings
    000015f0 UNKNOWN           configareastrings
    000015f8 UNKNOWN           configareastrings
    00001600 UNKNOWN           configareastrings
    00001608 UNKNOWN           configareastrings
    00001610 UNKNOWN           configareastrings
    00001618 UNKNOWN           configareastrings
    00001620 UNKNOWN           configareastrings
    00001628 UNKNOWN           configareastrings
    00001630 UNKNOWN           configareastrings
    00001638 UNKNOWN           configareastrings
    00001640 UNKNOWN           configareastrings
    00001648 UNKNOWN           configareastrings
    00001650 UNKNOWN           configareastrings
    00001658 UNKNOWN           configareastrings
    00001660 UNKNOWN           configareastrings
    00001668 UNKNOWN           configareastrings
    00001670 UNKNOWN           configareastrings
    00001678 UNKNOWN           configareastrings
    00001680 UNKNOWN           configareastrings
    00001688 UNKNOWN           configareastrings
    00001690 UNKNOWN           configareastrings
    00001698 UNKNOWN           configareastrings
    000016a0 UNKNOWN           configareastrings
    000016a8 UNKNOWN           configareastrings
    000016b0 UNKNOWN           configareastrings
    000016b8 UNKNOWN           configareastrings
    000016c0 UNKNOWN           configareastrings
    000016c8 UNKNOWN           configareastrings
    000016d0 UNKNOWN           configareastrings
    000016d8 UNKNOWN           configareastrings
    000016e0 UNKNOWN           configareastrings
    000016e8 UNKNOWN           configareastrings
    000016f0 UNKNOWN           configareastrings
    000016f8 UNKNOWN           configareastrings
    00001700 UNKNOWN           configareastrings
    00001708 UNKNOWN           configareastrings
    00001710 UNKNOWN           configareastrings
    00001718 UNKNOWN           configareastrings
    00001720 UNKNOWN           configareastrings
    00001728 UNKNOWN           configareastrings
    00001730 UNKNOWN           configareastrings
    00001738 UNKNOWN           configareastrings
    00001740 UNKNOWN           configareastrings
    00001748 UNKNOWN           configareastrings
    GCC hat mal was ander der ABI geändert was einigen nicht passte

  5. #5
    IPPF Achttausend-VIP Avatar von PeterPawn
    Registriert seit
    10.05.2006
    Ort
    Berlin
    Beiträge
    8.179
    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.

  6. #6
    IPPF-Fan
    Registriert seit
    27.05.2010
    Beiträge
    170
    Die .o Datei ist jetzt um die 8kB gross Leider bootet der Kernel nicht, wird aber wohl an der .config liegen. Die Wlan-LED flackert nur sehr schnell, das kann der AVM-Treiber so nicht ^^ Hab jetzt aber keine Zeit mehr zum testen.
    Ich denk man baut das am best in Freetz ein, indem man 1 Patch nach make/linux/patches/3.10.73/7490_06.60/ packt (nicht als 4 Dateien). Tools zum generieren/auslesen eben nach tools/. Bei neuer Firmware-Version muss man eh immer einges für replace kernel anpassen, hieran ändert sich evtl auch wieder was. Außderm muss man ja auch immer wieder .config-raten spielen, die AVM ja auch nicht herausrückt trotz GPL...

  7. #7
    IPPF Achttausend-VIP Avatar von PeterPawn
    Registriert seit
    10.05.2006
    Ort
    Berlin
    Beiträge
    8.179
    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.

  8. #8
    IPPF-Fan
    Registriert seit
    27.05.2010
    Beiträge
    170
    Der einfachste uns sicherste Weg zu schauen ob ein selbstgebauter Kernel läuft ist "uname -a". Wenn vom 20.6. hats nicht geklappt... Hatte auch den Fall dass der Kernel nicht im RAM geladen werden konnte, und deshlab ger nciht erst geflasht wurde.
    Kannst kurz umschalten und schauen von wann dein Kernel ist?
    Ich versuchs mals mit deiner .config, bzw schaue nach den Unterschieden.

    - - - Aktualisiert - - -

    Wo ist denn eine .config für den kernel? linux-7490-06.60.tar.xz ist nur umgepacktes Archiv von AVM. Die Datei sollte unter ./make/linux/configs/freetz/config-vr9-7490_06.60 liegen

  9. #9
    IPPF Achttausend-VIP Avatar von PeterPawn
    Registriert seit
    10.05.2006
    Ort
    Berlin
    Beiträge
    8.179
    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).

  10. #10
    IPPF-Fan
    Registriert seit
    27.05.2010
    Beiträge
    170
    Keine grossen Unterschiede in der .config
    Code:
    --- my  2016-10-07 20:15:50.716847937 +0200
    +++ pp   2016-10-07 20:14:43.737000239 +0200
    -CONFIG_EXPORTFS=m
    -CONFIG_NETWORK_FILESYSTEMS=y
    -CONFIG_NFS_FS=m
    -CONFIG_NFS_V2=m
    -CONFIG_NFS_V3=m
    -CONFIG_NFSD=m
    -CONFIG_NFSD_V3=y
    -CONFIG_LOCKD=m
    -CONFIG_LOCKD_V4=y
    -CONFIG_NFS_COMMON=y
    -CONFIG_SUNRPC=m
    -CONFIG_CIFS=m
    -CONFIG_CIFS_STATS=y
    -CONFIG_CODA_FS=m
    -CONFIG_CRYPTO_AEAD2=y
    -CONFIG_CRYPTO_BLKCIPHER=m
    -CONFIG_CRYPTO_BLKCIPHER2=y
    -CONFIG_CRYPTO_RNG2=y
    -CONFIG_CRYPTO_PCOMP2=y
    -CONFIG_CRYPTO_MANAGER=m
    -CONFIG_CRYPTO_MANAGER2=y
    -CONFIG_CRYPTO_MANAGER_DISABLE_TESTS=y
    -CONFIG_CRYPTO_WORKQUEUE=y
    -CONFIG_CRYPTO_ECB=m
    -CONFIG_CRYPTO_HMAC=m
    -CONFIG_CRYPTO_MD4=m
    -CONFIG_CRYPTO_MD5=m
    -CONFIG_CRYPTO_SHA256=m
    -CONFIG_CRYPTO_ARC4=m
    -CONFIG_CRYPTO_DES=m
    Das wird wohl nicht das Problem sein. Hast du bei deiner 7490 Wlan aktiv? Ich hab mit Gast-Wlan und somit wird es beim booten gestartet.
    Wie gesagt flackerte die Wlan-LED sehr schnell bei mir

  11. #11
    IPPF Achttausend-VIP Avatar von PeterPawn
    Registriert seit
    10.05.2006
    Ort
    Berlin
    Beiträge
    8.179
    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.

  12. #12
    IPPF-Fan
    Registriert seit
    27.05.2010
    Beiträge
    170
    Also LED Treiber schien zu gehen.
    Aber der Reihe nach: Flashen per adam ging nicht, da fehlt wohl noch was im Kernel? Nur Kernel per adam laden ging auch nicht..
    Flashen mit Freetz-Webif dagegen schon, es blieb dann aber nur die power-LED durchgehend an. Info-LED zeigt Internetverbindung an und blieb aus. Wlan hatte ich ausgeschaltet.
    Box war nicht per IP erreichbar, ist als IP-Client konfiguriert.
    Nach zurückwechseln hab ich nichts im panic oder crash log gefunden (leer)
    Da ich mal alle 3 Konsolen bestückt hab, müsste ich die Box bei Gelegenheit mal aus dem Keller holen und mir die serielle Konsole anschauen ^^ Glaube das ist der beste Weg

  13. #13
    IPPF Achttausend-VIP Avatar von PeterPawn
    Registriert seit
    10.05.2006
    Ort
    Berlin
    Beiträge
    8.179
    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 ...

  14. #14
    IPPF-Fan
    Registriert seit
    01.09.2016
    Beiträge
    156
    Zitat Zitat von PeterPawn Beitrag anzeigen
    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???
    Geändert von noob_noob (08.10.2016 um 15:01 Uhr)
    7490, ftth 300mbit syncron auf lan1, 6.80. <-> 5ghz only, 7490, repeater, 2.4 & 5 ghz wlan, 6.80. dualband frequenzband wechsel: disable.
    6490 bastelkiste mit 6.24 <-> 6.63 mit https://bitbucket.org/fesc2000/ffritz
    https://nordheide.freifunk.net/wiki/Hauptseite seit 2006

  15. #15
    IPPF Achttausend-VIP Avatar von PeterPawn
    Registriert seit
    10.05.2006
    Ort
    Berlin
    Beiträge
    8.179
    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.

  16. #16
    IPPF-Fan
    Registriert seit
    01.09.2016
    Beiträge
    156
    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
    Geändert von noob_noob (08.10.2016 um 16:20 Uhr)
    7490, ftth 300mbit syncron auf lan1, 6.80. <-> 5ghz only, 7490, repeater, 2.4 & 5 ghz wlan, 6.80. dualband frequenzband wechsel: disable.
    6490 bastelkiste mit 6.24 <-> 6.63 mit https://bitbucket.org/fesc2000/ffritz
    https://nordheide.freifunk.net/wiki/Hauptseite seit 2006

  17. #17
    IPPF Achttausend-VIP Avatar von PeterPawn
    Registriert seit
    10.05.2006
    Ort
    Berlin
    Beiträge
    8.179
    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ß.

  18. #18
    IPPF-Fan
    Registriert seit
    01.09.2016
    Beiträge
    156
    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
    7490, ftth 300mbit syncron auf lan1, 6.80. <-> 5ghz only, 7490, repeater, 2.4 & 5 ghz wlan, 6.80. dualband frequenzband wechsel: disable.
    6490 bastelkiste mit 6.24 <-> 6.63 mit https://bitbucket.org/fesc2000/ffritz
    https://nordheide.freifunk.net/wiki/Hauptseite seit 2006

  19. #19
    IPPF-Fan
    Registriert seit
    27.05.2010
    Beiträge
    170
    Konsole ist schon besser mit eigenem Kernel, damit sieht man auch andere Fehler die evtl ein booten verhindern. Ich hatte bislang immer selbstgemauten Kernel seit 7170
    Die Probleme sind normal Dinge die noch aktivert werden müssen, obwohl sie in der "offiziellen" .config nicht sind

    Zitat Zitat von PeterPawn Beitrag anzeigen
    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.
    .. konnte

    - - - Aktualisiert - - -

    Zitat Zitat von PeterPawn Beitrag anzeigen
    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.
    Nicht immer! Für NFS Support als modul muss der Kernel vorher schon konfiguriert sein

  20. #20
    IPPF Achttausend-VIP Avatar von PeterPawn
    Registriert seit
    10.05.2006
    Ort
    Berlin
    Beiträge
    8.179
    Zitat Zitat von opto Beitrag anzeigen
    Nicht immer! Für NFS Support als modul muss der Kernel vorher schon konfiguriert sein
    Habe ich doch genauso auch geschrieben am Nachmittag?

Seite 1 von 4 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
  •