Homepage Wiki Forum Buy

Backport Kernel

Aus GNUBLIN

Schwierigkeitsgrad Voraussetzung Gnublin Familie
Gnublin logo advanced.png Kernel kompilieren, Toolchain Alle


Neue Hardware auf altem Kernel

Als Grundlage diente mir ein auf buildroot basiertes Gnublin Linux. Die Vorgehensweise bei einer Debian Distribution ist analog, da sie auf dem gleichen Kernel aufbaut.

Inhaltsverzeichnis


Kleine Anmerkung: Das Ganze ist ein iterativer und kein linearer Prozess, deswegen wird es auch etwas sprunghaft zugehen. Es ist auch noch keine allgemeingültige Anleitung sondern eher ein Erfahrungsbericht, ein Blick hinter die Kulissen, Hilfe zur Selbsthilfe.

Am Schluss gib's natürlich alles noch als Kochrezept mit den notwendigen Dateien und Patches!

Buildroot

Ausgehend von benbrensons version ( http://code.google.com/p/gnublin-buildroot-git/ ) mit make ein Gnublin Linux bauen und testen. Damit es später keine Probleme mit den Pfaden gibt, am besten nicht das eigene Homeverzeichnis sondern /opt/gnublin/buildroot als Basisverzeichnis verwenden. Der weitere Sourcode für die extern zu bauenden Treiber und die Quellen für Compat-Wireless ( http://backports.wiki.kernel.org ) kommen dann nach opt/gnublin/src . Alle Patches und Pfadangaben beziehen sich auf dieses Layout.

Ist die Toolchain, der Kernel und das RootFS gebaut und getestet, kann / muss der Kernel passend konfiguriert werden. Bevor wir uns allerdings damit beschäftigen, erst noch ein paar Anmerkungen zum Kernel-Build-System.

Kernel

Seit Kernel 2.6 wird ein neues Konfigurationsschema verwendet das die verschiedenen Optionen verwaltet, die notwendig sind um eine flexibles und modulares Betriebssystem zu bauen. Auch der Bau von Treibern profitiert davon, da hiermit auch die Abhängigkeiten zwischen den einzelnen Komponenten und Module gesteuert wird. Prinzipiell gibt es zwei Arten Kernel-Module zu bauen, extern in einem eigenen Verzeichnis oder aber innerhalb des Kernelbaums. Beides hat vor und Nachteile. Da Backports auf verschiedene Kernelversionen angewandt werden, ist es sinnvoll die Quellen außerhalb des jeweiligen Kerns zu verwalten und nur über das Buildsystem zur Übersetzungszeit die Verknüpfung herzustellen.

Ein typisches Makefile für ein externes Module sieht in etwa folgendermaßen aus:

obj-m := ext_kernel_modul.o

KERNELDIR     := /opt/gnublin/buildroot/output/build/linux-2.6.33/
CROSS_COMPILE := /opt/gnublin/buildroot/output/host/usr/bin/arm-linux-
PWD           := $(shell pwd)
ARCH          := arm

all:
	$(MAKE) ARCH=$(ARCH) CROSS_COMPILE=$(CROSS_COMPILE) -C $(KERNELDIR) M=$(PWD) modules

clean:
	rm -rf *.o *~ core .depend .*.cmd *.ko *.mod.c .tmp_versions

und funktioniert auch für Ebedded-Systems problemlos, wenn man Toolchain und Kernelverzeichnis explizit angibt. Im Gegensatz zu vielen Hardwareherstellern haben sich die Maintainer des Compat-Wireless-Projekts daran gehalten und damit die besten Voraussetzungen für das Erstellen der notwendigen Module geschaffen. Der Wermutstropfen liegt nun darin, dass man die Abhängigkeiten, die uns das Kernelbuildsystem normalerweise auflöst, nun selbst bearbeiten muss.

Damit das mit dem Übersetzen grundsätzlich funktioniert, sind Ergänzungen im Makefile notwendig:

KLIB:=          "/opt/gnublin/buildroot/output/build/linux-2.6.33"
ARCH:=          "arm" 
CROSS_COMPILE:= "/opt/gnublin/buildroot/output/host/usr/bin/arm-linux-"

Ein 'make clean' führt dann zu einigen Warnungen bezüglich nicht gesetzter Build-Optionen und zu oben beschriebenen Problem, da diese nicht in der üblichen Weise in Kernel-Configuration explizit gesetzt werden können. Ein Blick in ein typisches Config-File zeigt das Dilemma, Optionen werden implizit bei der Auswahl einzelner Module angewählt, nur diese wollen wir ja unter Umständen in der neuen Version erst extern übersetzen oder benötigen sie gar nicht. Nach längerem experimentieren blieben drei Kandidaten übrig, die dann der entsprechenden Steuerdatei hinzugefügt wurden.

In Datei Kconfig in output/build/linux-2.6.33/arch/arm/mach-lpc313x/ am Ende folgende Ergänzungen vornehmen:

   ................
   config NET_SCHED
	bool "Gnublin Extra Flag NET_SCHED"
	help
	  Say Y here if you are using extra flags

   config WIRELESS_EXT
	bool "Gnublin Extra Flag WIRELESS_EXT & LIBIPW"
	help
	  Say Y here if you are using extra flags

   config GENERIC_ATOMIC64
	bool "Gnublin Extra Flag GENERIC_ATOMIC64"
	help
	  Say Y here if you are using extra flags
   ...............

Die neuen Module benötigen den Netzwerktreiber Scheduler, die Wireless Extensions ( für iwconfig und wpa-tools ) und Atomare 64Bit Operationen. Letztere werden uns nachher nochmals begegnen.

Im Menu sind dann die Flags zu setzen, wenn Treiber aus der Compat Bibliothek hinzugefügt werden sollen.

   SystemType ---> 
      Special settings  ---> 
	[*] Gnublin Extra Flag NET_SCHED                         
    	[*] Gnublin Extra Flag WIRELESS_EXT & LIBIPW                
    	[*] Gnublin Extra Flag GENERIC_ATOMIC64

Es gibt noch weitere Abhängigkeiten die im Laufe des Build-Prozesse auftreten, teilweise erst ganz zum Schluss wenn das Root-Filesystem gebaut wird, dazu später mehr. Damit verlassen wir fürs erste das Kernel-Build-System und wenden uns der Compat-Wireless zu.

Compat-Wireless

Als Erstes, download der stabilen Release von http://www.kernel.org/pub/linux/kernel/projects/backports/2012/10/08/ in meinem Fall compat-drivers-2012-10-08-c.tar.gz , die den Kernel bezüglich des Wireless-Subsystems auf den Level von 3.x anhebt. Wie oben schon angedeutet nach /opt/gnublin/src entpacken und das Makefile anpassen.

Ein erster Blick in das Quellverzeichnis zeigt zwei wichtige Ordner, compat und driver. Der Erstere ist für die Rückwärtskompatibilität zuständig, der Letztere enthält dann die aktuellen 3.x Kernel Treiber. Hier ist auch das Modul, das letztlich Anlass für den ganzen Aufwand war zu finden, der Treiber für die neuseten WLAN-Sticks mit dem Ralink RT5370 Chipsatz. Die notwendige Firmware hatte ich schon auf meinem Debian-Entwicklungssystem, firmware-ralink.deb aus dem Archive von http://backports.debian.org/debian-backports. Damit sind zumindest alle Zutaten vorhanden und das es prinzipiell funktioniert, habe ich in einer Debian6 VM mit x86 Architektur schon ausprobiert.

Jetzt wird es Zeit für einen ersten Versuch, im Buildroot-Verzeichnis, die Optionen setzen und Kernel neu kompilieren:


make linux-menuconfig
make

Das nächste Problem! Da der 80211 Layer gegen einen aus dem Backport ausgetauscht werden muss, muss dieses zwangsläufig als Modul übersetzt werden, nächste Runde:

NetworkingSupport ---> 
    Wireless ---> 
	<M>   cfg80211 - wireless configuration API  

Nächstes und auf den ersten Blick nicht triviales Problem, Syntaxfehler in lib/atomic64.c.Da dieses Problem in der Vorstudie auf der x86 Architektur nicht auftrat, muss hier das Problem auf der ARM Seite liegen!

//#include <asm/atomic.h>
#include <asm-generic/atomic64.h>

ARM Prozessoren kennen keine atomare 64Bit Operationen, deshalb muss auf eine Softwarelösung mit Spinlocks zurückgegriffen werden. Die Einbindung von arch/arm/... ist da noch unvollständig, die passende Include-Datei wird fürs erste von Hand eingebunden.

Das nächste 'make' führt dann zu einem fehlerfrei übersetzten und lauffähigen Kernel.

Wir verlassen das Buildroot-Verzeichnis und versuchen die compat drivers zu übersetzen. Damit auftauchende Probleme besser eingegrenzt werden können, beschränken wir uns auf die gesuchten WLAN-USB-Treiber.

scripts/driver-select rt2x00

Das Script wählt alle notwendigen Bestandteile aus und erzeugt eine passende Konfiguration für das nachfolgende make. Im Makefile für die compat drivers nun die oben beschriebenen Änderungen vornehmen:

#----------------------- GNUBLIN ------------------
KLIB_BUILD:=    /opt/gnublin/buildroot/output/build/linux-2.6.33
export KMODDIR?=       updates
KMODDIR_ARG:=   "INSTALL_MOD_DIR=$(KMODDIR)"
KMODPATH_ARG:=  "INSTALL_MOD_PATH=/opt/gnublin/buildroot/output/target"
export KLIB:=   /opt/gnublin/buildroot/output/build/linux-2.6.33
MAKE:= make ARCH=arm CROSS_COMPILE=/opt/gnublin/buildroot/output/host/usr/bin/arm-linux- 
#----------------------- GNUBLIN -----------------

Ein weitere Fehler in Bezug auf die Atomic-Operationen taucht auf! Das gleiche Spiel wie oben, in der Datei net/mac80211/mesh_pathtbl.c die notwendigen Ergänzungen einfügen.

#include <asm/atomic.h>

   static inline int atomic_add_unless(atomic_t *v, int a, int u) {
	return __atomic_add_unless(v, a, u);
 }

Immerhin jetzt läuft der Compiler durch, übrig bleiben drei Linker Warnings, crc_ccitt, cpufreq_cpu_get und cpufreq_cpu_put undefined! Die Ursache für die erste Warning ist ein noch fehlendes Kernel-Module, die letzten beiden sind modernen CPUs mit variabler Taktfrequenz geschuldet. Mit grep den Quelltext durchsucht und in compat/compat-3.1.c auskomentiert:

   .....
   /*
   unsigned int compat_cpufreq_quick_get_max(unsigned int cpu) 
   {
	struct cpufreq_policy *policy = cpufreq_cpu_get(cpu);
	unsigned int ret_freq = 0;

	if (policy) {
		ret_freq = policy->max;
		cpufreq_cpu_put(policy);
	}
	return ret_freq;
   }
   .....
EXPORT_SYMBOL(compat_cpufreq_quick_get_max);
*/	

Das Kernel-Module aktivieren:

Library routines  --->
   <M> CRC-CCITT functions  

Kernel und Treiber neu übersetzen. Wenn jetzt alles ohne Fehler durchgelaufen ist, ein mutiges 'make install-modules' und in /opt/gnublin/buildroot/output/target/lib/modules/2.6.33/updates/ stehen die neuen Treiber.

Hotplug

Wer nun glaubt das wäre es, der irrt! Nun gilt es die Treiber auf der Zielplatform auch zum laufen zu bringen und dazu benötigen wir, wie bei den meisten neueren WLAN Sticks und Karten, Firmware! Die gibt’s auf besagten http://backports.debian.org/debian-backports und die müssen nun ebenfalls wie die Treiber ins Target-Verzeichnis gespeichert werden. Wo genau hängt vom verwendeten Hotplug System ab! Wie Hotplug im Detail genau funktioniert steht in einem eigenen Artikel. Hier nur so viel, wie wir für die ersten Gehversuche benötigen.

Im 2.6 Kernel ist eine im Prinzip einfach zu handhabende Hotplug-Schnittstelle eingebaut. In /proc/sys/kernel/hotplug steht der Name eines Scriptes das bei einem Event aufgerufen wird, die notwendigen Informationen werden auf der Komandozeile und in Umgebungsvariablen übergeben. Standardmäßig lautet der Name /sbin/hotplug.

Der Kernel ruft wenn ein USB Gerät ein/abgesteckt wird /sbin/hotplug mit folgenden Argumenten auf:

argv [0] = hotplug_path
argv [1] = "usb"
argv [2] = 0
HOME=/
PATH=/sbin:/bin:/usr/sbin:/usr/bin
ACTION=action
PRODUCT=idVendor/idProduct/bcdDevice
TYPE=device_class/device_subclass/device_protocol
INTERFACE=class/subclass/protocol
DEVFS=/proc/bus/usb
DEVICE=/proc/bus/usb/bus_number/device_number

Zum Testen reicht uns fürs erste ein simples Script,

#! /bin/sh

env >> /dev/ttyS0

das alle Ausgaben auf die Gnublin Konsole umleitet. Damit es auch sicher vom Kernel aufgerufen wird, den Pfad im Proc-Filesystem abspeichern.

echo /sbin/hotplug > /proc/sys/kernel/hotplug


Nach Einstecken des WLAN-Sticks meldet uns das USB-Subsystem das neue Gerät:

usb 1-1.4: New USB device found, idVendor=148f, idProduct=5370
usb 1-1.4: New USB device strings: Mfr=1, Product=2, SerialNumber=3
usb 1-1.4: Product: 802.11 n WLAN
usb 1-1.4: Manufacturer: Ralink
usb 1-1.4: SerialNumber: 1.0

Ein 'lsmod' hingegen zeigt kein geladenes Modul und das ist auch korrekt so, denn fürs laden der Module ist der Userlandteil des Hotplug-Systems verantwortlich, es ist also fürs Erste Handarbeit angesagt. Unser Script gibt uns allerdings eine ganz Reihe von Informationen zurück:

DEVTYPE=usb_device
SUBSYSTEM=usb
DEVPATH=/devices/platform/lpc-ehci.0/usb1/1-1/1-1.4
DEVNUM=005
MINOR=4
ACTION=add
BUSNUM=001
MAJOR=189
DEVNAME=bus/usb/001/005
DEVICE=/proc/bus/usb/001/005
PRODUCT=148f/5370/101

Ein 'modprobe rt2800usb' lädt den Treiber nebst den notwendigen Modulen. Auf einem 8MB Board unbedingt swapspace aktivieren. Trotzdem ist der Ladevorgang wegen des geringen Speichers sehr holprig, daher möglichst kleinen und kompakten Kernel verwenden und nicht benötigte Services deaktivieren. 'lsmod' zeigt uns dann die geladenen Module.

Module                  Size  Used by    Not tainted
rt2800usb              12116  0 
rt2800lib              48139  1 rt2800usb
crc_ccitt               1031  1 rt2800lib
rt2x00usb               7095  1 rt2800usb
rt2x00lib              29602  3 rt2800usb,rt2800lib,rt2x00usb
mac80211              224997  3 rt2800lib,rt2x00usb,rt2x00lib
cfg80211              151534  2 rt2x00lib,mac80211
compat                 19410  4 rt2800usb,rt2x00lib,mac80211,cfg80211
led_class               2091  2 rt2x00lib,compat

Ein neues Gerät mit dem Namen wlan0 ist vorhanden, ein 'ifconfig wlan0 192.168.6.99' verlangt nach einem Firmware upload:

......
SUBSYSTEM=firmware
DEVPATH=/devices/platform/lpc-ehci.0/usb1/1-1/1-1.4/1-1.4:1.0/firmware/1-1.4:1.0
FIRMWARE=rt2870.bin
......

Wer ein sehr kompaktes System bauen will oder muss, kann sich mit dem Beispielscript aus der Kernel-Documentation behelfen (linux-2.6.33/Documentation/firmware-class/hotplug-script). Zuvor muss allerdings noch das Verzeichnis /lib/firmware angelegt und die rt2xxx.bin Dateien darin abgespeichert werden.

# Simple hotplug script sample:
# 
# Both $DEVPATH and $FIRMWARE are already provided in the environment.

HOTPLUG_FW_DIR=/lib/firmware/

echo 1 > /sys/$DEVPATH/loading
cat $HOTPLUG_FW_DIR/$FIRMWARE > /sys/$DEVPATH/data
echo 0 > /sys/$DEVPATH/loading

# To cancel the load in case of error:
#
#	echo -1 > /sys/$DEVPATH/loading
#

Das Tor zu einem unverschlüsselten WLAN steht uns nun offen. Für eine endgültige, vor allem automatische Lösung sollte man doch besser eines der beiden fertigen Userland-Hotplug-System verwenden. Ich habe mich wegen des geringen Speicherbedarfs und der Einfachheit für mdev entschieden und es in der Buildroot BusyBox Konfiguration aktiviert.

mdev

Automatisch ins WLAN.......

Wir benutzen mdev als Hotplug-Script und aktivieren das Hotplug im System-Startscript /etc/init.d/rcS :

#!/bin/sh

# Init hotplug interface 
echo /sbin/mdev > /proc/sys/kernel/hotplug

# Start all init scripts in /etc/init.d
# executing them in numerical order.
#
for i in /etc/init.d/S??* ;do
...........

Die Konfiguration befindet sich in der Datei /etc/mdev.conf:

$MODALIAS=.*    0:0 0660 @modprobe "$MODALIAS" 
wlan[0-9]*      0:0 0660 */etc/mdev.wlan

Die erste ruft 'modprobe' auf und lädt die notwendigen Module. Wenn alles gut geht und das USB-Gerät ein WLAN-Device ist, existiert das dazu passende Netzwerkinterface wlan0 und als Aktion wird das Script mdev.wlan ausgeführt:

#!/bin/sh
LOG="logger -p user.info -t mdev-wlan"
WARN="logger -p user.warn -t mdev-wlan"

case "$ACTION" in
        add | "" )
                if [ -s /etc/wpa_supplicant.conf ]; then
                        $LOG "trying to bring $MDEV up"
                        wpa_supplicant -B -Dwext -i $MDEV -c /etc/wpa_supplicant.conf
                        ifup $MDEV
                else
                        $WARN "/etc/wpa_supplicant.conf missing or empty, not trying to bring $MDEV up"
                fi
                ;;
 	remove )
		$LOG "trying to bring $MDEV down"
		ifdown $MDEV
                killall wpa_supplicant
		;;
