Kernel-Modul musb_hdrc ändern - Ziel: isochroner USB-Transfermodus

[Chatty]

Hallo,

ich wollte mich mal an meinen eigenen Vorschlag machen, nachdem dieser von niemandem aufgegriffen wurde.

Konkret geht es um musb_hdrc.ko (config USB_MUSB_HDRC). Der Source hierzu liegt sowohl unter
./source/avm-gpl-7270_04.76/GPL/base/kernel/linux-2.6.19.2/drivers/usb/musb/ und
./source/ref-8mb_26-7270_04.76/kernel/kernel_8mb_26_build/kernel/linux-2.6.19.2/drivers/usb/musb/

Warum wird die überflüssige Kopie nicht gelöscht und welche muss geändert werden, um ins finale Image übernommen zu werden?

Gibt es sonst noch etwas zu beachten (außer zu hoffen, dass sich zwischen 2.6.19.2 und 2.6.32 die Schnittstellen nicht großartig geändert haben)?

Ziel wäre:
rmmod musb_hdrc
insmod /neues_Modul/musb_hdrc.ko

Forschungsergebnisse:
* musb-Treiber kam erst am 24.06.08 in den offiziellen Kernel (müsste 2.6.26 gewesen sein).
* letztere Änderungen am musb-Treiber gerade erst am 02.11.09

 

[olistudent]

Die Kopie ist nicht überflüssig, sondern die gepatchte Version des Source.

Du solltest vielleicht nicht gleich mit dem neuesten Kernel anfangen. Normalerweise kommt man mit so Versuchen nicht wirklich weit. Aber du kannst es gerne probieren. Der musb ist auch noch nicht lange im vanilla Kernel oder?

MfG Oliver

 

[linuxkasten]

Ist musb wieder so ein AVM-Chip oder ein allgemeiner Standard-Chip?
Hat er irgendwas mit dem alten AHCI-1.1 gemeinsam?
(Ich wette, du willst auf den isochronen Transfer hinaus...)

 

[RalfFriedl]

Wenn Quellen dafür vorhanden sind, ist es vermutlich ein anderer Chip, zumal er USB 2.0 unterstützt.

 

[Chatty]

Die Kopie ist nicht überflüssig, sondern die gepatchte Version des Source.

Hmm, aber in Bezug auf musb sind beide Verzeichnis identisch - also inklusive AVM-Patches.

Außerdem hast du noch nicht beantwortet, welches Verzeichnis ich ändern muss, damit es in den Kernel gelangt (kann man natürlich auch einfach ausprobieren :-(). Und muss man sonst noch etwas beachten? (irgendeine Config.in ändern, make sonstwas ausführen, touch Datei-X damit make die Änderung erkennt usw.)

 

[olistudent]

Ändern musst du das: ./source/ref-8mb_26-7270_04.76/kernel/kernel_8mb_26_build/kernel/linux-2.6.19.2/drivers/usb/musb/

Wir haben keine AVM-Patches. Die Targets sind "make kernel-precompiled" und "make kernel-dirclean". Wobei du nach einer Änderung ein "make kernel-menuconfig" ausführen solltest und dann ein "make kernel-precompiled". Da sparst du dir das dirclean und eine Menge Zeit.

MfG Oliver

 

[Chatty]

Vielen Dank für deine Tipps, das erspart mir schon mal eine Menge Probieren.

Mit AVM-Patches meinte ich deren Änderungen am "offiziellen" musb-Treiber, den es so jedoch in 2.6.19.2 gar nicht gab. Habe aber erst jetzt verstanden, dass die zwei "Kopien" wohl AVM-Original mit und ohne Freetz-Änderung sind.

 

[RalfFriedl]

Die Dateien in musb sind in beiden Verzeichnissen gleich, wenn es keine Patches dafür gibt. Das heißt aber nicht, daß es für den ganzen Kernel keine Patches gibt.

Außerdem gibt es noch ein Make-Target "kernel-force", mit dem das Kernel-Make aufgerufen wird, auch ohne daß man sonst etwas tun muß.

Vor einem "make kernel-dirclean" und sicherheitshalber auch vor einem "svn up" sollte man die selbst gemachten Änderungen sichern bzw. gleich als Patch abspeichern.

 

[Chatty]

@Ralf: make kernel-force, selbst nach einem make kernel-menuconfig führt nicht zur Kompilation geänderter Sourcedateien. Olivers Tipp funktioniert aber (make kernel-menuconfig && make kernel-precompiled).

 

[RalfFriedl]

Es war aber mal extra dafür gedacht. Vielleicht hat sich seither etwas geändert und es funktioniert deswegen nicht mehr?
Was genau passiert denn bei Dir? Gar nichts, oder wird nur ein Teil übersetzt?

 

[Chatty]

Also ein Teil der Ausgabe sieht identisch aus (zw. precompiled und force). Jedoch scheint es, als würde er die Änderung nicht erkennen. Man könnte ja mal einen sauberen Trunk auschecken und schauen, ob dann etwas kompiliert wird...

 

[olistudent]

Ist denn das musb-Modul gebaut worden?

Mfg Oliver

 

[Chatty]

Mit precompiled ja, mit force nein.

 

[RalfFriedl]

Also ein Teil der Ausgabe sieht identisch aus (zw. precompiled und force).

Und der andere Teil nicht. Alles klar.

Das Target kernel-force ruft das Kernel-Make auf und sollte somit alle geänderten Dateien neu compilieren.
Es kopiert aber nicht die erstellten Module aus dem Kernel-Tree heraus. Dafür kann man kernel-precompiled verwenden. Das wird aber meines Wissens sowieso beim Erstellen der Firmware aufgerufen.

 

[Chatty]

Und der andere Teil nicht. Alles klar.

Sei doch nicht gleich so sarkastisch. Ich vergaß anzuhängen: und ein anderer Teil scheint zu fehlen (bei force).

 

[RalfFriedl]

Das ergibt sich fast automatisch. Entweder ein Teil fehlt, oder ein Teil ist unterschiedlich. Interessanter wäre, was fehlt.

Aber ist es das, was ich oben in #14 beschrieben habe?

 

[cuma]

@Chatty: Läuft das Modul? Würde mich gern als Tester zur Verfügung stellen.

 

[Chatty]

Ich hab jetzt alle nötigen Vorbereitungen hinter mir, jetzt muss ich wieder Zeit finden, weiter zu vergleichen. Da AVM einige Anpassungen gemacht, die nicht zurück in den Kernel geflossen sind, lässt sich ohne weiteres nicht der aktuelle Kernel-Treiber verwenden. Im Übrigen lässt sich dass von mir im Moment verwendete WinMerge leicht aus dem Tritt bringen, was die Sache nicht gerade erleichtert.

Sobald es etwas Neues gibt, melde ich es hier.

 

[linuxkasten]

Hab mal eine Verständnisfrage: Du willst den Treiber von einem aktuelleren Linux-Vanilla-Kernel nehmen, weil da der isochrone Transport implementiert ist, und diesen zum FritzBox-Kernel backporten, oder?
Und was/warum hat AVM rumgepatcht? Haben die am musb noch was verändert?
Verwendest du Windows zum Linux-Kernel basteln?

Ich blick da nicht ganz durch, deswegen wärs schön, wenn mir das jemand beantworten könnte

 

[Silent-Tears]

Das "warum" wird dir nur AVM beantworten können. Und das "was" liegt den veröffentlichten Sourcen bei.