====== Hardware Detection ====== * **AUTORE**: Alexander E. Patrakov * **TRADUTTORE**: Sandro Cardelli * **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 FIXME: 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: - driver duplicati (per esempio e100 vs eepro100) - 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) - framebuffer (per esempio rivafb) se si utilizza principalmente X - 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