SOMMARIO
Rilevamento Automatico di Hardware PCI e USB in LFS
DESCRIZIONE:
A volte non si conosce esattamente che tipo di hardware si ha e non
si desidera immaginare il modulo corretto. Adesso non occorre più essere indovini.
In questo hint vine descritto il software necessario per il riconoscimento
automatico dell'hardware al momento dell'avvio.
PREREQUISITI
Questo hint funziona su LFS >=4.0, con o senza devfs, con
kernel 2.4 o 2.6.
HINT
Allo stato attuale, gli utenti LFS devono o compilare tutti i driver relativi ai dispositivi
nel kernel in modo statico o scrivere delle righe magiche in /etc/modules.conf.
Con il secondo modo, è necessario conoscere esattamente quale hardware si abbia. Questa
informazione non è sempre disponibile per i notebook e dispositivi “assemblati”.
Fortunatamente, la maggior parte dell'hardware può essere auto-riconosciuto all'avvio. Uno
svantaggio di questa soluzione è che non funziona con tutte le schede ISA.
Un'altro svantaggio è il prolungamento di due-secondi del processo di avvio. Il terzo
svantaggio è che quei moduli per l'hardware non utilizzato spesso, sono
caricati all'avvio, e non al primo utilizzo come nel caso alternativo
utilizzando modules.conf.
AVVERTIMENTO IMPORTANTE
E' stato riportato che seguendo questo hint si hanno, da quanto risulta, tonnellate di
(possibili falsi) messaggi circa sovratensione da moduli USB su alcuni
computer. Non sono responsabile per qualsiasi danneggiamento hardware.
Se si ricevono o no questi messaggi, prego inviare per e-mail all'autore l'output dei
comandi lspci e lsusb così che egli possa formulare l'esatte condizioni
che conducono a questi messaggi nelle future versioni di questo hint.
SI E' LETTO L'AVVERTIMENTO IMPORTANTE SOPRA?
Per far sì che il proprio computer rilevi automaticamente l'hardware
installare il seguente software:
1. pciutils
Le istruzioni sono nel libro BLFS. Occorrerà la patch con nome
pciutils-2.1.11-pcimodules-1.patch dal progetto patch dal momento che si
utilizzerà il comando pcimodules.
Questo comando dovrebbe mostrare la lista dei moduli necessari per supportare le proprie
schede PCI, basato sui contenuti del file /lib/modules/`uname -r`/modules.pcimap.
Testare l'installazione di pciutils:
ottengo quanto segue:
00:00.0 Host bridge: VIA Technologies, Inc. VT82C693A/694x [Apollo RO133x](rev c4) 00:01.0 PCI bridge: VIA Technologies, Inc. VT82C598/694x [Apollo MVP3/Pro133x AGP] 00:07.0 ISA bridge: VIA Technologies, Inc. VT82C686 [Apollo Super South] (rev 40) 00:07.1 IDE interface: VIA Technologies, Inc. VT82C586/B/686A/B PIPC Bus Master IDE (rev 06) 00:07.2 USB Controller: VIA Technologies, Inc. USB (rev 1a) 00:07.4 SMBus: VIA Technologies, Inc. VT82C686 [Apollo Super ACPI] (rev 40) 00:0b.0 Communication controller: Lucent Microelectronics LT WinModem (rev 02) 00:0d.0 Multimedia audio controller: Fortemedia, Inc Xwave QS3000A [FM801](rev b2) 00:0d.1 Input device controller: Fortemedia, Inc Xwave QS3000A [FM801 game port](rev b2) 01:00.0 VGA compatible controller: nVidia Corporation NV11 [GeForce2 MX](rev b2)
kernel in esecuzione.
Io ho l'output seguente:
rivafb snd-fm801 usb-uhci uhci parport_pc
Se si vuole che il file pci.ids sia in /usr/share/misc piuttosto che in
/usr/share, utilizzare la patch di nome pciutils-2.1.11-sharedir-1.patch
2. [opzionale] usbutils
Questo pacchetto contiene i comandi lsusb e usbmodules. Questi sono gli
equivalenti per USB dei comandi lspci e pcimodules di pciutils. Il
pacchetto non è, rigorosamente parlando, necessario perché lo script
hotplug analizza i file di /proc/bus/usb/*/* e rileva i dispositivi USB
anche senza usbutils. Così funziona per me. Ma gli autori del
pacchetto hotplug scrivono che il processo sarà più affidabile con usbutils.
Sito di download:
http://wwwbode.cs.tum.edu/Par/arch/usb/download/usbutils/usbutils-0.11.tar.gz
Istruzioni di installazione:
./configure --prefix=/usr make make install rm /usr/lib/libusb.* rm /usr/include/libusb.h
Spiegazione degli ultimi due comandi: le librerie libusb installate dal
pacchetto usbutils non sono utilizzate. Il codice di rilievo è linkato staticamente nei
programmi lsusb e usbmodules. Una versione più nuova incompatibile di libusb è
disponibile separatamente e fornisce file /usr/lib/libusb-0.1.* e
/usr/include/usb.h. Altre applicazioni come SANE utilizzano la versione più nuova.
Se si vuole che il file usb.ids sia in /usr/share/misc invece che in
/usr/share, aggiungere il parametro –datadir=/usr/share/misc al comando ./configure.
Adesso testare il pacchetto:
consultare l'output del comando pcimodules. Per esempio:
modprobe uhci
mount -t usbfs usbfs /proc/bus/usb
Unknown line at line 1809 Duplicate HUT Usage Spec at line 2650 Bus 001 Device 001: ID 0000:0000 Virtual Hub Bus 001 Device 002: ID 05d8:4002 Ultima Electronics Corp. Lifetec LT9385 Scanner
(in realtà è un Mustek 1200 UB plus)
usbmodules --device /proc/bus/usb/001/002
L'output sul mio computer è:
scanner
Notare che il file usb.ids distribuito con il pacchetto usbutils è vecchio
e incompleto. Questo non è un problema, perché il comando usbmodules
utilizza un'altro file, /lib/modules/`uname -r`/modules.usbmap per far
corrispondere i dispositivi con i nomi dei moduli.
3. hotplug
Download:
http://www.kernel.org/pub/linux/utils/kernel/hotplug/hotplug-2003_08_05.tar.bz2
Gli script in questo pacchetto reagiscono agli eventi hotplug inviati dal
kernel, e anche agli eventi sintetici “coldplug” al momento dell'avvio.
Essi utilizzano programmi da pciutils e usbutils per caricare il modulo
corretto ed eseguire azioni specifiche.
Gli script contenuti nel pacchetto hotplug devono essere modificati un pò per
conformarli agli standard LFS. Eseguire le seguenti modifiche su etc/rc.d/init.d/hotplug:
start|restart|status)
aggiungere:[ -d /var/run/usb ] || mkdir -m 700 /var/run/usb
$RC $1
o $RC start
in:HW=`basename $RC .rc | tr [:lower:] [:upper:]` echo "Detecting $HW hardware..." $RC $1 (or $1 start) report_status success
Fare modifiche simili alle righe dalla forma $RS stop
:
HW=`basename $RC .rc | tr [:lower:] [:upper:]` echo "Stopping $HW hardware support..." $RC stop report_status success
Adesso copiare tutti gli script contenuti nel pacchetto hotplug nelle
loro posizioni finali ed eseguire chown a root:root. Fare i seguenti symlink:
ln -s ../init.d/hotplug /etc/rc.d/rc3.d/S15hotplug ln -s ../init.d/hotplug /etc/rc.d/rc4.d/S15hotplug ln -s ../init.d/hotplug /etc/rc.d/rc5.d/S15hotplug
4. Linux kernel
Compilare un kernel che supporti tutto l'hardware sui computer prescelti,
con molti moduli. Compilare anche ALSA, DRI e qualsiasi altro pacchetto
che contenga moduli. Non dimenticare i seguenti punti:
5. Configurazione
Decommentare tutte le righe dalla forma “alias eth0 8139too” che specificano il driver esplicitamente. I moduli saranno caricati dallo script hotplug. Notare che l'ordine delle periferiche ethernet può cambiare se sono di diverso tipo.
Aggiungere la seguente linea:
usbfs /proc/bus/usb usbfs defaults 0 0
: può non funzionare su vecchi computer senza USB.
Aggiungere i nomi dei moduli che non si vuole caricare automaticamente. Dei buoni condidati sono:
(è una fortuna non averne bisogno)
Se si deve fare qualcosa di particolare con il proprio hardware USB, creare uno script
in /etc/hotplug/usb. Per esempio, prima che uno scanner terminale fosse ben supportato
dal modulo scanner del kernel, ho dovuto modificare i permessi sullo pseudofile
in /proc/bus/usb corrispondente al mio Mustek 1200 UB Plus scanner, così che ci
potessi lavorare come utente normale, non come root. Questo script accetta il nome dello
pseudofile nella variabile d'ambiente DEVICE. La documentazione completa
che concerne le altre variabili è all'inizio di /etc/hotplug/usb.agent.
Così ho scritto:
cat >/etc/hotplug/usb/mustek1200ubplus <<"EOF" #!/bin/sh chmod 666 $DEVICE EOF chmod 755 /etc/hotplug/usb/mustek1200ubplus
Quindi aggiunto una riga a /etc/hotplug/usb.usermap, come descritto nel commento all'inizio del file. Ho aggiunto il seguente (scusate l'estetica):
mustek1200ubplus 0x0003 0x05d8 0x4002 0x0000 0x0000 0x00 0x00 0x00 0x00 0x00 0x00 0x00000000
I campi idVendor e idProduct (0x05d8 e 0x4002) possono essere recuperati
dall'output di lsusb. Il primo campo è un OR logico dei seguenti flag:
USB_MATCH_VENDOR=0x0001 USB_MATCH_PRODUCT=0x0002 USB_MATCH_DEV_LO=0x0004 USB_MATCH_DEV_HI=0x0008 USB_MATCH_DEV_CLASS=0x0010 USB_MATCH_DEV_SUBCLASS=0x0020 USB_MATCH_DEV_PROTOCOL=0x0040 USB_MATCH_INT_CLASS=0x0080 USB_MATCH_INT_SUBCLASS=0x0100 USB_MATCH_INT_PROTOCOL=0x0200
Così la mia riga fondamentalmente dice “Controllare gli ID del rivenditore
e del prodotto e ignorare qualsiasi altra cosa. Se questi sono uguali a
0x05d8 e 0x4002, eseguire lo script mustek1200ubplus”.
Di certo, adesso non c'è questa riga perché linux-2.4.22 supporta bene
questo scanner senza libusb.
Apparentemente c'è un pò di supporto per tali azioni specifiche (per esempio il caricamento
del firmware) per hardware PCI. Vedere all'inizio di /etc/hotplug/pci.agent.
Non posso dire altro perché non ho avuto bisogno di ulteriori azioni.
6. Testing
Riavviare e vedere se tutti i moduli necessari sono caricati dallo script hotplug.
7. Problemi
Nel mio caso il WinModem LT rimane non rilevato. E' stato risolto
aggiungendo una riga per quel modem in /etc/modules.conf:
alias /dev/tts/LT0 lt_serial
Un approccio diverso consiste nel creare uno script chiamato /etc/hotplug/hidden.rc che
esegue un comando modprobe per ciascun modulo non rilevabile. Oppure è
possibile editare /lib/modules/`uname -r`/modules.pcimap.
Editare manualmente /lib/modules/`uname -r`/modules.pcimap è anche uno dei
metodi per gestire i mal-rilevamenti quando viene caricato il modulo errato
(l'altro metodo consiste nell'inserire in una blacklist il modulo errato).
8. Da fare
CHANGELOG
2003-12-04: pubblicazione iniziale