Old:ACPI e DSDT: differenze tra le versioni

ACPI ('''Advanced Configuration and Power Interface''') � uno standard industriale aperto che definisce l'interfaccia tra S.O. e BIOS per l'amministrazione e la configurazione delle risorse di un PC. ACPI prevede che le informazioni a basso livello sul sistema (batteria, luminosit� LCD, pulsanti Fn, ecc.) siano contenute nella DSTD ('''Differentiated System Description Table''').  

Per questo motivo, per utilizzare appieno le possibilit� offerte da alcuni PC, soprattutto laptop, � necessario correggere la DSDT e istruire il kernel affinch� nel processo di boot carichi la tabella fornita da noi invece di quella fornita dal BIOS.

Per cominciare � indispensabile aggiornare il BIOS con l�ultima versione disponibile, sperando che la nuova versione contenga una tabella DSDT con meno errori della precedente :P.

Per poter utilizzare ACPI � necessario disporre di un kernel in cui sia stato abilitato il supporto ACPI. Praticamente tutte le distribuzioni forniscono kernel precompilati con il supporto ACPI attivato. Nel caso, per�, vi trovaste a dover (o voler) compilare autonomamente un kernel con il supporto ACPI, le voci necessarie sono le seguenti:

Per poter leggere e compilare una DSDT � necessario il compilatore ASL di Intel, che in debian esiste gi� precompilato a partire da etch (attuale testing), altrimenti � liberamente disponibile per il download all'indirizzo:

Per utilizzare la DSDT corretta sono disponibili due metodi: il primo prevede l'applicazione di una [ftp://ftp.kernel.org/pub/linux/kernel/people/lenb/acpi/patches/release/ patch per il kernel] e l'inserimento della nuova DSDT direttamente nel kernel, che quindi  sar� da ricompilare ogni volta che si fanno cambiamenti alla DSDT.  