esac       
          

Jetzt noch die Konfiguration fürs WLAN nach /etc/wpa_supplicant.conf speichern:

# home network; allow all valid ciphers
network={
    ssid="FLAN6"
    key_mgmt=NONE
#--------- WPA -----------------
#   key_mgmt=WPA-PSK
#   psk="very secret passphrase"

}

für 'ifup' noch das wlan0 aktivieren und in /etc/network/interfaces eintragen:

# cat /etc/network/interfaces 
# Configure Loopback
auto lo
iface lo inet loopback
iface wlan0 inet dhcp

USB-WLAN-Stick anschließen und der Rest sollte nun automatisch funktionieren:

usb 1-1.2: new high speed USB device using lpc-ehci and address 3
usb 1-1.2: New USB device found, idVendor=148f, idProduct=5370
usb 1-1.2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
usb 1-1.2: Product: 802.11 n WLAN
usb 1-1.2: Manufacturer: Ralink
usb 1-1.2: SerialNumber: 1.0
Compat-drivers backport release: compat-drivers-2012-10-08-c
Backport based on linux-next.git next-20121008
compat.git: linux-next.git
cfg80211: Calling CRDA to update world regulatory domain
usb 1-1.2: reset high speed USB device using lpc-ehci and address 3
Registered led device: rt2800usb-phy0::radio
Registered led device: rt2800usb-phy0::assoc
Registered led device: rt2800usb-phy0::quality
usbcore: registered new interface driver rt2800usb
rt2800usb 1-1.2:1.0: firmware: requesting rt2870.bin
wlan0: authenticate with 90:f6:52:c5:0c:58
wlan0: send auth to 90:f6:52:c5:0c:58 (try 1/3)
wlan0: authenticated
wlan0: associate with 90:f6:52:c5:0c:58 (try 1/3)
wlan0: RX AssocResp from 90:f6:52:c5:0c:58 (capab=0x421 status=0 aid=1)
wlan0: associated

