Old:ACPI e DSDT: differenze tra le versioni

Old:ACPI e DSDT (visualizza wikitesto)

Versione delle 00:26, 4 gen 2010

Nessun cambiamento nella dimensione , 4 gen 2010

m

nessun oggetto della modifica

S3v

6 999

contributi

@@ Riga 1: / Riga 1: @@
 ==Introduzione==
-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''').
+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 DSDT ('''Differentiated System Description Table''').
 Il problema principale del supporto ad ACPI in linux risiede nella nella presenza di errori (ma anche di controlli espliciti su alcune caratteristiche peculiari del S.O. soprastante) nella tabella DSDT: purtroppo, molti fornitori di hardware non sono in grado, o non vogliono fornire tabelle DSDT completamente funzionali secondo gli standard ACPI.
@@ Riga 117: / Riga 117: @@
 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:
+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:
 <pre>
 Scope (\_SI)
@@ Riga 162: / Riga 162: @@
 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 :()
+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.
@@ Riga 170: / Riga 170: @@
 Return(Package(0x02){0x00, 0x00})
 </pre>
-Dopo le correzioni il codice viene ricompilato senza errori ne' warning :D
+Dopo le correzioni il codice viene ricompilato senza errori né warning :D
 Ora però mi viene una curiosità, e mi metto a cercare nel codice la scritta "Microsoft". Questo è quello che ne viene fuori:
@@ Riga 198: / Riga 198: @@
 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:
+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:
 <pre>
 Method (\_SB.PCI0._INI, 0, NotSerialized)
@@ Riga 230: / Riga 230: @@
 Vorrei far notare che le correzioni che sono state fatte <b>non sono</b> delle <b>vere</b> correzioni, ma dei workaround: non ci si assicura che il codice faccia quel che deve fare, ma solo che non ci siano errori formali.
-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.
+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.
 ==Aggiornare il Kernel==