Seite 2 von 2 ErsteErste 12
Ergebnis 21 bis 30 von 30

Thema: Fehlende Bestandteile im OpenSource-Paket von AVM

  1. #21
    IPPF-Fan
    Registriert seit
    27.05.2010
    Beiträge
    282
    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.239
    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
    27.05.2010
    Beiträge
    282
    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 04:59 Uhr)

  4. #24
    IPPF Siebentausend-VIP Avatar von PeterPawn
    Registriert seit
    10.05.2006
    Ort
    Berlin
    Beiträge
    7.239
    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
    27.05.2010
    Beiträge
    282
    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 19:00 Uhr)

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

Seite 2 von 2 ErsteErste 12

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