# lsmod
Module                  Size  Used by    Not tainted
rt2800usb              12116  0 
rt2800lib              48147  1 rt2800usb
crc_ccitt               1031  1 rt2800lib
rt2x00usb               7103  1 rt2800usb
rt2x00lib              29634  3 rt2800usb,rt2800lib,rt2x00usb
mac80211              225585  3 rt2800lib,rt2x00usb,rt2x00lib
cfg80211              151782  2 rt2x00lib,mac80211
compat                 19454  4 rt2800usb,rt2x00lib,mac80211,cfg80211
led_class               2091  2 rt2x00lib,compat

#ifconfig
wlan0     Link encap:Ethernet  HWaddr 7C:DD:90:0B:B0:FB
          inet addr:192.168.6.100  Bcast:192.168.6.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:29 errors:0 dropped:0 overruns:0 frame:0
          TX packets:2 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:10332 (10.0 KiB)  TX bytes:696 (696.0 B)

Verbindung steht !

Das war's, viel Spass beim nachvollziehen.

Kochrezept Buildroot

Patches und mehr......

Alle Patches beziehen sich auf folgende Verzeichnisstruktur:

  /opt/gnublin/buildroot/....
  /opt/gnublin/src/compat-drivers-2012-10-08-c/....

und wurden in /opt/gnublin in der üblichen Weise mit 'diff -uNr original neu' erzeugt!

  500-arch-lpc313x-Kconfig.patch   
  501-lib-atomic64.patch           
  502-compat-net-mac80211.patch 
  503-compat-compat-3.1.patch 
  504-compat-makefile.patch 

Patches im Verzeichnis /opt/gnublin anwenden: 'patch -p0 < 50.....'

alternativ, in .../buildroot : 'patch -p1 < 50.....'

bzw. .../src/compat-drivers-2012-10-08-c : 'patch -p2 < 50.....'

Kochrezept Debian Gnublin

Das Ganze auf die aktuelle Debian-Distro anwenden.

Als Basis benötigt man das Debian-Gnublin-Build-System wie es im Artikel Die Gnublin Distribution beschrieben ist.

Am besten wieder außerhalb des Home-Verzeichnisses installieren, dazu compat-drivers-2012-10-08-c.tar.gz von http://www.kernel.org/pub/linux/kernel/projects/backports/2012/10/08/ und die notwendigen Patches.

  600-arch-lpc313x-Kconfig.patch   
  601-lib-atomic64.patch           
  602-compat-net-mac80211.patch 
  603-compat-compat-3.1.patch 
  604-compat-makefile.patch 

Mein Verzeichnisbaum sieht dann so aus:

filou@moave:/opt/debian/gnublin$ ls -l
insgesamt 40
-rw-r--r--  1 filou filou  623 10. Jan 19:22 600-arch-lpc313x-Kconfig.patch
-rw-r--r--  1 filou filou  373 10. Jan 19:23 601-lib-atomic64.patch
-rw-r--r--  1 filou filou  461 10. Jan 19:23 602-compat-net-mac80211.patch
-rw-r--r--  1 filou filou  475 10. Jan 19:23 603-compat-compat-3.1.patch
-rw-r--r--  1 filou filou 2461 10. Jan 19:26 604-compat-makefile.patch
drwxr-xr-x 34 filou filou 4096  6. Jan 17:36 busybox-1.20.2
drwxr-xr-x 15 filou filou 4096  5. Jan 19:18 compat-drivers-2012-10-08-c
drwxr-xr-x 14 filou filou 4096  5. Jan 19:01 lpc3131

Dann ins Kernel-Verzeichnis wechseln und die Patches anwenden:


cd /opt/debian/gnublin/lpc3131/kernel/linux-2.6.33-lpc313x
patch -p0 < /opt/debian/gnublin/600-arch-lpc313x-Kconfig.patch
patch -p0 < /opt/debian/gnublin/601-lib-atomic64.patch


Dito im Compat-Drirvers-Verzeichnis:


cd /opt/debian/gnublin/compat-drivers-2012-10-08-c
patch -p0 < /opt/debian/gnublin/602-compat-net-mac80211.patch
patch -p0 < /opt/debian/gnublin/603-compat-compat-3.1.patch
patch -p0 < /opt/debian/gnublin/604-compat-makefile.patch


Falls andere Pfade verwendet werden, das Makefile anpassen!!

Und weiter wie in Buildroot-Kernel oben, options und module setzen. Die Datei .stamp-kernel entfernen und Kernel mit make neu übersetzen. Weiter mit den Treibern im Verzeichnis /opt/debian/gnublin/compat-drivers-2012-10-08-c:


make clean
scripts/driver-select rt2x00
make


SD Karte an den PC anstecken und die notwendigen Änderungen vornehmen, dazu sind zeitweilig root-Rechte notwendig! Meine SD Karte wurde als Device sdc vom kernel erkannt, Bitte die Kommandos entsprechend anpassen!