Il secondo inserisce la nuova DSDT all'interno dell'initrd, e quindi non necessita la ricompilazione del kernel, a patto che nel vostro kernel sia stata inclusa una [http://gaugusch.at/kernel.shtml patch apposita]. Al momento la patch menzionata � inclusa nei kernel delle maggiori distribuzioni (sicuramente in Debian, Ubuntu, Suse, e Mandriva).  

Uno dei motivi per cui le DSDT sono spesso difettose � che vengono compilate con il compilatore fornito da Microsoft, invece che con quello fornito da Intel. Curiosamente i sistemi Microsoft riescono ad evitare gli errori commessi dal compilatore della stessa societ�, mentre, come si pu� immaginare, la stessa cosa non succede per Linux.

Per installare il compilatore Intel � sufficiente avere nel <tt>sources.list</tt> un repository per etch, e impartire, da root, il comando

Se invece avete scaricato i sorgenti, per avere il compilatore ASL funzionante � necessario compilarlo:

� possibile ottenere la DSDT attualmente installata per poi correggere gli eventuali errori e problemi, copiandola da un file reso appositamente disponibile dal filesystem virtuale /proc:

Ci� creer� un file '''dsdt.dat''' che contiene la DSDT compilata.  

Per poterne leggere il contenuto � necessario decompilarla con il compilatore ASL appena installato:

Verr� generato un file di testo denominato '''dsdt.dsl''', che contiene la DSDT. Questo file pu� essere modificato con un normale editor di testi e modificato a seconda delle esigenze e dei problemi riscontrati.  

Per vedere quali sono i problemi spesso � sufficiente ricompilare il file ottenuto: il compilatore ASL fornir� una serie di warning sulle ottimizzazioni che � possibile fare (e le far� automaticamente) ed, eventualmente, segnaler� degli errori, la cui soluzione pu� essere, ad esempio, ricercata su internet.

Ad ogni modo una lettura del codice della DSDT pu� essere istruttiva. Il linguaggio � abbastanza simile al C e con qualche minima conoscenza � possibile comprendere i principali costrutti logici.

Nel codice di alcune DSDT � stato trovato un controllo (if .. then) sulla lunghezza del nome del S.O. soprastante (17 lettere, proprio come "Microsoft Windows") come requisito per l'attivazione di alcune funzioni dell'ACPI.

{{ Warningbox | � possibile scaricare una custom DSDT gi� pronta e corretta da internet per molti portatili in commercio: http://acpi.sourceforge.net/dsdt/tables }}

in sostanza, c'� un errore ripetuto identico tre volte (<tt>Error 1048</tt>), oltre ad un warning. Andiamo a vedere le sezioni incriminate. La prima �:

La funzione <tt>Store</tt> � una funzione di assegnazione verso destra: alla variabile a destra viene assegnato il valore (o il valore della variabile) che si trova a sinistra.  

In questo caso, per�, � evidente che questa assegnazione � del tutto inutile, perch� viene assegnato alla variabile <tt>Local0</tt> il valore che ha gi�, quindi per correggere l'errore non faccio altro che cancellare l'istruzione commentandola:

Facendo questa correzione anche nelle altre posizioni segnalate vengono eliminati tutti gli errori, quindi passiamo al warning. Il codice � questo:

Le ultime righe mi danno la prova che l'errore ha a che fare con le porte USB, come avevo gi� notato.  

Cercando in rete scopro che il metodo <tt>\_WAK</tt>, che � una funzione utilizzata al risveglio da uno stato di risparmio energetico (o di spegnimento), deve restituire un valore, che indichi se l'operazione di risveglio � riuscita o meno.

Una possibile diagnosi del mio problema, a questo punto, � che in certi casi durante il boot viene richiamato questo metodo, e il sistema si blocca in attesa di un risultato, che per� non viene mai restituito. (N.d.A.: la diagnosi � evidentemente sbagliata, perch� il problema persiste :()

Io non ho idea di come reperire, nel codice, l'informazione sull'esito dell'inizializzazione delle porte USB, quindi non mi � possibile correggere il codice in modo che assolva alla funzione per cui � stato scritto, ma posso usare un workaround, e fare in modo che restituisca comunque un esito positivo.  

Per fare questo si trova (in rete), senza entrare nei dettagli, che � sufficiente aggiungere alla fine del metodo, subito prima dell'ultima parentesi graffa, la riga

Ora per� mi viene una curiosit�, e mi metto a cercare nel codice la scritta "Microsoft". Questo � quello che ne viene fuori:

Anche senza conoscere il linguaggio, il codice � facilmente interpretabile: "se il Sistema Operativo si chiama 'Microsoft Windows' assegna il valore (esadecimale) <tt>0x56</tt> alla variabile <tt>SMIP</tt>, se invece si chiama 'Microsoft Windows NT' assegna <tt>0x58</tt> alla variabile <tt>SMIP</tt> e zero alle variabili <tt>OSFX</tt> e <tt>OSFL</tt>; se il S.O. � diverso da quelli elencati assegna alle tre variabili, rispettivamente, <tt>0x57</tt>, <tt>0x02</tt> e <tt>0x02</tt>".

Per qualche motivo a me ignoto chi ha impostato questa DSDT ha fatto in modo di cambiare le funzionalit� del sottosistema ACPI a seconda del S.O. che si usa. Poich� questo non mi rende particolarmente felice, ho modificato il codice in questo modo, eliminando di fatto il controllo:

Aggiornamento: ricontrollando il codice ho notato che le tre variabili <tt>SMIP</tt>, <tt>OSFX</tt> e <tt>OSFL</tt> vengono inizializzate altrove, e quindi, in sostanza, il presente codice � inutile (se non dannoso ;-)), quindi l'ho semplicemente eliminato.

Purtroppo la correzione <b>vera</b> di questi errori � al di l� delle nostre possibilit�, perch� richiede, oltre alla conoscenza del linguaggio di programmazione, una conoscenza approfondita di come si comporta il nostro hardware, e nella grande maggioranza dei casi queste informazioni sono tenute segrete.

Come abbiamo gi� detto, � possibile inserire la tabella DSDT generata in modo statico nel kernel, oppure renderla disponibili tramite initrd.

Il metodo initrd � probabilmente preferibile, particolarmente se dovete fare diversi cambiamenti alla vostra DSDT, perch� non richiede la ricompilazione del kernel per ogni nuova DSDT generata.

� necessario applicare una patch al kernel per far s� che sia in grado di leggere la nuova DSDT.  

Se non appaiono errori, significa che la patch � stata applicata correttamente.

Infine ricompiliamo il kernel. Se non ci sono errori al prossimo avvio del PC il supporto ACPI � caricato correttamente senza alcun problema.

Se usate un kernel standard Debian non � necessario ricompilare il kernel: � sufficiente posizionare la tabella DSDT nel posto giusto e ricreare l'initrd o l'initramfs.  

Per fare questo dovete prima verificare se il vostro kernel usa l'initrd o l'initramfs: i kernel Debian standard usano l'initramfs a partire dalla versione 2.6.14 compresa.

# cp dsdt.asl /etc/mkinitrd/DSDT

# mkinitrd -o initrd-<versione> <versione>  

in cui <tt><versione</tt> � il nome della directory che contiene i moduli, e che trovate in <tt>/lib/modules/</tt>.

# cp dsdt.asl /etc/mkinitrd/DSDT.asl

# mkinitrd -o initrd-<versione> <versione>  

Se il vostro kernel non comprende la patch che gli permette di leggere la DSDT nell'initrd, dovete ricompilarlo. Prima per� applicate la patch, spostandovi nella directory dove sono presenti i sorgenti:

Prima di compilare � necessario assicurarsi che i seguenti moduli (ramdisk and initrd ) siano compilati staticamente nel kernel:

Inoltre � necessario controllare che l�opzione '''Read DSDT from initrd''' sia selezionata nel menu delle opzioni ACPI:

Se queste opzioni non sono abilitate, abilitarle e ricompilare il kernel. Se sono gi� abilitate non � necessario ricompilare il kernel ;-).  

Ora il kernel � pronto ad accettare la DSDT con initrd.  

Se non avete a disposizione i tool mkinitrd e/o mkinitramfs che Debian mette a disposizione � necessario modificare l'initrd che avete, ma prima di farlo � fortemente consigliato di farne una copia di backup: