Seite 2 von 4 ErsteErste 1234 LetzteLetzte
Ergebnis 21 bis 40 von 65

Thema: Fehlende Bestandteile im OpenSource-Paket von AVM

  1. #21
    IPPF-Fan
    Registriert seit
    26.05.2010
    Beiträge
    164
    Zitat Zitat von PeterPawn Beitrag anzeigen
    Habe ich doch genauso auch geschrieben
    Mkay...

    Hier log nach flashen mit adam2 eines replace-kernels:

    Code:
    [/]
    
    (AVM) EVA Revision: 1.1777 Version: 2777
    (C) Copyright 2005 AVM Date: Jun 21 2013 Time: 15:00:26 (1) 3 0x0-0x740D
    
    [FLASH:] MACRONIX Uniform-Flash 1MB 256 Bytes WriteBuffer
    [FLASH:](Eraseregion [0] 16 sectors a 64kB)
    [NAND:] 512MB MICRON 2048 Pagesize 128k Blocksize 4096 Blocks 8Bit 1 CS HW
    [SYSTEM:] VR9 on 500MHz/250MHz/250MHz
    
    .Atheros 8030/35 detected
    
    Eva_AVM >
    
    
    
    
    
    
    
    
    <REJECTED 0x8C5B5020>
    <REJECTED 0x8C5B55C0>
    <REJECTED 0x8C5B5B60>
    <REJECTED 0x8C5B6100>
    <REJECTED 0x8C5B66A0>
    <REJECTED 0x8C5B6C40>
    <REJECTED 0x8C5B71E0>
    <REJECTED 0x8C5B7780>
    <REJECTED 0x8C5B7D20>
    <REJECTED 0x8C5B82C0>
    <REJECTED 0x8C5B8860>
    <REJECTED 0x8C5B8E00>
    <REJECTED 0x8C5B93A0>
    <REJECTED 0x8C5B9940>
    <REJECTED 0x8C5B9EE0>
    <REJECTED 0x8C5BA480>
    <REJECTED 0x8C5BAA20>
    <REJECTED 0x8C5BAFC0>
    <REJECTED 0x8C5BB560>
    <REJECTED 0x8CD11080>
    <REJECTED 0x8CD11620>
    <REJECTED 0x8CD11BC0>
    <REJECTED 0x8CD12160>
    <REJECTED 0x8CD12700>
    <REJECTED 0x8CD12CA0>
    <REJECTED 0x8CD13240>
    <REJECTED 0x8CD137E0>
    <REJECTED 0x8CD13D80>
    <REJECTED 0x8CD14320>
    <REJECTED 0x8CD148C0>
    <REJECTED 0x8CD14E60>
    <REJECTED 0x8CD15400>
    <REJECTED 0x8CD159A0>
    <REJECTED 0x8CD15F40>
    <REJECTED 0x8CD164E0>
    <REJECTED 0x8CD16A80>
    <REJECTED 0x8CD17020>
    <REJECTED 0x8CD175C0>
    <REJECTED 0x8D280DE0>
    <REJECTED 0x8D281380>
    <REJECTED 0x8D281920>
    <REJECTED 0x8D281EC0>
    <REJECTED 0x8D282460>
    <REJECTED 0x8D282A00>
    <REJECTED 0x8D282FA0>
    <REJECTED 0x8D283540>
    <REJECTED 0x8D283AE0>
    <REJECTED 0x8D284080>
    <REJECTED 0x8D284620>
    <REJECTED 0x8D284BC0>
    <REJECTED 0x8D285160>
    <REJECTED 0x8D285700>
    <REJECTED 0x8D285CA0>
    <REJECTED 0x8D286240>
    <REJECTED 0x8D2867E0>
    <REJECTED 0x8D286D80>
    <REJECTED 0x8D287320>
    <REJECTED 0x8D628060>
    <REJECTED 0x8D628600>
    <REJECTED 0x8D628BA0>
    <REJECTED 0x8D629140>
    <REJECTED 0x8D6296E0>
    <REJECTED 0x8D629C80>
    <REJECTED 0x8D62A220>
    <REJECTED 0x8D62A7C0>
    <REJECTED 0x8D62AD60>
    <REJECTED 0x8D62B300>
    <REJECTED 0x8D62B8A0>
    <REJECTED 0x8D62BE40>
    <REJECTED 0x8D62C3E0>
    <REJECTED 0x8D62C980>
    <REJECTED 0x8D62CF20>
    <REJECTED 0x8D62D4C0>
    <REJECTED 0x8D62DA60>
    <REJECTED 0x8D62E000>
    <REJECTED 0x8D62E5A0>
    <REJECTED 0x8D974200>
    <REJECTED 0x8D9747A0>
    <REJECTED 0x8D974D40>
    <REJECTED 0x8D9752E0>
    <REJECTED 0x8D975880>
    <REJECTED 0x8D975E20>
    <REJECTED 0x8D9763C0>
    <REJECTED 0x8D976960>
    <REJECTED 0x8D976F00>
    <REJECTED 0x8D9774A0>
    <REJECTED 0x8D977A40>
    <REJECTED 0x8D977FE0>
    <REJECTED 0x8D978580>
    <REJECTED 0x8D978B20>
    <REJECTED 0x8D9790C0>
    <REJECTED 0x8D979660>
    <REJECTED 0x8D979C00>
    <REJECTED 0x8D97A1A0>
    <REJECTED 0x8D97A740>
    ................................................................
    
    Lantiq xDSL CPE VR9
    phym = 0d000000, mem = 0d000000, max_pfn = 0000d000
    Reserving memory for CP1 @0xad000000, size 0x00000000
    plat_device_tree_setup: AVM hardware subrevision 1
    plat_device_tree_setup: Missing device-tree for AVM hardware subrevision 1
    
    CAUSE    = 0x50008000  interrupt
    STATUS   = 0x1100FF03      EPC      = 0x8004B5C4
    BADVADDR = 0x7731F820      ERROREPC = 0x80017580
    
    $ 0(zr):0x00000000  $ 8(t0):0x8088B5B0  $16(s0):0x00000014  $24(t8):0x00000003
    $ 1(at):0x18102000  $ 9(t1):0x8088B780  $17(s1):0x0E707688  $25(t9):0x00000000
    $ 2(v0):0xFFFFFFFF  $10(t2):0x00000000  $18(s2):0x0E707750  $26(k0):0x00000000
    $ 3(v1):0x00000000  $11(t3):0x00000006  $19(s3):0x00000000  $27(k1):0x00000000
    $ 4(a0):0x000003E8  $12(t4):0x00000000  $20(s4):0x80890000  $28(gp):0x80714000
    $ 5(a1):0x00000000  $13(t5):0x00000006  $21(s5):0x80730000  $29(sp):0x80717DF8
    $ 6(a2):0x00000000  $14(t6):0x00000006  $22(s6):0x000003E8  $30(s8):0x00000000
    $ 7(a3):0x00000002  $15(t7):0x00000000  $23(s7):0x00000000  $31(ra):0x8004B5CC
    [/]
    
    (AVM) EVA Revision: 1.1777 Version: 2777
    (C) Copyright 2005 AVM Date: Jun 21 2013 Time: 15:00:26 (1) 3 0x0-0x740D
    
    [FLASH:] MACRONIX Uniform-Flash 1MB 256 Bytes WriteBuffer
    [FLASH:](Eraseregion [0] 16 sectors a 64kB)
    [NAND:] 512MB MICRON 2048 Pagesize 128k Blocksize 4096 Blocks 8Bit 1 CS HW
    [SYSTEM:] VR9 on 500MHz/250MHz/250MHz
    
    .Atheros 8030/35 detected
    
    Eva_AVM >##............................................................
    Lantiq xDSL CPE VR9
    ifx_dplus_clean error: IFX_REG_R32(DMRX_PGCNT) = 0x01300013, IFX_REG_R32(DMRX_PKTCNT) = 0x0000000a, IFX_REG_R32(DSRX_PGCNT) = 0x00000013
    phym = 10000000, mem = 10000000, max_pfn = 00010000
    Reserving memory for CP1 @0xb0000000, size 0x00000000
    plat_device_tree_setup: AVM hardware subrevision 1
    plat_device_tree_setup: using Fallback device-tree of AVM hardware subrevision 0
    Scheinbar geht der Fallback nicht

    "Missing device-tree for AVM hardware subrevision 1"
    sollte so ein
    "using Fallback device-tree of AVM hardware subrevision 0"

  2. #22
    IPPF Siebentausend-VIP Avatar von PeterPawn
    Registriert seit
    10.05.2006
    Ort
    Berlin
    Beiträge
    7.937
    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
    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         }
    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...l_config.patch), dann stellt sich die Frage, ob Du ggf. vergessen haben könntest, diesen Patch zu deaktivieren.

  3. #23
    IPPF-Fan
    Registriert seit
    26.05.2010
    Beiträge
    164
    Zitat Zitat von PeterPawn Beitrag anzeigen
    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...l_config.patch), dann stellt sich die Frage, ob Du ggf. vergessen haben könntest, diesen Patch zu deaktivieren.
    Ja, ist noch auskommentiert °_° Ohne den Patch läuft der Kernel! NFS will noch nicht, aber das dürft an der .config liegen

    - - - Aktualisiert - - -

    Hab mal die Annex Dateien mit ins Image genommen, aber auf der Konsole keine Fehler beim laden gesehen. Müsste funktionieren


    - - - Aktualisiert - - -

    NFS Server läuft (hab nfs-utils geupdated, kA ob nötig). NFS-Client nicht als Modul, Fehler "unsupported Protocol". Fest im Kernel geht, allerdings kommt ein "nfs: exports duplicate symbol alloc_nfs_open_context (owned by kernel)". CIFS geht nicht, braucht ich aber nicht unebdingt und belass es dabei. DAV2FS geht auch. Sieht soweit also schonmal ganz gut aus. Danke für die Hilfe @PeterPawn!
    Geändert von opto (09.10.2016 um 03:59 Uhr)

  4. #24
    IPPF Siebentausend-VIP Avatar von PeterPawn
    Registriert seit
    10.05.2006
    Ort
    Berlin
    Beiträge
    7.937
    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.

  5. #25
    IPPF-Fan
    Registriert seit
    26.05.2010
    Beiträge
    164
    Naja, es müssten dann auch andere Sachen automatisiert werden, wie zB die Version in 110-hwrev_list.patch. Von daher - mir reicht's so

    UPDATE: Was mir bislang auffiel was mit der 6.60 und Kernel 3 nicht geht:
    - freetzmount muss noch angepasst werden
    - cryptosetup, Module
    - iptables, Compilierfehler
    Ansonsten ist die 7490 damit mittlerweile ein schneller Ersatz für die 7390, punktlich zum Markstart der 7580 °-°
    Geändert von opto (20.10.2016 um 18:00 Uhr)

  6. #26
    IPPF Fünfhunderter
    Registriert seit
    20.12.2005
    Beiträge
    872
    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

  7. #27
    IPPF Siebentausend-VIP Avatar von PeterPawn
    Registriert seit
    10.05.2006
    Ort
    Berlin
    Beiträge
    7.937
    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 = .;
    -		. += 64 * 1024;
    +		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.

  8. #28
    IPPF Fünfhunderter
    Registriert seit
    20.12.2005
    Beiträge
    872
    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

  9. #29
    IPPF Fünfhunderter
    Registriert seit
    20.12.2005
    Beiträge
    872
    Hallo Peter,

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

  10. #30
    IPPF Siebentausend-VIP Avatar von PeterPawn
    Registriert seit
    10.05.2006
    Ort
    Berlin
    Beiträge
    7.937
    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.

  11. #31
    IPPF-Fan
    Registriert seit
    26.11.2005
    Ort
    Österreich
    Beiträge
    366
    Hallo,
    mich bringt http://freetz.org/ticket/2774#comment:164 hierher.

    Code:
    user@zx:~/freetz-trunk$ make
    make -j2 -f Makefile.freetz -C /home/user/freetz-trunk/source/host-tools/dtc-v1.4.2/libfdt \
            CC="gcc"
    make[1]: Entering directory '/home/user/freetz-trunk/source/host-tools/dtc-v1.4.2/libfdt'
    gcc -O2 -m32 -std=c99 -I. -D_GNU_SOURCE  -c -o fdt.o fdt.c
    gcc -O2 -m32 -std=c99 -I. -D_GNU_SOURCE  -c -o fdt_ro.o fdt_ro.c
    In file included from /usr/include/stdint.h:25:0,
                     from /usr/lib/gcc/x86_64-linux-gnu/4.9/include/stdint.h:9,
                     from libfdt_env.h:56,
                     from fdt_ro.c:51:
    /usr/include/features.h:374:25: fatal error: sys/cdefs.h: Datei oder Verzeichnis nicht gefunden
     #  include <sys/cdefs.h>
                             ^
    compilation terminated.
    In file included from /usr/include/stdint.h:25:0,
                     from /usr/lib/gcc/x86_64-linux-gnu/4.9/include/stdint.h:9,
                     from libfdt_env.h:56,
                     from fdt.c:51:
    /usr/include/features.h:374:25: fatal error: sys/cdefs.h: Datei oder Verzeichnis nicht gefunden
     #  include <sys/cdefs.h>
                             ^
    compilation terminated.
    <builtin>: recipe for target 'fdt_ro.o' failed
    make[1]: *** [fdt_ro.o] Error 1
    make[1]: *** Warte auf noch nicht beendete Prozesse...
    <builtin>: recipe for target 'fdt.o' failed
    make[1]: *** [fdt.o] Error 1
    make[1]: Leaving directory '/home/user/freetz-trunk/source/host-tools/dtc-v1.4.2/libfdt'
    tools/make/dtc-host/dtc-host.mk:21: recipe for target '/home/user/freetz-trunk/source/host-tools/dtc-v1.4.2/libfdt/libfdt.a' failed
    make: *** [/home/user/freetz-trunk/source/host-tools/dtc-v1.4.2/libfdt/libfdt.a] Error 2
    trunk ist frisch ausgecheckt. Fehlt mir was auf meiner Build-Umgebung (Debian 8.7 64bit)?
    Geändert von berndy2001 (10.02.2017 um 22:43 Uhr)
    Connected by UPC (75/7,5)
    FRITZ!Box Fon WLAN 7490
    Cisco SPA525G (SIP)

  12. #32
    IPPF Fünfhunderter
    Registriert seit
    20.12.2005
    Beiträge
    872
    Zitat Zitat von berndy2001 Beitrag anzeigen
    Fehlt mir was auf meiner Build-Umgebung (Debian 8.7 64bit)?
    s. hier (ab "# Auf 64-Bit Systemen sind zusätzlich folgende Pakete zu installieren")

  13. #33
    IPPF-Fan
    Registriert seit
    26.11.2005
    Ort
    Österreich
    Beiträge
    366
    Danke. Ich war der Meinung diese Pakte hätte eh installiert.
    Connected by UPC (75/7,5)
    FRITZ!Box Fon WLAN 7490
    Cisco SPA525G (SIP)

  14. #34
    IPPF Fünfhunderter
    Registriert seit
    20.12.2005
    Beiträge
    872
    Hallo Peter,

    hast Du Dich zufälligerweise schon mit dem Thema "avm_kernel_config_area" im Zusammenhang mit den GRX5-Boxen (7560, 7580) auseinander gesetzt? kernel.image ist bei diesen nicht mehr lzma1 komprimiert, sondern irgendwie anders (xz?). Könntest Du bitte bei Gelegenheit {extract,gen}_avm_kernel_config anpassen? avm_kernel_config_area ist bei diesen Boxen laut verfügbaren kernel-sourcen 96KB groß.

    Danke!

    VG, Gene

  15. #35
    IPPF Siebentausend-VIP Avatar von PeterPawn
    Registriert seit
    10.05.2006
    Ort
    Berlin
    Beiträge
    7.937
    @er13:
    Nein, habe ich noch nicht (intensiv) gemacht. Ich habe seit letztem Donnerstag eine 7580 hier und passe erst einmal mein "modfs" an die geänderte Dateisystem-Struktur an.

    Nach allem, was ich bisher gesehen habe, kommt bei der 7580 aber der (OF-)FDT-Blob ohnehin aus dem Bootloader ... dieser stellt seinerseits sicher, daß an der Stelle, wo ansonsten HWSubRevision 0 liegen würde, die korrekten Daten für die aktuelle Box liegen und das ganze "Ablaufen" auf der Suche nach der passenden HWSubRevision bzw. der nächstkleineren, fällt bei GRX500 einfach aus - "subrev" wird stur auf "0" gesetzt in "arch/mips/kernel/setup.c".

    Ich habe bisher noch keine Ahnung, was AVM da nun überhaupt im Konfigurationsbereich unterbringt ... der FDT ist es jedenfalls schon mal nicht. Nach allem, was man ansonsten in "init/avm_kernel_config.c" sehen kann, werden da auch keine zusätzlichen Typen von Einträgen verwendet ... zumindest enden alle neuen Typen am Ende in einem "pr_err()"-Aufruf, der sie als "unhandled" brandmarkt. Bleiben also noch die Versionsinformationen und die Module-Tabelle.

    Allerdings habe ich noch nicht in den Speicher zwischen diesen beiden Symbolen (start und end) geschaut ... es ist nur bereits jetzt klar, daß der Code zur Suche nach dem FDT, mit dem der Konfigurationsbereich im VR9-Kernel ja lokalisiert wird, hier mit einiger Wahrscheinlichkeit nicht funktionieren wird, solange AVM dort nicht (sicherheitshalber) noch eine zusätzliche FDT-Struktur ablegt.

    Das Erhöhen des Zählers für die möglichen "HWSubRevisionen" auf 256 könnte eine der Ursachen sein, warum das nun 96 KB sein sollen ... wobei ich eigentlich der Meinung bin, daß der Code für den GRX500 historisch sogar älter sein müßte, als der für den VR9 - auch der ältere Kernel spricht m.E. dafür.

    Wobei im Moment ja für die 7580 die Quellen nicht zur aktuell veröffentlichten Firmware passen ... die Firmware ist die 06.81 vom 25.01.2017 und das Opensource-Paket ist (Stand heute) immer noch das für die 06.53 aus dem Oktober 2016. Mal sehen, wann da die aktuelle Version kommt ... 6 Wochen sind schon mal rum (wobei die 06.80 aus dem Dez. 2016 hier gar nicht betrachtet wird).

    Gepackt sollte der Kernel mit "gzip" sein ... aber ich finde schon den Header nicht (falls AVM die Standardroutinen zum Entpacken benutzt (lib/decompress_inflate.c), müßte der Payload mit 0x1F8B08 starten) und auch das doppelte TI-Magic am Ende des Kernel-Files (ich hatte die 06.53 untersucht) läßt mich etwas skeptisch zurück, ob da alles mit rechten Dingen zugeht.

  16. #36
    IPPF Fünfhunderter
    Registriert seit
    20.12.2005
    Beiträge
    872
    @Peter: Ok, alles klar. Danke für die Antwort! Diese Woche ist bei mir recht voll, komme wahrscheinlich erst nächste Woche dazu, mich mit dem Thema weiter zu beschäftigen.

  17. #37
    IPPF Siebentausend-VIP Avatar von PeterPawn
    Registriert seit
    10.05.2006
    Ort
    Berlin
    Beiträge
    7.937

    Kernel-Konfiguration FRITZ!Box 7580

    In der 7580 ist der Kernel ja mit der Option "CONFIG_IKCONFIG=y" und "CONFIG_IKCONFIG_PROC=y" übersetzt (153.06.54) ... infolgedessen steht die tatsächlich verwendete Konfiguration als "config.gz" unterhalb von "/proc" zum Auslesen bereit - siehe Anhang.

    Vergleicht man das mit dem, was AVM im OpenSource-Paket für dieselbe Version "beilegt", ergeben sich bereits dort so gravierende Unterschiede, daß man schon fast von (bewußter?) Sabotage am OpenSource-Gedanken ausgehen muß:
    Code:
    @@ -181,7 +181,7 @@
     CONFIG_ARCH_DISCARD_MEMBLOCK=y
     # CONFIG_HAVE_BOOTMEM_INFO_NODE is not set
     CONFIG_PAGEFLAGS_EXTENDED=y
    -CONFIG_SPLIT_PTLOCK_CPUS=999999
    +CONFIG_SPLIT_PTLOCK_CPUS=4
     CONFIG_COMPACTION=y
     CONFIG_MIGRATION=y
     # CONFIG_PHYS_ADDR_T_64BIT is not set
    @@ -430,7 +430,11 @@
     # CONFIG_DEFAULT_CFQ is not set
     # CONFIG_DEFAULT_NOOP is not set
     CONFIG_DEFAULT_IOSCHED="deadline"
    -CONFIG_UNINLINE_SPIN_UNLOCK=y
    +CONFIG_INLINE_SPIN_UNLOCK_IRQ=y
    +CONFIG_INLINE_READ_UNLOCK=y
    +CONFIG_INLINE_READ_UNLOCK_IRQ=y
    +CONFIG_INLINE_WRITE_UNLOCK=y
    +CONFIG_INLINE_WRITE_UNLOCK_IRQ=y
     CONFIG_MUTEX_SPIN_ON_OWNER=y
     CONFIG_LTQ_LIST_PREFETCH=y
     CONFIG_AVM_KERNEL=y
    @@ -512,7 +516,8 @@
     # CONFIG_LTQ_CPUFREQ_DEBUG is not set
     CONFIG_LTQ_CPU_FREQ=y
     CONFIG_LTQ_CPUFREQ_DVS=y
    -# CONFIG_AVM_IPI_YIELD is not set
    +CONFIG_AVM_IPI_YIELD=y
    +CONFIG_AVM_IPI_YIELD_DEBUG=y
     CONFIG_NET=y
     CONFIG_ETHERNET_PACKET_MANGLE=y
     # CONFIG_NET_DEV_LOAD is not set
    @@ -539,7 +544,7 @@
     CONFIG_XFRM_IPCOMP=y
     CONFIG_NET_KEY=y
     # CONFIG_NET_KEY_MIGRATE is not set
    -CONFIG_LANTIQ_MCAST_HELPER=n
    +CONFIG_LANTIQ_MCAST_HELPER=m
     CONFIG_LANTIQ_MCAST_HELPER_ACL=y
     # CONFIG_LTQ_STAT_HELPER is not set
     CONFIG_AVM_RECV_HOOKS=y
    @@ -612,15 +617,15 @@
     # CONFIG_INET6_IPCOMP is not set
     # CONFIG_IPV6_MIP6 is not set
     # CONFIG_INET6_XFRM_TUNNEL is not set
    -CONFIG_INET6_TUNNEL=n
    +CONFIG_INET6_TUNNEL=m
     # CONFIG_INET6_XFRM_MODE_TRANSPORT is not set
     # CONFIG_INET6_XFRM_MODE_TUNNEL is not set
     # CONFIG_INET6_XFRM_MODE_BEET is not set
     # CONFIG_INET6_XFRM_MODE_ROUTEOPTIMIZATION is not set
    -CONFIG_IPV6_SIT=n
    +CONFIG_IPV6_SIT=m
     CONFIG_IPV6_SIT_6RD=y
     CONFIG_IPV6_NDISC_NODETYPE=y
    -CONFIG_IPV6_TUNNEL=n
    +CONFIG_IPV6_TUNNEL=m
     # CONFIG_IPV6_GRE is not set
     CONFIG_IPV6_MULTIPLE_TABLES=y
     CONFIG_IPV6_SUBTREES=y
    @@ -684,6 +689,7 @@
     CONFIG_L2TP_ETH=y
     CONFIG_STP=y
     CONFIG_BRIDGE=y
    +CONFIG_AVM_BRIDGE_FLOOD_RATELIMITER=y
     CONFIG_BRIDGE_IGMP_SNOOPING=y
     CONFIG_AVM_BRIDGE_MULTICAST_TO_UNICAST=y
     CONFIG_AVM_BRIDGE_MULTICAST_TO_UNICAST_DEFAULT_THRESHOLD=3
    @@ -708,26 +714,26 @@
     #
     CONFIG_NET_SCH_CBQ=y
     CONFIG_NET_SCH_HTB=y
    -CONFIG_NET_SCH_HFSC=n
    +CONFIG_NET_SCH_HFSC=m
     # CONFIG_NET_SCH_ATM is not set
    -CONFIG_NET_SCH_PRIO=n
    +CONFIG_NET_SCH_PRIO=m
     # CONFIG_NET_SCH_MULTIQ is not set
     CONFIG_NET_SCH_RED=y
     # CONFIG_NET_SCH_SFB is not set
    -CONFIG_NET_SCH_SFQ=n
    +CONFIG_NET_SCH_SFQ=m
     # CONFIG_NET_SCH_ESFQ is not set
    -CONFIG_NET_SCH_TEQL=n
    -CONFIG_NET_SCH_TBF=n
    -CONFIG_NET_SCH_GRED=n
    +CONFIG_NET_SCH_TEQL=m
    +CONFIG_NET_SCH_TBF=m
    +CONFIG_NET_SCH_GRED=m
     CONFIG_NET_SCH_DSMARK=y
    -CONFIG_NET_SCH_NETEM=n
    +CONFIG_NET_SCH_NETEM=m
     # CONFIG_NET_SCH_DRR is not set
     # CONFIG_NET_SCH_MQPRIO is not set
     # CONFIG_NET_SCH_CHOKE is not set
     # CONFIG_NET_SCH_QFQ is not set
    -CONFIG_NET_SCH_CODEL=n
    +CONFIG_NET_SCH_CODEL=m
     CONFIG_NET_SCH_LLQ=y
    -CONFIG_NET_SCH_HW=n
    +CONFIG_NET_SCH_HW=m
     CONFIG_NET_SCH_HW_BYPASS=y
     CONFIG_NET_SCH_FQ_CODEL=y
     CONFIG_NET_SCH_INGRESS=y
    @@ -737,29 +743,29 @@
     # Classification
     #
     CONFIG_NET_CLS=y
    -CONFIG_NET_CLS_BASIC=n
    -CONFIG_NET_CLS_TCINDEX=n
    -CONFIG_NET_CLS_ROUTE4=n
    +CONFIG_NET_CLS_BASIC=m
    +CONFIG_NET_CLS_TCINDEX=m
    +CONFIG_NET_CLS_ROUTE4=m
     CONFIG_NET_CLS_FW=y
     CONFIG_NET_CLS_U32=y
     CONFIG_CLS_U32_PERF=y
     # CONFIG_CLS_U32_MARK is not set
     CONFIG_CLS_U32_EXTMARK=y
    -CONFIG_NET_CLS_RSVP=n
    -CONFIG_NET_CLS_RSVP6=n
    -CONFIG_NET_CLS_FLOW=n
    +CONFIG_NET_CLS_RSVP=m
    +CONFIG_NET_CLS_RSVP6=m
    +CONFIG_NET_CLS_FLOW=m
     # CONFIG_NET_CLS_CGROUP is not set
     CONFIG_NET_EMATCH=y
     CONFIG_NET_EMATCH_STACK=32
    -CONFIG_NET_EMATCH_CMP=n
    -CONFIG_NET_EMATCH_NBYTE=n
    -CONFIG_NET_EMATCH_U32=n
    -CONFIG_NET_EMATCH_META=n
    -CONFIG_NET_EMATCH_TEXT=n
    +CONFIG_NET_EMATCH_CMP=m
    +CONFIG_NET_EMATCH_NBYTE=m
    +CONFIG_NET_EMATCH_U32=m
    +CONFIG_NET_EMATCH_META=m
    +CONFIG_NET_EMATCH_TEXT=m
     CONFIG_NET_CLS_ACT=y
     CONFIG_NET_ACT_POLICE=y
     # CONFIG_NET_ACT_GACT is not set
    -CONFIG_NET_ACT_MIRRED=n
    +CONFIG_NET_ACT_MIRRED=m
     # CONFIG_NET_ACT_NAT is not set
     # CONFIG_NET_ACT_PEDIT is not set
     # CONFIG_NET_ACT_SIMP is not set
    @@ -995,7 +1001,7 @@
     # CONFIG_BLK_DEV_COW_COMMON is not set
     CONFIG_BLK_DEV_LOOP=y
     CONFIG_BLK_DEV_LOOP_MIN_COUNT=2
    -CONFIG_BLK_DEV_CRYPTOLOOP=n
    +CONFIG_BLK_DEV_CRYPTOLOOP=m
     # CONFIG_BLK_DEV_DRBD is not set
     # CONFIG_BLK_DEV_NBD is not set
     # CONFIG_BLK_DEV_NVME is not set
    @@ -1217,7 +1223,7 @@
     #
     # Controllers with non-SFF native interface
     #
    -CONFIG_SATA_AHCI=n
    +CONFIG_SATA_AHCI=m
     # CONFIG_SATA_AHCI_PLATFORM is not set
     # CONFIG_SATA_INIC162X is not set
     # CONFIG_SATA_ACARD_AHCI is not set
    @@ -1316,14 +1322,14 @@
     # CONFIG_I2O is not set
     CONFIG_NETDEVICES=y
     CONFIG_NET_CORE=y
    -CONFIG_BONDING=n
    +CONFIG_BONDING=m
     # CONFIG_DUMMY is not set
     # CONFIG_EQUALIZER is not set
     # CONFIG_NET_FC is not set
     CONFIG_MII=y
     # CONFIG_IFB is not set
     # CONFIG_NET_TEAM is not set
    -CONFIG_MACVLAN=n
    +CONFIG_MACVLAN=m
     # CONFIG_LTQ_ETHSW is not set
     # CONFIG_MACVTAP is not set
     # CONFIG_VXLAN is not set
    @@ -1386,14 +1392,14 @@
     # CONFIG_IP1000 is not set
     CONFIG_NET_VENDOR_LANTIQ=y
     CONFIG_LANTIQ_VRX318=y
    -CONFIG_ACCL_11AC=n
    +CONFIG_ACCL_11AC=m
     # CONFIG_LANITQ_VRX318_PCIE_SWITCH_DSL_BONDING is not set
     # CONFIG_LANTIQ_ETH_FRAMEWORK is not set
     CONFIG_LTQ_ETH_XRX500=y
     CONFIG_XRX500_ETH_DRV_COC_SUPPORT=y
     CONFIG_SW_ROUTING_MODE=y
     # CONFIG_HAPS_CPU_LOOPBACK_TEST is not set
    -# CONFIG_LTQ_ETH_OAM is not set
    +CONFIG_LTQ_ETH_OAM=m
     CONFIG_LTQ_TOE_DRIVER=y
     CONFIG_LTQ_DATAPATH=y
     # CONFIG_LTQ_DATAPATH_MIB is not set
    @@ -1436,7 +1442,7 @@
     # VRX318
     #
     CONFIG_VRX318_DATAPATH=y
    -CONFIG_VRX318_TC=n
    +CONFIG_VRX318_TC=m
     CONFIG_LTQ_DIRECTCONNECT_DP=y
     CONFIG_LTQ_DIRECTCONNECT_DP_DBG=y
     # CONFIG_JME is not set
    @@ -1530,12 +1536,12 @@
     # CONFIG_USB_PEGASUS is not set
     # CONFIG_USB_RTL8150 is not set
     # CONFIG_USB_RTL8152 is not set
    -CONFIG_USB_USBNET=n
    +CONFIG_USB_USBNET=m
     # CONFIG_USB_NET_AX8817X is not set
     # CONFIG_USB_NET_AX88179_178A is not set
    -CONFIG_USB_NET_CDCETHER=n
    +CONFIG_USB_NET_CDCETHER=m
     # CONFIG_USB_NET_CDC_EEM is not set
    -# CONFIG_USB_NET_CDC_NCM is not set
    +CONFIG_USB_NET_CDC_NCM=m
     # CONFIG_USB_NET_CDC_MBIM is not set
     # CONFIG_USB_NET_DM9601 is not set
     # CONFIG_USB_NET_SMSC75XX is not set
    @@ -1544,7 +1550,7 @@
     # CONFIG_USB_NET_NET1080 is not set
     # CONFIG_USB_NET_PLUSB is not set
     # CONFIG_USB_NET_MCS7830 is not set
    -CONFIG_USB_NET_RNDIS_HOST=n
    +CONFIG_USB_NET_RNDIS_HOST=m
     # CONFIG_USB_NET_CDC_SUBSET is not set
     # CONFIG_USB_NET_ZAURUS is not set
     # CONFIG_USB_NET_CX82310_ETH is not set
    @@ -1574,16 +1580,16 @@
     # CONFIG_LTQ_PPA_XRX300 is not set
     # CONFIG_LTQ_PPA_XRX330 is not set
     CONFIG_LTQ_PPA_GRX500=y
    -CONFIG_LTQ_PPA_API=y
    +CONFIG_LTQ_PPA_API=m
     # CONFIG_LTQ_MINI_JUMBO_FRAME_SUPPORT is not set
     CONFIG_LTQ_PPA_API_DIRECTPATH=y
     CONFIG_LTQ_PPA_API_DIRECTPATH_BRIDGING=y
     CONFIG_LTQ_PPA_API_DIRECTPATH_HAS_NEW_API=y
     CONFIG_LTQ_PPA_HAL_SELECTOR=y
    -CONFIG_LTQ_PPA_PAE_HAL=n
    +CONFIG_LTQ_PPA_PAE_HAL=m
     CONFIG_LTQ_PPA_LRO=y
     CONFIG_LTQ_PPA_TMU_HAL=y
    -CONFIG_LTQ_PPA_MPE_HAL=n
    +CONFIG_LTQ_PPA_MPE_HAL=m
     CONFIG_LTQ_PPA_COC_SUPPORT=y
     CONFIG_LTQ_BRIDGE_LEARNING=y
     # CONFIG_LTQ_PPA_HANDLE_CONNTRACK_SESSIONS is not set
    @@ -1591,7 +1597,7 @@
     # CONFIG_LTQ_PPA_DIRECTPATH_TX_QUEUE_SIZE is not set
     # CONFIG_LTQ_PPA_DIRECTPATH_TX_QUEUE_PKTS is not set
     # CONFIG_LTQ_PPA_DIRECTPATH_TX_IMQ is not set
    -CONFIG_LTQ_PPA_API_PROC=n
    +CONFIG_LTQ_PPA_API_PROC=m
     # CONFIG_LTQ_PPA_MFE is not set
     CONFIG_LTQ_PPA_AVM_PA=y
     CONFIG_LTQ_PPA_AVM_PA_COUNTER_INTERVAL=1
    @@ -1599,7 +1605,7 @@
     CONFIG_LTQ_PPA_QOS_WFQ=y
     CONFIG_LTQ_PPA_QOS_RATE_SHAPING=y
     CONFIG_LTQ_PPA_IPv6_ENABLE=y
    -CONFIG_LTQ_PPA_DATAPATH=y
    +CONFIG_LTQ_PPA_DATAPATH=m
     
     #
     # Package Selection
    @@ -1611,7 +1617,7 @@
     # CONFIG_LTQ_PPA_API_SW_FASTPATH is not set
     CONFIG_AVM_QOS=y
     CONFIG_AVM_QOS_GRX_TMU=y
    -CONFIG_AVM_NET_LINK_AUDIO=n
    +CONFIG_AVM_NET_LINK_AUDIO=m
     CONFIG_ISDN=y
     # CONFIG_ISDN_I4L is not set
     CONFIG_ISDN_CAPI=y
    @@ -1625,7 +1631,7 @@
     #
     # AVM CAPI-CODEC
     #
    -CONFIG_CAPI_CODEC=n
    +CONFIG_CAPI_CODEC=m
     # CONFIG_CAPI_CODEC_SPEEX is not set
     CONFIG_CAPI_CODEC_ILBC=y
     CONFIG_CAPI_CODEC_G729=y
    @@ -1639,7 +1645,7 @@
     #
     # AVM DECT Stack
     #
    -CONFIG_AVM_DECT=n
    +CONFIG_AVM_DECT=m
     # CONFIG_AVM_DECT_DEBUG is not set
     CONFIG_ISDN_DRV_AVMB1_VERBOSE_REASON=y
     CONFIG_CAPI_TRACE=y
    @@ -1653,11 +1659,11 @@
     # CONFIG_ISDN_DRV_AVMB1_B1PCI is not set
     # CONFIG_ISDN_DRV_AVMB1_T1PCI is not set
     # CONFIG_ISDN_DRV_AVMB1_C4 is not set
    -CONFIG_ISDN_CAPI_ISDN_NT_PCMLINK=n
    -CONFIG_ISDN_NT_PCMLINK_BLK=n
    -CONFIG_ISDN_NT_PCMLINK_E1=n
    -CONFIG_ISDN_NT_PCMLINK_STACK=n
    -CONFIG_ISDN_NT_PCMLINK_ISDN_AB=n
    +CONFIG_ISDN_CAPI_ISDN_NT_PCMLINK=m
    +CONFIG_ISDN_NT_PCMLINK_BLK=m
    +CONFIG_ISDN_NT_PCMLINK_E1=m
    +CONFIG_ISDN_NT_PCMLINK_STACK=m
    +CONFIG_ISDN_NT_PCMLINK_ISDN_AB=m
     # CONFIG_ISDN_NT_PCMLINK_DEBUG is not set
     # CONFIG_ISDN_NT_PCMLINK_NO_BCHANNEL is not set
     # CONFIG_ISDN_NT_PCMLINK_FAX is not set
    @@ -1742,6 +1748,7 @@
     # CONFIG_TFFS_DEV_LEGACY is not set
     CONFIG_TFFS_DEV_MTDNAND=y
     CONFIG_TFFS_DEV_CACHE=y
    +CONFIG_TFFS_DEV_CACHE_ENV_ONLY=y
     CONFIG_TFFS_ENV=y
     CONFIG_TFFS_PANIC_LOG=y
     CONFIG_TFFS_PANIC_LOG_ID=96
    @@ -1770,13 +1777,13 @@
     #
     # AVM Piglet (no emif)
     #
    -CONFIG_AVM_PIGLET_NOEMIF=n
    +CONFIG_AVM_PIGLET_NOEMIF=m
     CONFIG_AVM_PIGLET_DECT=y
     
     #
     # AVM PCMLINK driver for PCM-Routing
     #
    -CONFIG_UBIK2=n
    +CONFIG_UBIK2=m
     CONFIG_UBIK2_DEVELOPMENT_SUPPORT=0
     CONFIG_UBIK2_MSEC_PER_IRQ=4
     CONFIG_UBIK2_ISDNSTACK_ON_CPU=0
    @@ -1784,11 +1791,11 @@
     #
     # AVM DECT_IO
     #
    -CONFIG_AVM_DECT_IO=n
    +CONFIG_AVM_DECT_IO=m
     # CONFIG_LTQ_DSL_CPE_MEI_ARX is not set
     CONFIG_DSL_MEI_CPE_DRV=y
     CONFIG_LTQ_DSL_CPE_MEI_VRX=y
    -CONFIG_LTQ_VOIP_TIMER=n
    +CONFIG_LTQ_VOIP_TIMER=m
     CONFIG_LTQ_RCU=y
     
     #
    @@ -1997,7 +2004,7 @@
     # CONFIG_W1 is not set
     # CONFIG_POWER_SUPPLY is not set
     # CONFIG_POWER_AVS is not set
    -CONFIG_HWMON=n
    +CONFIG_HWMON=m
     # CONFIG_HWMON_VID is not set
     # CONFIG_HWMON_DEBUG_CHIP is not set
     
    @@ -2089,7 +2096,7 @@
     # CONFIG_SENSORS_ADS7871 is not set
     # CONFIG_SENSORS_AMC6821 is not set
     # CONFIG_SENSORS_INA209 is not set
    -CONFIG_SENSORS_INA2XX=n
    +CONFIG_SENSORS_INA2XX=m
     # CONFIG_SENSORS_THMC50 is not set
     # CONFIG_SENSORS_TMP102 is not set
     # CONFIG_SENSORS_TMP401 is not set
    @@ -2106,7 +2113,7 @@
     # CONFIG_SENSORS_W83L786NG is not set
     # CONFIG_SENSORS_W83627HF is not set
     # CONFIG_SENSORS_W83627EHF is not set
    -CONFIG_LTQ_SPDMON=n
    +CONFIG_LTQ_SPDMON=m
     # CONFIG_THERMAL is not set
     # CONFIG_WATCHDOG is not set
     CONFIG_SSB_POSSIBLE=y
    @@ -2256,8 +2263,8 @@
     # USB Host Controller Drivers
     #
     # CONFIG_USB_C67X00_HCD is not set
    -CONFIG_USB_XHCI_HCD=n
    -CONFIG_USB_XHCI_PLATFORM=n
    +CONFIG_USB_XHCI_HCD=m
    +CONFIG_USB_XHCI_PLATFORM=m
     # CONFIG_USB_XHCI_HCD_DEBUGGING is not set
     # CONFIG_USB_EHCI_HCD is not set
     # CONFIG_USB_OXU210HP_HCD is not set
    @@ -2273,8 +2280,8 @@
     #
     # USB Device Class drivers
     #
    -CONFIG_USB_ACM=n
    -CONFIG_USB_PRINTER=n
    +CONFIG_USB_ACM=m
    +CONFIG_USB_PRINTER=m
     # CONFIG_USB_WDM is not set
     # CONFIG_USB_TMC is not set
     
    @@ -2313,7 +2320,7 @@
     #
     # USB port drivers
     #
    -CONFIG_USB_SERIAL=n
    +CONFIG_USB_SERIAL=m
     # CONFIG_USB_SERIAL_GENERIC is not set
     # CONFIG_USB_SERIAL_AIRCABLE is not set
     # CONFIG_USB_SERIAL_ARK3116 is not set
    @@ -2358,8 +2365,8 @@
     # CONFIG_USB_SERIAL_TI is not set
     # CONFIG_USB_SERIAL_CYBERJACK is not set
     # CONFIG_USB_SERIAL_XIRCOM is not set
    -CONFIG_USB_SERIAL_WWAN=n
    -CONFIG_USB_SERIAL_OPTION=n
    +CONFIG_USB_SERIAL_WWAN=m
    +CONFIG_USB_SERIAL_OPTION=m
     # CONFIG_USB_SERIAL_OMNINET is not set
     # CONFIG_USB_SERIAL_OPTICON is not set
     # CONFIG_USB_SERIAL_VIVOPAY_SERIAL is not set
    @@ -2543,7 +2550,7 @@
     #
     # HID Sensor RTC drivers
     #
    -CONFIG_RTC_DRV_AVM_REF_CLOCK=n
    +CONFIG_RTC_DRV_AVM_REF_CLOCK=m
     CONFIG_DMADEVICES=y
     # CONFIG_DMADEVICES_DEBUG is not set
     
    @@ -2712,7 +2719,7 @@
     #
     CONFIG_FAT_FS=y
     CONFIG_MSDOS_FS=y
    -CONFIG_VFAT_FS=n
    +CONFIG_VFAT_FS=m
     CONFIG_FAT_DEFAULT_CODEPAGE=437
     CONFIG_FAT_DEFAULT_IOCHARSET="iso8859-1"
     # CONFIG_NTFS_FS is not set
    @@ -2731,12 +2738,12 @@
     CONFIG_TMPFS_POSIX_ACL=y
     CONFIG_TMPFS_XATTR=y
     # CONFIG_HUGETLB_PAGE is not set
    -CONFIG_CONFIGFS_FS=n
    +CONFIG_CONFIGFS_FS=m
     CONFIG_MISC_FILESYSTEMS=y
     # CONFIG_ADFS_FS is not set
     # CONFIG_AFFS_FS is not set
    -CONFIG_HFS_FS=n
    -CONFIG_HFSPLUS_FS=n
    +CONFIG_HFS_FS=m
    +CONFIG_HFSPLUS_FS=m
     # CONFIG_BEFS_FS is not set
     # CONFIG_BFS_FS is not set
     # CONFIG_EFS_FS is not set
    @@ -2789,11 +2796,11 @@
     # CONFIG_AFS_FS is not set
     CONFIG_NLS=y
     CONFIG_NLS_DEFAULT="iso8859-1"
    -CONFIG_NLS_CODEPAGE_437=n
    +CONFIG_NLS_CODEPAGE_437=m
     # CONFIG_NLS_CODEPAGE_737 is not set
     # CONFIG_NLS_CODEPAGE_775 is not set
    -CONFIG_NLS_CODEPAGE_850=n
    -CONFIG_NLS_CODEPAGE_852=n
    +CONFIG_NLS_CODEPAGE_850=m
    +CONFIG_NLS_CODEPAGE_852=m
     # CONFIG_NLS_CODEPAGE_855 is not set
     # CONFIG_NLS_CODEPAGE_857 is not set
     # CONFIG_NLS_CODEPAGE_860 is not set
    @@ -2813,7 +2820,7 @@
     # CONFIG_NLS_CODEPAGE_1250 is not set
     # CONFIG_NLS_CODEPAGE_1251 is not set
     # CONFIG_NLS_ASCII is not set
    -CONFIG_NLS_ISO8859_1=n
    +CONFIG_NLS_ISO8859_1=m
     # CONFIG_NLS_ISO8859_2 is not set
     # CONFIG_NLS_ISO8859_3 is not set
     # CONFIG_NLS_ISO8859_4 is not set
    @@ -2823,7 +2830,7 @@
     # CONFIG_NLS_ISO8859_9 is not set
     # CONFIG_NLS_ISO8859_13 is not set
     # CONFIG_NLS_ISO8859_14 is not set
    -CONFIG_NLS_ISO8859_15=n
    +CONFIG_NLS_ISO8859_15=m
     # CONFIG_NLS_KOI8_R is not set
     # CONFIG_NLS_KOI8_U is not set
     # CONFIG_NLS_MAC_ROMAN is not set
    @@ -2837,7 +2844,7 @@
     # CONFIG_NLS_MAC_INUIT is not set
     # CONFIG_NLS_MAC_ROMANIAN is not set
     # CONFIG_NLS_MAC_TURKISH is not set
    -CONFIG_NLS_UTF8=n
    +CONFIG_NLS_UTF8=m
     # CONFIG_DLM is not set
     
     #
    @@ -2862,7 +2869,7 @@
     # CONFIG_PANIC_ON_OOPS is not set
     CONFIG_PANIC_ON_OOPS_VALUE=0
     # CONFIG_DETECT_HUNG_TASK is not set
    -CONFIG_SCHED_DEBUG=y
    +# CONFIG_SCHED_DEBUG is not set
     # CONFIG_SCHEDSTATS is not set
     # CONFIG_TIMER_STATS is not set
     # CONFIG_DEBUG_OBJECTS is not set
    @@ -2871,7 +2878,7 @@
     # CONFIG_DEBUG_KMEMLEAK is not set
     # CONFIG_DEBUG_RT_MUTEXES is not set
     # CONFIG_RT_MUTEX_TESTER is not set
    -CONFIG_DEBUG_SPINLOCK=y
    +# CONFIG_DEBUG_SPINLOCK is not set
     # CONFIG_DEBUG_MUTEXES is not set
     # CONFIG_DEBUG_LOCK_ALLOC is not set
     # CONFIG_PROVE_LOCKING is not set
    @@ -2984,7 +2991,7 @@
     # CONFIG_CRYPTO_CTS is not set
     CONFIG_CRYPTO_ECB=y
     # CONFIG_CRYPTO_LRW is not set
    -CONFIG_CRYPTO_PCBC=n
    +CONFIG_CRYPTO_PCBC=m
     # CONFIG_CRYPTO_XTS is not set
     
     #
    @@ -3001,40 +3008,40 @@
     CONFIG_CRYPTO_CRC32C=y
     # CONFIG_CRYPTO_CRC32 is not set
     CONFIG_CRYPTO_GHASH=y
    -CONFIG_CRYPTO_MD4=n
    +CONFIG_CRYPTO_MD4=m
     CONFIG_CRYPTO_MD5=y
    -CONFIG_CRYPTO_MICHAEL_MIC=n
    +CONFIG_CRYPTO_MICHAEL_MIC=m
     # CONFIG_CRYPTO_RMD128 is not set
     # CONFIG_CRYPTO_RMD160 is not set
     # CONFIG_CRYPTO_RMD256 is not set
     # CONFIG_CRYPTO_RMD320 is not set
     CONFIG_CRYPTO_SHA1=y
    -CONFIG_CRYPTO_SHA256=n
    -CONFIG_CRYPTO_SHA512=n
    -CONFIG_CRYPTO_TGR192=n
    -CONFIG_CRYPTO_WP512=n
    +CONFIG_CRYPTO_SHA256=m
    +CONFIG_CRYPTO_SHA512=m
    +CONFIG_CRYPTO_TGR192=m
    +CONFIG_CRYPTO_WP512=m
     
     #
     # Ciphers
     #
     CONFIG_CRYPTO_AES=y
    -CONFIG_CRYPTO_ANUBIS=n
    +CONFIG_CRYPTO_ANUBIS=m
     CONFIG_CRYPTO_ARC4=y
     CONFIG_CRYPTO_BLOWFISH=y
     CONFIG_CRYPTO_BLOWFISH_COMMON=y
     # CONFIG_CRYPTO_CAMELLIA is not set
    -CONFIG_CRYPTO_CAST_COMMON=n
    -CONFIG_CRYPTO_CAST5=n
    -CONFIG_CRYPTO_CAST6=n
    +CONFIG_CRYPTO_CAST_COMMON=m
    +CONFIG_CRYPTO_CAST5=m
    +CONFIG_CRYPTO_CAST6=m
     CONFIG_CRYPTO_DES=y
     # CONFIG_CRYPTO_FCRYPT is not set
    -CONFIG_CRYPTO_KHAZAD=n
    +CONFIG_CRYPTO_KHAZAD=m
     # CONFIG_CRYPTO_SALSA20 is not set
     # CONFIG_CRYPTO_SEED is not set
    -CONFIG_CRYPTO_SERPENT=n
    -CONFIG_CRYPTO_TEA=n
    -CONFIG_CRYPTO_TWOFISH=n
    -CONFIG_CRYPTO_TWOFISH_COMMON=n
    +CONFIG_CRYPTO_SERPENT=m
    +CONFIG_CRYPTO_TEA=m
    +CONFIG_CRYPTO_TWOFISH=m
    +CONFIG_CRYPTO_TWOFISH_COMMON=m
     
     #
     # Compression
    Zwar braucht man jetzt bei der 7580 nicht zu raten, welche Kernel-Konfiguration AVM da nun verwendet haben mag ... aber die Chancen, mit dem reinen OpenSource-Paket (so wie es die GPLv2 eigentlich fordert) einen funktionsfähigen, identischen Kernel zu erstellen, dürften (augenscheinlich) gegen Null tendieren.

    Wenn also man wieder jemand von oder bei AVM über die "vorbildliche" Bereitstellung von OpenSource-Paketen schwadroniert - sei es auf irgendeiner Messe oder anderswo, die CeBIT steht ja vor der Tür -, dann kann so jemand ja vielleicht auch diesen Widerspruch (zumindest für mich ist es einer, denn die mitgelieferte ".config" paßt nicht zum tatsächlich verwendeten Kernel - auch wenn man das bei den schon vorher sichtbaren Unterschieden zwischen "n" und "m" bei diversen LKM schon erwarten konnte) "auflösen".

    EDIT: Korrektur meinerseits ... AVM hat die Quellen für die 06.54 noch gar nicht bereitgestellt (diese Firmware-Version wurde am 19.10.2016 erstellt). Die von mir zum Vergleich benutzte ".config" stammt also noch aus dem Paket zur 153.06.53. Ich werde bei Gelegenheit den in der 06.53 verwendeten Kernel (wenn ich ihn dann entpacken konnte, was ja auch noch als ToDo ansteht) untersuchen, dort die verwendete Konfiguration auslesen (sollte bei entpacktem Kernel mit "scripts/extract_ikconfig" aus den Kernel-Sourcen funktionieren) und dann noch einmal den oben stehenden Vergleich starten - ich erwarte zwar keine gravierenden Unterschiede, aber man weiß ja nie ...
    Angehängte Dateien Angehängte Dateien
    Geändert von PeterPawn (17.03.2017 um 00:02 Uhr)

  18. #38
    IPPF Fünfhunderter
    Registriert seit
    20.12.2005
    Beiträge
    872
    Das "=n" von AVM ist als "=m" von vanilla zu verstehen (und nicht als "# CONFIG_XY is not set"). Warum AVM "=n" verwendet kann ich nicht sagen. Eventuell verwenden sie irgendein altes oder irgendein eigenes Tool zum Konfigurieren des Kernels. Oder es ist sogar ein Fehler in deren Routine, die deren Open-Source-Pakete bastelt. Diese sind ja auch an einigen anderen Stellen unplausibel/komisch - Namen der Tarballs spiegeln nicht unbedingt den Inhalt wider, busybox-Tarball enthält z.B. gar keine busybox, usw.

    Edit: das mit "=n" haben sie übrigens nicht von Anfang an gemacht, die "alten" .config's (die für 04.XX) enthalten noch "=m", ab 05.XX sind diese zu "=n" geworden.
    Geändert von er13 (17.03.2017 um 11:33 Uhr)

  19. #39
    IPPF Siebentausend-VIP Avatar von PeterPawn
    Registriert seit
    10.05.2006
    Ort
    Berlin
    Beiträge
    7.937
    Ich habe schon durchaus auch eine Idee/Vermutung, was sich AVM dabei gedacht hat ... die Makefiles arbeiten ja häufig mit der Konstruktion:
    Code:
    obj-$(CONFIG_SOMEWHAT)     += somewhat.o
    
    konkret z.B.:
    obj-$(CONFIG_LTQ_PPA_DATAPATH)      += ltqmips_ppe_drv.o
    für das Zusammenstellen von Listen-Variablen.

    Damit werden also die ganzen von AVM als Module "angedachten" Dateien nicht in der Variablen "obj-m", sondern in "obj-n" gesammelt (im Code meist über Präprozessor-"#ifdef" abgefragt und da ist es egal, ob das "y", "m" oder "n" ist) und beim Linken bzw. beim Build für die Module damit nicht berücksichtigt, weil dort natürlich "obj-m" oder "obj-y" verwendet wird.

    Damit dürfte man also das Problem "fehlender" Module (bzw. fehlender Quellen dafür) umgehen ... aber die Tatsache, daß das nirgendwo dokumentiert ist und man sich das alles selbst zusammensuchen und -reimen muß, führt natürlich die Forderung aus der GPLv2 trotzdem ad absurdum; ebenso der seit der Veröffentlichung der 06.54 vergangene Zeitraum, in dem die AVM-OpenSource-Pakete für diese Version nun schon fehlen. Inzwischen fehlen mittendrin ja auch die 06.80 und 06.81 - auch für die 7580 wird sicherlich die 06.83 nicht mehr lange auf sich warten lassen; die anderen Modelle sind ja inzwischen "versorgt".

    So bleiben selbst beim Ausblenden dieser Unterschiede noch Differenzen übrig, die teilweise zwar tatsächlich dem Unterschied 06.53 (bei den Sourcen) und 06.54 (beim Kernel) zuzurechnen sind (das ist auch die Richtung für das folgende "diff"-Kommando):
    Code:
    # diff -u .config /tmp/.config | grep -v "^+.*=m\$" | grep -v "^-.*=n\$" | grep -v "^ " | grep -v "^@" | grep -v "^+++" | grep -v "^---"
    -CONFIG_SPLIT_PTLOCK_CPUS=999999
    +CONFIG_SPLIT_PTLOCK_CPUS=4
    -CONFIG_UNINLINE_SPIN_UNLOCK=y
    +CONFIG_INLINE_SPIN_UNLOCK_IRQ=y
    +CONFIG_INLINE_READ_UNLOCK=y
    +CONFIG_INLINE_READ_UNLOCK_IRQ=y
    +CONFIG_INLINE_WRITE_UNLOCK=y
    +CONFIG_INLINE_WRITE_UNLOCK_IRQ=y
    -# CONFIG_AVM_IPI_YIELD is not set
    +CONFIG_AVM_IPI_YIELD=y
    +CONFIG_AVM_IPI_YIELD_DEBUG=y
    +CONFIG_AVM_BRIDGE_FLOOD_RATELIMITER=y
    -# CONFIG_LTQ_ETH_OAM is not set
    -# CONFIG_USB_NET_CDC_NCM is not set
    -CONFIG_LTQ_PPA_API=y
    -CONFIG_LTQ_PPA_DATAPATH=y
    +CONFIG_TFFS_DEV_CACHE_ENV_ONLY=y
    -CONFIG_SCHED_DEBUG=y
    +# CONFIG_SCHED_DEBUG is not set
    -CONFIG_DEBUG_SPINLOCK=y
    +# CONFIG_DEBUG_SPINLOCK is not set
    , aber das macht es ja nicht besser, wie AVM hier (wieder einmal) die OpenSource-Pakete behandelt. Mein Fehler war allerdings, daß ich vor dem ersten "diff" weiter oben nicht die tatsächliche Version des OSS-Paketes verifiziert hatte und damit 06.53 mit 06.54 (also Äpfel mit Pferdeäpfeln) verglichen habe.

    Wobei es sich beim "BRIDGE_FLOOD_RATELIMITER" und bei "TFFS_DEV_CACHE_ENV_ONLY" wohl um bei der 06.54 erst neu eingeführte Parameter handelt, denn in der 06.53 sind sie ja nicht als "is not set" enthalten - der Unterschied bei "LTQ_PPA_API" und "LTQ_PPA_DATAPATH" dürfte sich aber direkt auf die Struktur des Kernels auswirken (hier ist "y" vs. "m" und das müßte sich beim Linken des Kernels eigentlich bemerkbar machen) und ich bin tatsächlich mal gespannt, ob die 06.53-Sourcen da mit dem 06.53-Kernel übereinstimmen werden.

    Die unterschiedlichen "DEBUG"-Einstellungen kann man sicherlich ohnehin in den Skat drücken (für die Funktion oder das Versagen einzelner Feature jedenfalls), bei "CONFIG_USB_NET_CDC_NCM" dürfte das aber schon den Unterschied machen, ob einige Sticks (die nur mit NCM funktionieren) an der Box nach wie vor (in demselben Umfang wie bei der 06.54 von AVM) arbeiten oder nicht.
    Geändert von PeterPawn (17.03.2017 um 13:29 Uhr)

  20. #40
    IPPF Fünfhunderter
    Registriert seit
    20.12.2005
    Beiträge
    872
    Zitat Zitat von PeterPawn Beitrag anzeigen
    Damit dürfte man also das Problem "fehlender" Module (bzw. fehlender Quellen dafür) umgehen
    Ja, ist durchaus denkbar, klingt zumindest sehr plausibel.


    Zitat Zitat von PeterPawn Beitrag anzeigen
    ... aber die Tatsache, daß das nirgendwo dokumentiert ist und man sich das alles selbst zusammensuchen und -reimen muß, führt natürlich die Forderung aus der GPLv2 trotzdem ad absurdum; ebenso der seit der Veröffentlichung der 06.54 vergangene Zeitraum, in dem die AVM-OpenSource-Pakete für diese Version nun schon fehlen.
    Ja, das "GPL-Einhalten" ist leider überhaupt keine Stärke von AVM. Es ist sogar eine Dreistigkeit, was sie sich da so alles erlauben: für manche Boxen wurden bisher gar keine Quellen veröffentlicht für keine Firmware-Version (nur als Beispiel sei die 7412 genannt, die echte Liste ist viel länger), für manche Boxtyp/Firmware-Kombinationen wurde auch Jahre nach dem Release keine Quellen veröffentlicht (wieder nur als Beispiel seien AR10-Boxen und Fritz!OS 6.0X genannt). Wenn was veröffentlicht wird, konnte schon mehrfach nachgewiesen werden, dass das Veröffentlichte nicht dem tatsächlich Verwendeten entspricht (wieder nur als Beispiel, seien AR10-Boxen und Fritz!OS-5.5X genannt, s. hier). BuildRoot-Konfigurationen entweder fehlen gänzlich (ältere Pakete) oder sind nicht richtig, sodass die uClibc-Konfiguration daraus abgeleitet werden muss, welche Symbole es in der binären Version gibt. Den Quellcode für SquashFS-Tools habe ich ebenso noch nie in deren Paketen gesehen, usw. usw. usw.


    Leider haben wie es auch nie geschafft, uns die Zeit zu nehmen, zu überlegen, wie wir AVM gegenüber auftreten könnten, damit sich die Situation bessert.

Seite 2 von 4 ErsteErste 1234 LetzteLetzte

Ähnliche Themen

  1. [Info] Opensource der FBF 7390 84.05.01
    Von 3949354 im Forum Freetz
    Antworten: 4
    Letzter Beitrag: 01.04.2011, 09:40
  2. Antworten: 20
    Letzter Beitrag: 23.10.2008, 19:31
  3. SOT als OpenSource?
    Von FalkoD im Forum SOT / Streaming Client
    Antworten: 6
    Letzter Beitrag: 17.06.2007, 09: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, 14: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, 10:14

Berechtigungen

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