su
mount -t ext2 /dev/sdc1 /mnt/gnublin
cd /opt/debian/gnublin/lpc3131/output
cp -a 2.6.33-g0642480* /mnt/gnublin/lib/modules
cp -a zImage /mnt/gnublin
cd /opt/debian/gnublin/compat-drivers-2012-10-08-c
make install-modules
chown -R root:root /mnt/gnublin/lib/modules
cp -a /lib/firmware/rt2* /mnt/gnublin/lib/firmware/
umount /dev/sdc1


Jetzt kann Gnublin von der modifizierten Karte gebootet werden. Wenn noch das Hotplug wie beim Buildroot-Kernel angepasst wird, funktioniert alles automatisch: USB-Gerät erkennen, Treiber laden, Firmware laden, anmelden am WLAN und IP-Adresse per DHCP holen:

Compat-drivers backport release: compat-drivers-2012-10-08-c
Backport based on linux-next.git next-20121008
compat.git: linux-next.git
cfg80211: Calling CRDA to update world regulatory domain
usb 1-1.2: reset high speed USB device using lpc-ehci and address 3
Registered led device: rt2800usb-phy0::radio
Registered led device: rt2800usb-phy0::assoc
Registered led device: rt2800usb-phy0::quality
usbcore: registered new interface driver rt2800usb
rt2800usb 1-1.2:1.0: firmware: requesting rt2870.bin
ADDRCONF(NETDEV_UP): wlan0: link is not ready
wlan0: authenticate with 90:f6:52:c5:0c:58
wlan0: send auth to 90:f6:52:c5:0c:58 (try 1/3)
wlan0: authenticated
wlan0: associate with 90:f6:52:c5:0c:58 (try 1/3)
wlan0: RX AssocResp from 90:f6:52:c5:0c:58 (capab=0x421 status=0 aid=1)
wlan0: associated
ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready

ON AIR

TODO

Kochrezept mdev

Was gibt's noch

Framebuffer TFT Displays

In anderen Sprachen