• AUTORE: Alexander E. Patrakov semzx@newmail.ru
• TRADUTTORE: Sandro Cardelli sacarde@tiscali.it
• DATA: 2003-12-03
• LICENZA: GNU GPL

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:

• eseguire il comando lspci e vedere se l'output è corretto. Io a casa

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)

• eseguire il comando pcimodules e vedere se il risultato ha un qualsiasi senso per il

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:

• inserire i moduli che corrispondono al proprio controller USB. Nel dubbio,

consultare l'output del comando pcimodules. Per esempio:

modprobe uhci

• montare il filesystem usb:

mount -t usbfs usbfs /proc/bus/usb

• eseguire il comando lsusb. Sul mio sistema l'output è:

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)

• eseguire il comando usbmodules per un dispositivo, per esempio:

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:

• [necessaria] Dopo la riga start|restart|status) aggiungere:

[ -d /var/run/usb ] || mkdir -m 700 /var/run/usb

• [necessaria] Rimuovere tutte le righe che fanno riferimento a /var/lock/subsys/hotplug -la directory /var/lock/subsys non è utilizzata in LFS.

• [estetica] Modificare tutte le righe dalla forma $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:

• Compilare “Support for hot-pluggable devices”
• Compilare il supporto per “Preliminary USB filesystem”. Nel mio kernel è compilato staticamente. E' stato riportato che la sua compilazione come modulo non funziona come aspettato. Sono troppo pigro per verificarlo.
  
• Non compilare mai il proprio dispositivo root e il filesystem come moduli.
• Non dimenticare che qualche volta ci sono due driver per lo stesso dispositivo. Compilare solo uno di loro, o segnare come blacklist tutti i moduli eccetto uno (vedere sotto).
  

5. Configurazione

• /etc/modules.conf

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.

• /etc/fstab

Aggiungere la seguente linea:

usbfs /proc/bus/usb usbfs defaults 0 0

: può non funzionare su vecchi computer senza USB.

• /etc/hotplug/blacklist

Aggiungere i nomi dei moduli che non si vuole caricare automaticamente. Dei buoni condidati sono:

1. driver duplicati (per esempio e100 vs eepro100)
2. driver instabili (per esempio scanner in linux-2.4.21, il mio scanner funziona bene solo con libusb; il problema scompare in 2.4.22)
3. framebuffer (per esempio rivafb) se si utilizza principalmente X
4. moduli spesso-malrilevati (per esempio i810_rng fornisce falsi positivi)

• Specifiche azioni per specifici hardware (conosciuto anche come quirks)

(è 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

• Aggiungere autoconfigurazione del server X
• Aggiungere qualcosa per le schede ISA PNP

CHANGELOG

2003-12-04: pubblicazione iniziale