Treiber fest in Kernel einbinden

[zwette]

Ich versuche, den Promise-Treiber für den Fasttrak 378 fest in den 2.4.29er Kernel einzubauen. Die Sourcen habe ich mir runtergeladen (Kernel und Treiber). Dann kompilier ich den Treiber mit "make all". Den ganzen Kram kopier ich in /usr/src/linux-2.4.29/drivers/ide/raid und füg in die config.in noch

dep_tristate ' Promise PDC 203xx support' CONFIG_PDC203XX

hinzu, dass er die ft3xx.o mit einbinden soll. Genauso im Makefile in /usr/src/linux-2.4.29.

Kennt sich jemand damit aus? Wie macht man das exakt? Worauf muss ich achten? Gibt es irgendwo ne brauchbare Anleitung?

[pdreker]

Externe Treiber kann man normalerweise nur als Modul bauen. Das Hacken der makefiles/Configs reicht nicht, weil dazu auch Infrastruktur im SOurce erforderlich ist...

Tipp: benutze eine initrd, wenn Du den Treiber zum booten brauchst...

Patrick

[zwette]

Ok, dann bräuchte ich eine Anleitung für folgendes Szenario:

Ein Athlon 64 auf A8V Deluxe mit einem PATA-RAID0 soll mit Debian versehen werden. Standardmäßig findet Debian (Woody/Sarge) den Controller (Promise Fasttrak 378) nicht. Die Netinstall-CD eines Freundes, mit der ich einen Treiber von Diskette laden kann, hauchen dem System das erste Mal Leben ein. Das RAID wird erkannt, partitioniert und das Basissystem aufgespielt. Und jetzt kommt der Haken. Der Neustart lässt das Basissystem wieder im Nirvana verschwinden, weil der aufgespielte Kernel den Promise-Treiber nicht hat und auch nicht lädt. Wie bekomm ich den Treiber auf die Platte und wie das System zum Starten. Ich dachte immer, dass solche Treiber (wie auch IDE, Ext3, etc) immer fest im Kernel sein müssen, um das System zu starten!?

Deswegen auch die Frage nach "Treiber in den Kernel einbinden"...

[minimike]

mkinitrd $Kernelversion -o $Modulname

Modul mus natürlich installiert sein. Kannst du Knoppix verwenden ? Nicht lachen, ich muss Sarge von Knoppix über debootstrap und chroot aus installieren, weil beide Debiankernel mit meinem Sata Controller Probleme verusachen. Beide produzieren eine Fehlfunktion. Der 2.6.8 und 2.6.xx abwärts hat Probleme mit SATA Adaptern mit Silicon Image Chip. Das selbe mit dem 2.4.27 und den IDE Raid Treibern wobei es mittels SCSI gehen würde. Dummerweise werden default die IDE Treiber verwendet

[Meesta]

Kann zwar gerade nicht wirklich was zum Thema beisteuern da ich es auch noch nicht geschafft habe einen Treiber direkt in den Kernel zu bekommen.

aber laut:

Ob ein Treiber fest in den Kernel einkompiliert oder als Modul nach dem Hochfahren geladen wird, ist für die Programmierung des Treibers irrelevant. In beiden Fällen werden genau die gleichen Funktionen kodiert, nur wird im ersten Fall die Treiber-Initialisierungsfunktion beim Hochfahren, im zweiten Fall beim Laden des Moduls aufgerufen. Das Gleiche gilt für die Deinitialisierung. Allerdings muss vor dem Kompilieren festgelegt werden, ob der Treiber als Modul oder als Kernel-Bestandteil generiert werden soll. Aufgrund der Compiler-Option MODULE werden die beiden Makros module_init und module_exit nämlich unterschiedlich expandiert.

Quelle: http://ezs.kr.hsnr.de/TreiberBuch/html/ ... ONFIGENTRY

sollte es doch egal sein. Wenn der Treiber als Modul läuft müsste er sich auch als Built-In verwenden lassen oder sehe ich das Falsch?

[minimike]

Dann müste er dazu auch in den Kernelsourcen drinn sein. Wenn nicht must du genug Skills habe. Es reicht nicht aus um ein paar Makefiles zu editieren und den Code einzufügen. Ich selber bin daran gescheitert den Code vom Treiber 3x59x aus dem 2.4.29 in den 2.4.27 mit Debianpatch zu übertragen.

[zwette]

Ein Built-in-Treiber wird erstellt, indem

1. die Treiberquellen in ein entsprechendes Verzeichnis in den Kernelquellen kopiert wird. Für einen zeichenorientierten Treiber ist dies beispielsweise <drivers/char/>. Die Quellen eines USB-Treibers werden abhängig von der Art des Gerätes in das entsprechende USB-Unterverzeichnis (<drivers/usb/>) kopiert: media/, net/, serial/, input/ oder storage/. Geräte, die sich in keiner der angegebenen Klassen einordnen lassen, werden in das Verzeichnis misc/ kopiert. Der Quellcode für PCI-Geräte wird allerdings nicht in das Verzeichnis <drivers/pci/> kopiert, sondern in ein dem Gerätetyp entsprechendes Verzeichnis (zum Beispiel <drivers/media/>). Die genaue Stelle, an der die Quellen kopiert werden, kann auch über die Kernelkonfiguration bestimmt werden. Die Auswahl zum Treiber taucht nämlich entsprechend der Ablage der Quellen innerhalb des Verzeichnisbaumes auf.

2. Die Datei Kconfig des Verzeichnisses, in dem sich die Treiberquellen jetzt befinden, wird um die neue Option erweitert, mit der der Treiber ausgewählt werden kann. Handelt es sich um einen reinen Built-in-Treiber, wird eine Konfigurationsvariable vom Typ bool gewählt. Kann der Treiber auch als Modul realisiert werden, wird der Typ tristate ausgewählt.

3. Das Makefile des Verzeichnisses, in dem sich die Treiberquellen jetzt befinden, wird erweitert. Es wird eine neue Zeile hinzugefügt, mit der der Name des Treibers an eine der beiden Variablen (abhängig von der Konfigurationsvariablen) wie oben beschrieben angehängt wird.

4. Der Kernel wird neu konfiguriert, indem in dem Kernel-Quellverzeichnis (z.B. /usr/src/linux/) das Kommando make menuconfig oder das Kommando make xconfig aufgerufen wird.

Also bin ich doch auf dem richtigen Weg... so ähnlich hatte ich schon angefangen. Das kann alles nicht so schwer sein. Ich schau mal, unter welchem Kernel der Treiber laufen soll.

[Meesta]

Zu beachten ist, das die Anleitung sich auf den 2.6er Kernel bezieht. Da hat sich einiges seit dem 2.4er getan.

[HELLinG3R]

Hallo!
Ich habe hier im prinzip die gleiche Problemstellung.

Hat das nun nach dem Zitierten "mini-howto" von zwette funktioniert?
Rein theorethisch sollte ich doch auch ein eigenes Unterverzeichnis erstellen können, oder erkennt der Kernel anhand des Speicherortes, was für ein Treiber es ist und wo er zu laden ist?

Wie ist das, wenn ich einen vorhandenen Treiber (3ware raid) durch die Version der 3ware seite ersetzen will?