[info] DSDT A PEZZI

[scrax]

Per cercare di fare chiarezza sul dsdt e capire meglio come funziona ho provato a fare a pezzi un dsdt minimo che mi funziona senza problemi con la mia configurazione.

Vorrei con il contributo di tutti riempire questo primo topic con più informazioni possibili riguardo alle varie parti che lo compongono in modo da capirne meglio il funzionamento.

Se postate delle spiegazioni più esaurienti di quelle che finora ho messo le integrerò in questo topic per renderlo più completo possibile.

 

INTRODUZIONE (dal wiki di www.debianizzati.org)

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 (n.d.t. vale anche per Osx) risiede 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.

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.

 

Aggiornamento del BIOS

Per cominciare è indispensabile(nota: con OsX non è sempre vero talvolta un bios più vecchio da meno problemi) aggiornare il BIOS con l’ultima versione disponibile, sperando che la nuova versione contenga una tabella DSDT con meno errori della precedente .

 

Strumenti per lavorare con le DSDT

Per poter leggere e compilare una DSDT è necessario il compilatore ASL di Intel, per OsX esiste già precompilato nell'app IaslMe da mitch_de in questo topic.

Per utilizzare la DSDT corretta sono disponibili due metodi:

1. il primo prevede l'applicazione di un bios moddato con l'inserimento della nuova DSDT, che quindi sarà da modificare e riflashare ogni volta che si fanno cambiamenti alla DSDT. Inoltre potrebbe portare a dei problemi con altri sistemi operativi se troppo differente dall'originale;
   
2. il secondo inserisce la nuova DSDT all'avvio utilizzando un bootloader in grado di sovrascrivere la tabella passata al S.O. Non necessita la modifica del BIOS. Chameleon è uno dei bootloader in grado di fare ciò.
   

Ottenere una DSDT

È possibile ottenere la DSDT attualmente installata per poi correggere gli eventuali errori e problemi.

Da Osx usando DSDTSE.app una volta aperto cliccare sul bottone "Get DSDT" e salvare il file .dsl che si ottiene.

Da Linux copiandola da un file reso appositamente disponibile dal filesystem virtuale /proc:

# cat /proc/acpi/dsdt > dsdt.dat

Ciò creerà un file dsdt.dat che contiene la DSDT compilata. Per poterne leggere il contenuto è necessario decompilarla con il compilatore ASL appena installato:

$ iasl -d dsdt.dat

Verrà generato un file di testo denominato dsdt.dsl, che contiene la DSDT.

Questo file può essere aperto 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 in DSDTSE o 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.

Una volta corretti gli errori ricompilare il file dsdt.dsl (trascinandolo sull'icona di IaslMe).

 

È possibile scaricare una custom DSDT già pronta e corretta da Internet per molti portatili in commercio: http://acpi.sourceforge.net/dsdt/tables

se la usate segnalate nel topic le vostre esperienze.

 

Inoltre è utile per chi vuole avvicinarsi il più possibile allo ioreg di un mac qui c'è quello del MacPro3,1 (segnalato da RASONE topic #67)

 

Piccole note sul significato del codice:

// - Servono per definire l'inizio di una linea di commento. Tutto ciò che viene scritto dopo non viene usato nella compilazione la fine del commento corrisponde con la fine della linea

/* - Inizio paragrafo di commenti. Servono per definire l'inizio un commento di più righe

*/ - Fine paragrafo commenti. Serve a determinare la fine di un paragrafo commentato.

{} - Definiscono l'inizio e la fine dei vari blocchi del dsdt.

 

Esempio di analisi del codice DSDT (topic #34)

 

PER NEOFITI

Questo topic è indirizzato a utenti con una certa dimestichezza nell'editing del DSDT, se volete iniziare a capire meglio di cosa si parla potete provare iniziando da queste guide di base, per neofiti, per concessione dell' EvOSX86 Team, tradotte in Italiano by thefoul:

 

- Modifica DSDT - 1a parte - Le Basi

- Modifica del DSDT - 2a parte - TM fix

- Modifica del DSDT - 3a parte - aggiunta di codice per le schede video

-Modifica del DSDT - 4a parte - speedstep nativo mediante DSDT

 

 

DSDT MINIMO per P5KR valido anche su P5K e P5KC con crossflash BIOS a P5KR

(se lo testate senza crossflash postate i risultati)

Scope (_PR)

Parte del dsdt che imposta i vari valori per il funzionamento della CPU. Da modificar con i propri p-state o kernel panic

// qui verranno definiti i parametri dei core (comuni per tutti)
Scope (_PR) {	 
// Modificare in base ai propri p-state (0x03 è il numero in esadecimale dei p-state impostati
// ad es. con 11 p-state ci vuole 0x0B)
	Name (PSS, Package (0x03){	
// p-state 0 (max freq)
		Package (0x06){Zero,Zero,0x0A,0x0A,0x082A,Zero},	 
// p-state 1 (unico valore da modificare è 0724)
		Package (0x06){Zero,Zero,0x0A,0x0A,0x0724,One},	 
// p-state 2 (061D sono i valori di Fid e Vid per questo p-state) 
		Package (0x06){Zero,Zero,0x0A,0x0A,0x061D,0x02}	 
	})
//rimosso per snellire il codice in quanto sembra sene occupi AppleLPC.kext di questo
	//Name (PSD, Package (0x05){0x05,Zero,Zero,0xFC,0x04})	 
	Name (CST, Package (0x04){0x03, 
		Package (0x04){ResourceTemplate (){Register (FFixedHW,0x01,0x02,0x0000000000000000,,)},One,One,0x03E8}, 
		Package (0x04){ResourceTemplate (){Register (SystemIO,0x08,0x00,0x0000000000000814,,)},0x02,One,0x01F4}, 
		Package (0x04){ResourceTemplate (){Register (SystemIO,0x08,0x00,0x0000000000000815,,)},0x03,0x55,0xFA}
	})
	Processor (CPU1, 0x01, 0x00000810, 0x06){
// alias per non riscrivere i valori dei p-state per il primo core
		Alias (PSS, _PSS)	  
//rimosso l'alias che riprendeva i valori di _PSD 
		//Alias (PSD, _PSD)	
		Alias (CST, _CST)
	}
	Processor (CPU2, 0x02, 0x00000810, 0x06){
// alias per non riscrivere i valori dei p-state per il secondo core
		Alias (PSS, _PSS)	   
//rimosso l'alias che riprendeva i valori di _PSD
		//Alias (PSD, _PSD)
		Alias (CST, _CST)
	}
/* Parte necessaria solo per i quadcore (cancellare questa linea per decommentare la parte)
	Processor (CPU3, 0x03, 0x00000810, 0x06){
// alias per non riscrivere i valori dei p-state per il terzo core
		Alias (PSS, _PSS)	   
//rimosso l'alias che riprendeva i valori di _PSD
		//Alias (PSD, _PSD)
		Alias (CST, _CST)
	}
	Processor (CPU4, 0x04, 0x00000810, 0x06){
// alias per non riscrivere i valori dei p-state per il quarto core
		Alias (PSS, _PSS)	   
//rimosso l'alias che riprendeva i valori di _PSD
		//Alias (PSD, _PSD)
		Alias (CST, _CST)
	}
linea da cancellare se si ha un quad core */ 
}

 

Operation Region BIOS

Parte di impostazioni legate al BIOS, senza non va lo stop, spegnimento ecc.

	OperationRegion (BIOS, SystemMemory, 0xCFF8E064, 0x2D)
Field (BIOS, ByteAcc, NoLock, Preserve){SLPS,   8, Offset (0x0B), ASSB,   8}

 

Scope (_SB)

Definisce i Device (da vedere in dettaglio nel post #5.)

Scope (_SB){
	TUTTA LA PARTE DEI DEVICE STA QUI VEDI POST N°5
}

 

Method (_PTS)

Legato al OperationRegion BIOS iniziale serve per lo stop

	Method (_PTS, 1, NotSerialized) {
		\_SB.PCI0.LPCB.SPTS () Store (Arg0, ASSB)} }

 

Method (_WAK)

Serve per il risveglio dei device

Method (_WAK, 1, NotSerialized){
		Return (Package (0x02){Zero,Zero})}

 

Parte legata ai vari state S1-S3 ecc.

	Name (_S0, Package (0x04){Zero,Zero,Zero,Zero})
Name (_S1, Package (0x04){One,Zero,Zero,Zero})
Name (_S3, Package (0x04){0x05,Zero,Zero,Zero})
Name (_S4, Package (0x04){0x06,Zero,Zero,Zero})
Name (_S5, Package (0x04){0x07,Zero,Zero,Zero})

 

Method (MDCP)

Per iniettare codici nel dsdt

	Method (MCDP, 2, NotSerialized){
	If (LEqual (Arg0, Zero)){Store (Buffer (One){0x03}, Arg1)}}

 

Method (MCID)

Per iniettare id device se non si usano le EFI string

	Name (IDB0, Buffer (0x04){0x00, 0x00, 0x00, 0x00})
Name (IDB1, Buffer (0x04){0x00, 0x00, 0x00, 0x00})
Method (MCID, 2, NotSerialized){
	If (Arg1){
		Store (And (Arg1, 0xFF), Index (IDB0, Zero))
		Store (ShiftRight (And (Arg1, 0xFF00), 0x08), Index (IDB0, 
			One))
		If (LEqual (And (Arg1, 0xFFFF0000), Zero)){Store (Package (0x02){"device-id",IDB0}, Local0)}
		Else{ShiftRight (Arg1, 0x10, Arg1)
			Store (And (Arg1, 0xFF), Index (IDB1, Zero))
			Store (ShiftRight (And (Arg1, 0xFF00), 0x08), Index (IDB1,One))
			Store (Package (0x04){"vendor-id",IDB0,"device-id",IDB1}, Local0)
		}MCDP (Arg0, RefOf (Local0))Return (Local0)
	}
	Return (Zero)
}

[Giorgio_multi]

Aprofitto del Topic per chiedere, a chi eventualmente sa la risposta: perchè da quando ho eliminato DSDT.aml dai miei PC (8 su 11), funziona tutto perfettamente (con Snow), sleep, stop etc. Inoltre in 2 sistemi ho risolto il problema dello Stop eliminandolo.

 

In particolare su P5K-SE/EPU, Conroe 1333-d667 G31M-GS P5N-SE SLI P5LD2-SE P5KPL-VM.

 

Ovviamente audio in e out OK, QE/CI OpenCL OK, Lan OK Time machine OK, etc.

 

Specifico che la domanda non è provocatoria e rispetto il lavoro di chi si applica sul DSDT, ma solamente a scopo conoscitivo.

 

Il DSDT lo uso solo in 3 sistemi (AMD) e sul laptop Acer 6930G senza il quale il BIOS si resetta.

 

Giorgio

[jfk11]

Aprofitto del Topic per chiedere...

 

Mi accodo anche io per sviluppare un ragionamento più in senso pratico,ovvero: avere un DSDT corretto,e per corretto indendo che passato al DSDTSE o IASL non dà errori, significa che nell'installazione di SL e/o versioni ultime di Leopard (iDeneb 1.6) non avrà grossi problemi?

 

Nei due casi che ho in firma, posso dire che per Ideneb ho faticato NON poco a trovare i giusti parametri di installazione e cmq non ho mai avuto cartella Extra e adesso che, per studio, ho controllato il mio DSDT, ho rilevato degli errori che evidentemente non erano così gravi da influire sull'installazione quindi, a questo punto, il mio obbiettivo è di far funzionare la scheda di rete che sembra non ci sia verso di avviare con i Kext suggeriti e provati.

 

Per quanto riguarda SL dove, invece, l'installazione di BarboneNet prevede un DSDT.aml, esso (logicamente) è risultato esente da errori, però a mio modesto avviso il fatto di aver utilizzato un Harware "dedicato" e l'inserimento di maggiori driver (Kext) in SL retail, hanno giocato un ruolo fondamentale nella riuscita oppure,cosa che non so,BarboneNet ha fatto anche un grande lavoro sul DSDT.

 

Quindi,per quanto mi è dato di comprendere,l'utilizzo del DSDT può essere doppio: prima in una fase di "sgrosso" dei gravi conflitti e poi in una fase di affinamento per ottimizzare l'installazione, e magari prendersi lo sfizio di eliminare qualche Kext, in mezzo però rimane tutto il lavoro di sostanza (Cpu e Video) che, sempre se ho ben inteso,va fatto attraverso le EfiString ed i Kext adatti.

 

Ringrazio anticipatamente chiunque avrà la pazienza di commentare queste mie supposizioni.

 

Ciao.

 

Fabio

 

 

[BarboneNet]

ottimo.....anch'io mi sto un po' aggrovigliando con i dsdt!

 

Oggi ho perso un sacco di tempo per capire come estrarre i dsdt.aml dai file di bios .rom e .bin......alla fine ci sono riuscito, senza il tool Patcher02Beta04 gia noto sul forum internazionale.

 

Pero Scarx te sei troppo avanti hehee

[scrax]

Inizio definizioni per PCI 0

Device (PCI0) { Name (_ADR, Zero)

 

			Name (_UID, Zero)
		Name (_BBN, Zero)
		Name (_CID, EisaId ("PNP0A03"))
		Name (_HID, EisaId ("PNP0A08"))
		Name (_S3D, 0x02)
		Name (_PRT, Package (0x10){								  //Assegnazione degli IRQ ai device
			Package (0x04){0x0001FFFF,Zero,Zero,0x10},	   //P0P2
			Package (0x04){0x0001FFFF, One,Zero,0x11},
			Package (0x04){0x0001FFFF,0x02,Zero,0x12}, 
			Package (0x04){0x0001FFFF,0x03,Zero,0x13}, 
			Package (0x04){0x001FFFFF,Zero,Zero,0x12}, 
			Package (0x04){0x001FFFFF, One,Zero,0x16},	   //SATA 
			Package (0x04){0x001FFFFF,0x02,Zero,0x12}, 
			Package (0x04){0x001DFFFF,Zero,Zero,0x17},	   // EHCI - UHC1
			Package (0x04){0x001AFFFF,0x02,Zero,0x12},	   // UHCI - UHC6
			Package (0x04){0x001BFFFF,Zero,Zero,0x16},	   // HDEF
			Package (0x04){0x001DFFFF, One,Zero,0x13},	   // UHC2
			Package (0x04){0x001DFFFF,0x02,Zero,0x12},	   // UHC3
			Package (0x04){0x001AFFFF,Zero,Zero,0x10},	   // UHC4
			Package (0x04){0x001AFFFF, One,Zero,0x15},	   // UHC5
			Package (0x04){0x001CFFFF,Zero,Zero,0x11},	   // P0P4
			Package (0x04){0x001CFFFF, One,Zero,0x10},	   // P0P9
		})
		Name (AR10, Package (0x04){
			Package (0x04){0xFFFF,Zero,Zero,0x10}, 
			Package (0x04){0xFFFF,One,Zero,0x11}, 
			Package (0x04){0xFFFF,0x02,Zero,0x12}, 
			Package (0x04){0xFFFF,0x03,Zero,0x13}
		})
		Name (AR11, Package (0x04){
			Package (0x04){0xFFFF,Zero,Zero,0x11}, 
			Package (0x04){0xFFFF,One,Zero,0x12}, 
			Package (0x04){0xFFFF,0x02,Zero,0x13}, 
			Package (0x04){0xFFFF,0x03,Zero,0x10}
		})
		Name (PW94, Package (0x02){0x09,0x04})

 

Inizio parte definizioni per i device

 

MCEH

Non ho ancora chiaro a cosa serva, forse a nulla a parte rinominare il edvice con la stessa nomenclatura apple, sia su hack che su mac non carica nessun kext particolare vedendo in ioreg

			
		Device (MCEH){Name (_HID, EisaId ("APP0006"))
			Name (_STA, 0x0B)
		}

PEGP (scheda video)

Qui si può inserire il codice per la scheda video, anche s'è consigliato usare EFi string per tenere il dsdt al minimo.

			Device (PEGP){Name (_ADR, 0x00010000)
			Alias (AR10, _PRT)
			Alias (PW94, _PRW)
		//Linea da sostituire con dsdt per scheda video 
		}

 

PCIB

In questa parte si può inserire la patch per la firewire se altrimenti non funziona, nonostante la patch l' hotplug non è ancora funzionante

			Device (PCIB){Name (_ADR, 0x001E0000)
			Name (_PRT, Package (One){	 //  numero dei package
				Package (0x04){0x0003FFFF,Zero,Zero,0x10}	//assegnazione PCI firewire
			})
			Name (_PRW, Package (0x02){0x0B,0x04})
			Device (FRWR){						// inizio firewire patch
				Name (_ADR, 0x00030000)
				Name (_GPE, 0x1E)
				Method (_DSM, 4, NotSerialized){
					Store (Package (0x02){"fwports",Buffer (0x04){0x01, 0x00, 0x00, 0x00}}, Local0)
					MCDP (Arg2, RefOf (Local0))Return (Local0)}
			}											// fine firewire patch
		}

 

LPCB

Parte definizioni per il controller LPC, qui vengono impostate varie proprietà per i componenti della periferica come hpet , Rtc ecc. In questa parte si correggono problemi di hpet, bios reset ecc. Forse più avanti nel topic la vederemo più in dettaglio.

			Device (LPCB){Name (_ADR, 0x001F0000)
			OperationRegion (SMIE, SystemIO, 0x0830, 0x08)
			Field (SMIE, ByteAcc, NoLock, Preserve){,   4, PS1E,   1,Offset (0x04), ,   4, PS1S,   1}
			Method (SPTS, 0, NotSerialized){Store (One, PS1S)Store (One, PS1E)}
			Device (HPET){Name (_HID, EisaId ("PNP0103")) Name (_STA, 0x0F)
				Name (_CRS, ResourceTemplate (){
					IRQNoFlags (){0}	// problema IRQ Hpet
					IRQNoFlags (){8}	// problema IRQ Hpet
					Memory32Fixed (ReadOnly,0xFED00000,0x00000400)
				}) }
			Device (RTC){Name (_HID, EisaId ("PNP0B00")) Name (_CRS, ResourceTemplate (){
					IO (Decode16,0x0070,0x0070,0x01,0x02,)}) }  // 0x02, risolve il reset del bios (su gigabyte è 0x04,)
			Device (TIMR){Name (_HID, EisaId ("PNP0100")) Name (_CRS, ResourceTemplate (){
					IO (Decode16,0x0040,0x0040,0x01,0x04,) })
			}
		}

 

SATA

Parte definizioni per le porte SATA

			Device (SATA){Name (_ADR, 0x001F0002)
		}

 

SBUS

Definizione per SBus minime, senza non va più il risveglio dopo lo stop.

			Device (SBUS){Name (_ADR, 0x001F0003)
			OperationRegion (SMBE, PCI_Config, 0x04, 0x02)
			Field (SMBE, AnyAcc, NoLock, Preserve){
				IOSE,   1
			}
			Name (SBOK, Zero)
			Method (ENAB, 0, NotSerialized){Store (One, IOSE)Store (One, SBOK)}
			Method (DISB, 0, NotSerialized){Store (Zero, SBOK)}
		}

 

ECH1 e ECH2

definizioni per USB2 controller

			Device (EHC1){Name (_ADR, 0x001D0007)
			Name (_PRW, Package (0x02){0x0D,0x04})
		}
		Device (EHC2){Name (_ADR, 0x001A0007)
			Name (_PRW, Package (0x02){0x0D,0x04})
		}

 

POP#

Porte pci inutilizzate

			Device (P0P4){Name (_ADR, 0x001C0000)
			Alias (AR10, _PRT)
			Alias (PW94, _PRW)
		}
		Device (P0P5){Name (_ADR, 0x001C0001)
			Alias (AR11, _PRT)
			Alias (PW94, _PRW)
		}
		Device (P0P6){Name (_ADR, 0x001C0002)
			Alias (PW94, _PRW)
		}
		Device (P0P7){Name (_ADR, 0x001C0003)
			Alias (PW94, _PRW)
		}

 

P0P8

Jmicron controller PATA e SATA

			Device (P0P8){Name (_ADR, 0x001C0004)
			Alias (AR10, _PRT)
			Alias (PW94, _PRW)
		   Device (IDE0){
				Name (_ADR, Zero)
				Device (PRID){Name (_ADR, Zero)}
				Device (SECD){Name (_ADR, One)}
			}
			Device (PAT1){
				Name (_ADR, One)
				Device (PRID){Name (_ADR, Zero)}
				Device (SECD){Name (_ADR, One)}
			}
		}

 

RP06

Perte che definisce la lan come integrata

			Device (RP06){Name (_ADR, 0x001C0005)
			Alias (AR11, _PRT)
			Alias (PW94, _PRW)
			Device (LAN0){Name (_ADR, Zero)
				Name (_SUN, 0x0B)
				Name (_PRW, Package (0x02){0x09,0x03})
			}
		}

 

HDEF o AZAL

definizioni scheda audio. Il codice per il riconoscimento può essere integrato in EFI string come per la parte video

			Device (HDEF){Name (_ADR, 0x001B0000)
			Name (_PRW, Package (0x02){0x0D,0x06})
			// sostituire con codice per audio
		}

 

USB

Definizione per le porte usb, va aggiunto un id apple per farle riconoscere come interne in EFI String

			Device (UHC0){Name (_ADR, 0x001D0000)
			Name (_PRW, Package (0x02){0x03,0x04}) Name (_S3D, 0x02)
		}
		Device (UHC1){Name (_ADR, 0x001D0001)
			Name (_PRW, Package (0x02){0x04,0x04}) Name (_S3D, 0x02)
		}
		Device (UHC2){Name (_ADR, 0x001D0002)
			Name (_PRW, Package (0x02){0x0C,0x04}) Name (_S3D, 0x02)
		}
		Device (UHC3){Name (_ADR, 0x001A0000)
			Name (_PRW, Package (0x02){0x0E,0x04}) Name (_S3D, 0x02)
		}
		Device (UHC4){Name (_ADR, 0x001A0001)
			Name (_PRW, Package (0x02){0x05,0x04}) Name (_S3D, 0x02)
		}
		Device (UHC5){Name (_ADR, 0x001A0002)
			Name (_PRW, Package (0x02){0x20,0x04}) Name (_S3D, 0x02)
		}

[scrax]

Aprofitto del Topic per chiedere, a chi eventualmente sa la risposta: perchè da quando ho eliminato DSDT.aml dai miei PC (8 su 11), funziona tutto perfettamente (con Snow), sleep, stop etc. Inoltre in 2 sistemi ho risolto il problema dello Stop eliminandolo.

 

Giorgio

 

Sono anch'io curioso su questo fatto.

Prima di tutto chiariamo il fatto che se non usiamo un dsdt.aml alternativo il sistema comunque usa il dsdt che la MoBo ha in bios, inoltre c'è da considerare che molte modifiche al dsdt risolvono dei problemi che possono essere ovviati anche con dei disabler, kext o altri metodi o sono delle modifiche estetiche tipo avere il nome dei device simil-apple. Altre cose come il reset del bios è d'obbligo paciare il dsdt non essendoci altri metodi funzionanti.

 

Io credo che probabilmente su questi sistemi dove non hai il dsdt (considerando che hai tolto il dsdt patchato da dsdt patcher) vuol dire che la MoBo ha già un dsdt fatto abbastanza bene (e su questo fronte la Asus a occhio fa un po meno casini della Gigabyte) e che addirittura in alcuni casi le modifiche con dsdtpatcher siano negative su quelle mobo (leggi problema stop risolto eliminandolo), a me è capitato di aiutare qualcuno con un dst modificato da dstpacher in maniera tale da non essere più compilabile, per questo ne sconsiglio l'uso.

 

Però bisogna capire cosa intendi per "funziona tutto perfettamente" perciò ti chiedo un po' di delucidazioni sulla P5K-SE ad esempio:

Le usb te le vede interne? senza nessuna modifica specifica?

I drive SATA vanno a 3.0Gbit reali (AHCI Version 1.20 Supported)?

La scheda di rete è vista come interna di default? Altrimenti non hai problemi con timemachine?

Come fai a far funzionare lo speedstep (se il processore lo supporta ma penso di si nel tuo caso)?

O com'è possibile che ti carichi AppleLPC (se lo fa)?

Puoi postare una lista dei kext che usi e le opzioni di c.a.B.p per vedere se hai qualcosa a riguardo?

 

Sinceramente ti credo se dici che ti funziona tutto, ma non credo che sia un tutto perfettamente, dato che per lo speedstep nativo senza dsdt modificato non conosco nessun'altra maniera (puoi averlo con qualche kext ma allora non è più nativo).

 

Inoltre gli ultimi svilluppi mi portano a pensare che il dsdt è comunque scritto per windows e quindi moltissimo codice è inutile nei mac infatti il loro dsdt è tendenzialmente sempre più breve di quello dei pc, per questo con il lavoro fatto da Master Chief per le schede P5K si sta tendendo a ridurlo il più possibile. Questo velocizza l'avvio e in un secondo tempo potrebbe portarci ad avere un bootloader con dsdt ottimizzato già integrati nel bios (tradotto in una estrema velocità di boot)

 

Quindi dalla tua esperienza in sintesi credo che il dsdt modificato non sia obbligatorio per far andare bene uno Snow su certe configurazioni più compatibili di altre, ma serve per configurazioni che hanno dei problemi particolari (come il reset del bios ad es.) o per eliminare e ripulire da disabler e kext inutili una installazione funzinante rendendola così quasi perfetta.

 

Per vedere meglio il perchè tecnico devi estrarti i dsdt originali che usi nelle configurazioni senza /Extra/dsdt.aml e fare dei confronti con i dsdt che ti davano problemi così capisci cosa c'è che ti da problemi sullo stop

 

Per quanto riguarda SL dove, invece, l'installazione di BarboneNet prevede un DSDT.aml, esso (logicamente) è risultato esente da errori, però a mio modesto avviso il fatto di aver utilizzato un Harware "dedicato" e l'inserimento di maggiori driver (Kext) in SL retail, hanno giocato un ruolo fondamentale nella riuscita oppure,cosa che non so,BarboneNet ha fatto anche un grande lavoro sul DSDT.

 

Quindi,per quanto mi è dato di comprendere,l'utilizzo del DSDT può essere doppio: prima in una fase di "sgrosso" dei gravi conflitti e poi in una fase di affinamento per ottimizzare l'installazione, e magari prendersi lo sfizio di eliminare qualche Kext, in mezzo però rimane tutto il lavoro di sostanza (Cpu e Video) che, sempre se ho ben inteso,va fatto attraverso le EfiString ed i Kext adatti.

 

Allora, gli errori che ti da iasl sono da differenziare in errori avvisi e notifiche i primi non ti permettono di compilarlo e quindi di avere un file.aml funzionante mentre gli altri sono problemi ignorabili per la compilazione.

Tutto ciò non centra col fatto che il dsdt vada bene per Snow o no, è solo un controllo del codice che viene inserito, ma se il codice non va bene per Snow può esser comunque scritto giusto e non dare errori.

 

Col dsdt puoi fare tutto ma non è sempre la soluzione più comoda.

Io per esempio oltre a fakesmc.kext ho solo i kext per Audio, Pata e Scheda di rete (come se avessi installato periferiche di terze parti su un mac originale). Tutto il resto l'ho corretto tramite dsdt video compreso, ultimamente però per comodità ho portato molte modifiche al dsdt in EFI string video incluso (anche per ridurre il dsdt al minimo).

 

In pratica più o meno come avevi capito tu.

 

Oggi ho perso un sacco di tempo per capire come estrarre i dsdt.aml dai file di bios .rom e .bin......alla fine ci sono riuscito, senza il tool Patcher02Beta04 gia noto sul forum internazionale.

 

Hai fatto sempre da osx? Riesci anche a reinserire il dsdt paciato nel file.rom?

Spiega un po'

[Giorgio_multi]

Sono anch'io curioso su questo fatto.

Prima di tutto chiariamo il fatto che se non usiamo un dsdt.aml alternativo il sistema comunque usa il dsdt che la MoBo ha in bios, inoltre c'è da considerare che molte modifiche al dsdt risolvono dei problemi che possono essere ovviati anche con dei disabler, kext o altri metodi o sono delle modifiche estetiche tipo avere il nome dei device simil-apple. Altre cose come il reset del bios è d'obbligo paciare il dsdt non essendoci altri metodi funzionanti.

 

Io credo che probabilmente su questi sistemi dove non hai il dsdt (considerando che hai tolto il dsdt patchato da dsdt patcher) vuol dire che la MoBo ha già un dsdt fatto abbastanza bene (e su questo fronte la Asus a occhio fa un po meno casini della Gigabyte) e che addirittura in alcuni casi le modifiche con dsdtpatcher siano negative su quelle mobo (leggi problema stop risolto eliminandolo), a me è capitato di aiutare qualcuno con un dst modificato da dstpacher in maniera tale da non essere più compilabile, per questo ne sconsiglio l'uso.

 

 

Quindi dalla tua esperienza in sintesi credo che il dsdt modificato non sia obbligatorio per far andare bene uno Snow su certe configurazioni più compatibili di altre, ma serve per configurazioni che hanno dei problemi particolari (come il reset del bios ad es.) o per eliminare e ripulire da disabler e kext inutili una installazione funzinante rendendola così quasi perfetta.

 

 

Direi che hai sintetizzato molto bene il mio pensiero.

 

In quest'ottica sono d'accordo con te.

 

Io credo, che un sistema funzionante, che botta in 12-15 secondi, va in shutdown in 5-8 secondi, mai un KP, il software funziona, i benchmark (per quello che valgono) entro la media, lo sleep che funziona, Time machine che va, audio in e out OK etc etc sia l'obiettivo, poi come lo raggiungi poco importa, se hai la fortuna di avere hardware più "compatibile" soprattutto per quanto riguarda il BIOS residente, tribolerai meno.

 

Comunque usare il DST per implementare alcune funzionalità eliminando la necessità di usare i kext è elegante, inoltre come dicevi, alcune funzionalità necessitano del DSDT (vedi reset del BIOS)

 

Siccome molti utenti del Forum non sono a mio avviso, preparati per gestire un DSDT correttamente, in prima battuta cerco sempre di aiutare a risolvere i problemi nella maniera più semplice.

E' ovvio che tra utenti "evoluti" ad es tu, Smith@@ Tristano etc si possono percorrere strade diverse.

 

L'ideale, utopisticamente, sarebbe creare per ogni configurazione, un DSDT ottimizzato da inserire definitivamente nel BIOS di quella mobo.

 

Grazie per la risposta, cortese e auterovele.

 

Giorgio

[BarboneNet]

Hai fatto sempre da osx? Riesci anche a reinserire il dsdt paciato nel file.rom?

Spiega un po'

stasera di dico bene la procedura!

 

certo, con questo metodo di possono creare i fantomatici bios per OSX...senza usare l'utility Patcher02beta4, che a volte crea casini!

 

pero, bisogna ridurre le ottimizzazioni del dsdt, e patcharlo solo quanto basta per rendere la versione del bios standard....altrimenti se ci metti le ottimizzazioni per un Q9550, l'utente con il C2D E6600 potrebbe avere dei problemi, e viceversa.....quindi nel settore CPU, bisogna limitarsi a rimuovere gli alias!

 

Stessa cosa per il reparto video, al massimo si patcha dopo il dsdt.aml nella cartella Extra.

 

P.S: comunque ho usato Windows(ho messo in piedi un baracchino con su WindowsXp e Ubuntu9.10, non si sa mai che mi servano per vecchi software, o per qualcosa di particolare:))....comunque quei tool funzionano anche su Seven e Vista!

[RASONE]

in questi giorni ho installato snow su una p55 e magie delle magie è partito senza dsdt e senza nullcpupwrmenagement, caricando anche tranquillamente il CpuPowerMenagement, è una Asus P7P55D con i5 750, i dischi li vede come unknow device, 3gbit, AHCI version 1.3, anche se però la frequenza del procio andava al minimo, ma risolto con EvoSpeedstep, ma lo speedstep vanilla proprio niente, sempre kernel panic,

ste asus mi sbalordiscono sempre di più su os x, per stare in tema con ciò che diceva Giorgio

[Smith@@™]

stasera di dico bene la procedura!

 

certo, con questo metodo di possono creare i fantomatici bios per OSX...senza usare l'utility Patcher02beta4, che a volte crea casini!

 

pero, bisogna ridurre le ottimizzazioni del dsdt, e patcharlo solo quanto basta per rendere la versione del bios standard....altrimenti se ci metti le ottimizzazioni per un Q9550, l'utente con il C2D E6600 potrebbe avere dei problemi, e viceversa.....quindi nel settore CPU, bisogna limitarsi a rimuovere gli alias!

 

Stessa cosa per il reparto video, al massimo si patcha dopo il dsdt.aml nella cartella Extra.

 

P.S: comunque ho usato Windows(ho messo in piedi un baracchino con su WindowsXp e Ubuntu9.10, non si sa mai che mi servano per vecchi software, o per qualcosa di particolare:))....comunque quei tool funzionano anche su Seven e Vista!

 

D'accordo. Patcher02beta4 è discreto, ma ha millemila bug :mellow:

[scrax]

Capisco il discorso dsdt poco modificato per la compatibilità ma a me interessava provare il mio all'osso con Revolution a far da bootloader così da avere solo /Extra/SSDT.aml per il procio. Peccato non sia fattibile con osx ancora.

Nota che per avere il dsdt da snow senza usare il Pacher2beta4 basta usare DSDTSE.

 

in questi giorni ho installato snow su una p55 e magie delle magie è partito senza dsdt e senza nullcpupwrmenagement, caricando anche tranquillamente il CpuPowerMenagement, è una Asus P7P55D con i5 750, i dischi li vede come unknow device, 3gbit, AHCI version 1.3, anche se però la frequenza del procio andava al minimo, ma risolto con EvoSpeedstep, ma lo speedstep vanilla proprio niente, sempre kernel panic,

ste asus mi sbalordiscono sempre di più su os x, per stare in tema con ciò che diceva Giorgio

 

Anche la mia p5k-c/r parte senza dsdt, non ricordo bene che problemi da tipo icone gialle ecc, però per partire parte, il dsdt rende tutto più veloce e "carino"

[BarboneNet]

Capisco il discorso dsdt poco modificato per la compatibilità ma a me interessava provare il mio all'osso con Revolution a far da bootloader così da avere solo /Extra/SSDT.aml per il procio. Peccato non sia fattibile con osx ancora.

Nota che per avere il dsdt da snow senza usare il Pacher2beta4 basta usare DSDTSE.

si ma dsdtse o everest, estraggono solo il dsdt della mobo in uso!

 

comunque ho dei problemi con riapplicazione del dsdt patchato nel bios......devo lavorarci ancora su per farlo manualmente!

altrimenti devo usare patcher02beta4 ma non mi arrendo.....ci sono quasi;)

 

P.S. menomale che la p5q deluxe ha il doppio bios..ho gia dovuto fare 2 flash a caldo:D

 

EDIT: mi sa che il bios moddato puo solo limitarsi a correggere gli errori e i warnings, piu le ottimizzazioni per cpu alias, htpe, rtc, vget fget tget, issomma alle ottimizazioni base!

Infatti con le ottimizzazioni di smith@@ non è possibile senza fare danni al bios!

[scrax]

si ma dsdtse o everest, estraggono solo il dsdt della mobo in uso!

Hai ragione non ci avevo pensato!

 

comunque ho dei problemi con riapplicazione del dsdt patchato nel bios......devo lavorarci ancora su per farlo manualmente!

EDIT: mi sa che il bios moddato puo solo limitarsi a correggere gli errori e i warnings, piu le ottimizzazioni per cpu alias, htpe, rtc, vget fget tget, issomma alle ottimizazioni base!

Infatti con le ottimizzazioni di smith@@ non è possibile senza fare danni al bios!

 

Nel senso che non funziona proprio più l'avvio o che non puoi reinserirlo?

 

A me è capitato che per non aver problemi ad inserire il dsdt nel bootloader è necessario che i bit siano divisibili per 4, forse può aiutare.

Se non lo è bisogna aggiungere delle linee alla fine del dsdt prima dell' ultima } con scritto:

Noop

finch'è si arriva ad un valore divisibile per 4. altrimenti il codice viene inserito in maniera incompleta e il dsdt non funziona.

[BarboneNet]

Hai ragione non ci avevo pensato!

 

 

 

Nel senso che non funziona proprio più l'avvio o che non puoi reinserirlo?

 

A me è capitato che per non aver problemi ad inserire il dsdt nel bootloader è necessario che i bit siano divisibili per 4, forse può aiutare.

Se non lo è bisogna aggiungere delle linee alla fine del dsdt prima dell' ultima } con scritto:

Noop

finch'è si arriva ad un valore divisibile per 4. altrimenti il codice viene inserito in maniera incompleta e il dsdt non funziona.

no, infondo ci vuole un WAKh...nel dsdt originale c'era.....con le ottimizzazione di smith@@ è sparito......ora ti posto il finale dell'originale!

 

P.S: ho provato ad aggiungerlo io, e il bios si era corrotto.....ho dovuto mettere il bios di recovery nello slot 1, e poi a pc avviato ho rimesso il vecchio bios corrotto e l'ho flashato....intanto che c'ero ho flashato anche il bios di recovery con l'ultima versione;)

    Method (WAK, 1, NotSerialized)
   {
       \_SB.PCI0.SBRG.SIOW (Arg0)
       \_SB.PCI0.SBRG.SWAK (Arg0)
       \_SB.PCI0.NWAK (Arg0)
   }
}

[Smith@@™]

Non puoi inserire questo "wak", richiama altro codice che non c'e' piu'! I metodi siow e nwak sono stati eliminati, il device sbrg e' stato rinominato. Ragazzi non inseriamo codice a caso della serie manca, allora lo aggiungo. Al "FUNZIONAMENTO", reale, quell'aggiunta non servira' a nulla in quanto manca dell'altro codice, quello e' solo un richiamo...

 

Il metodo wak dev'essere ad' ora al massimo questo:

Method (_WAK, 1, NotSerialized)
{
	Store (Zero, \_SB.PCI0.LPCB.EC.ECSS)
	\_SB.PCI0.SBUS.ENAB ()
	  PNOT ()
 //	  PINI ()
	Return (Package (0x02)
	{
		Zero, 
		Zero
	})
}

 

Ciao

[BarboneNet]

Non puoi inserire questo "wak", richiama altro codice che non c'e' piu'! I metodi siow e nwak sono stati eliminati, il device sbrg e' stato rinominato. Ragazzi non inseriamo codice a caso della serie manca, allora lo aggiungo. Al "FUNZIONAMENTO", reale, quell'aggiunta non servira' a nulla in quanto manca dell'altro codice, quello e' solo un richiamo...

 

Il metodo wak dev'essere ad' ora al massimo questo:

Method (_WAK, 1, NotSerialized)
{
	Store (Zero, \_SB.PCI0.LPCB.EC.ECSS)
	\_SB.PCI0.SBUS.ENAB ()
	  PNOT ()
 //	  PINI ()
	Return (Package (0x02)
	{
		Zero, 
		Zero
	})
}

 

Ciao

per metterlo nel bios, bisogna solo limitarsi a rimuovere i warnings e gli errori + le ottimizzazioni base, oltre non gradisce!

 

direi che il massimo di ottimizzazione è questa

dsdt.aml.zip

[scrax]

Method (_WAK, 1, NotSerialized)
{
	Store (Zero, \_SB.PCI0.LPCB.EC.ECSS)
	\_SB.PCI0.SBUS.ENAB ()
	  PNOT ()
 //	  PINI ()        //    
	Return (Package (0x02)
	{
		Zero, 
		Zero
	})
}

 

Il mio attuale _WAK:

Method (_WAK, 1, NotSerialized){
	\_SB.PCI0.SBUS.ENAB ()		 // legato a SBUS
	/*PINI ()					   // by THe KiNG @ projectosx.com
	\_PR.NOTI ()			
	\_SB.PCI0.UNOT ()*/
	Return (Package (0x02){Zero,Zero})
}

 

in pratica faccio a meno di:

		Store (Zero, \_SB.PCI0.LPCB.EC.ECSS)

 

e mi va tutto comunque.

 

Dagli ultimi test per avere il risveglio dallo stop devo matenere

\_SB.PCI0.SBUS.ENAB () // legato a SBUS

o non mi si risveglia più.

Oltre ad alcune altre parti.

 

Quello che non capisco è se il bios viene moddato e poi quando parte Osx il dsdt inserito non è quello che dovrebbe essere o se invece modificando troppo il dsdt non si riesce più ad integrarlo nel bios per errori nel flasharlo con la .rom modificata

 

Nota: ho corretto la parte relativa all SBUS lasciando solo l'indispensabile, nei prossimi test cercherò di ridurre il Device LPCB che secondo me è ancora troppo.

 

Sto cercando di ridurre il tutto al minimo per avere una dsdt base che possa funzionare da partenza per varie mobo, se vi va di testare le riduzioni suggerite in questo topic fatemi sapere come si comportan con le vostre configurazioni.

[Smith@@™]

Il mio attuale _WAK:

Method (_WAK, 1, NotSerialized){
	\_SB.PCI0.SBUS.ENAB ()		 // legato a SBUS
	/*PINI ()					   // by THe KiNG @ projectosx.com
	\_PR.NOTI ()			
	\_SB.PCI0.UNOT ()*/
	Return (Package (0x02){Zero,Zero})
}

 

in pratica faccio a meno di:

		Store (Zero, \_SB.PCI0.LPCB.EC.ECSS)

 

e mi va tutto comunque.

 

Dagli ultimi test per avere il risveglio dallo stop devo matenere

\_SB.PCI0.SBUS.ENAB () // legato a SBUS

o non mi si risveglia più.

Oltre ad alcune altre parti.

Ma infatti te lo feci notare, prima di postare il dsdt a barbone che master nel suo aveva tolto troppo e alcune parti di codice erano necessario proprio per lo sleep

 

Quello che non capisco è se il bios viene moddato e poi quando parte Osx il dsdt inserito non è quello che dovrebbe essere o se invece modificando troppo il dsdt non si riesce più ad integrarlo nel bios per errori nel flasharlo con la .rom modificata

 

Nota: ho corretto la parte relativa all SBUS lasciando solo l'indispensabile, nei prossimi test cercherò di ridurre il Device LPCB che secondo me è ancora troppo.

 

Sto cercando di ridurre il tutto al minimo per avere una dsdt base che possa funzionare da partenza per varie mobo, se vi va di testare le riduzioni suggerite in questo topic fatemi sapere come si comportan con le vostre configurazioni.

 

Per mia esperienza, oltre all'ottimizzazione iniziale fatta dal compilatore e all'aggiunta di fix quali hpet, rtc e rimossione alias, la mia deluxe non ne vuole sapere di partire, ventole a manetta e schermo nero .

 

 

Continuiamo con i test ....

[scrax]

Continuiamo con i test ....

 

Eh si, inizierò a provare anch'io a modificarmi il bios per vedere come si comporta. Per il resto hai ragione tu, comunque il 3.3.1 sembra che qualcuno l'abbia inserito nel bios senza problemi e con grandi miglioramenti in avvio (più veloce)

[Hugo_bee]

io aggiungo e sostengo scrax, perchè effettivamente e per la prima volta con la mobo amd tutti gli sforzi per fare un dsdt ideale, sono stati vani con snow. ma anche con leo, e forse (retorico) è colpa dei nuovi bootloader chamaleon.

 

infatti la prerogativa delle rc3 e poi rc4 è di infilare sempre più nel sistema cose che tipicamente si mettevano a manovella.

 

unito al fatto di passare dati già corretti, o quasi.

 

faccio un esempio: questa motherboard fa uno sleep ottimo, solo con la modifica wak e se si mette un metodo opportuno di notifica anche su tutte le periferiche usb si evita il noioso problema delle periferiche non correttamente inizializzate al resume.

eppure lo stesso dsdt in snow non lavora bene, e lo sleep non funziona se non si mette lo sleepenabler.kext. non spegne il video, etc..

 

siccome non è la prima volta che mi succede, oserei dire che in snow, nonstante sembri tanto uguale a leo, forse nel kernel non lo è al punto da bypassare comunque alcune informazioni iniettate post-boot e lette sulla piastra!

 

oppure che il chameleon e i boot comunque basati su modifiche del file boot di un chamaleon rc3 sono già troppo spinti da impedire che le modifiche del dsdt legate a parti vitali vengano interpretate come noi vogliamo e comunque bypassate?

 

ho passato 2 giorni a modificare un dsdt, per poi non cogliere differenze.

 

persino la grafica, che in leo era delegata ad un efi oppure con una sezione dsdt, in snow non gira.

 

chiedo: (è un mio pensiero, che vorrei condividere)

 

1-a scrax di non "sporcare" il bel lavoro che sta facendo (e che io davvero considero inumano per la voglia e la fatica necessarie ) con risposte o domande più legate al troubleshooting, magari (vedi 2)

2-ad un adm: di mettere questa cosa in uno stickye, e lasciarlo così intonso come una guida, e sotto invece permettere a tutti di chiedere ed ottenere una soluzione

 

altrimenti si rischia di avere un bel topic chilometrico, poco visibile e a breve introvabile oltre che dispersivo. se scrax dovesse appendere altre guide uno dovrebbe sfogliarsi tutte le pagine..

a l'ha gnun sens

[Smith@@™]

Sporcare il topic di scrax? Ma di che stai parlando?

 

Non ho ben capito, tranne gli ultimi 2 punti, a cosa precisamente ti riferisci nel tuo post? Chi e' che non sostiene scrax?

Tu hai capito di cosa parlavamo negli ultimi 2 post io e lui? Di revolution e non del dsdt in generale o del suo thread... :mellow:

 

Bho..

[Hugo_bee]

si si. certo

sprecare nel senso che questo topic è iniziato in un modo e me lo immaginavo così.. visto che non esiste nel forum una vera guida sul dsdt.. e molti le cercano e la chiedono. una luce.

sai anche tu che l'hardware passa e va, e se uno oggi chiede o cerca cose legate ad un modello specifico non le trova se non in topic vecchi di un anno. veceversa, avere una guida pulita che non arrivi ad avere 500post con domande e risposte nello specifico di ciascuno, credo (dico credo) sia meglio.

da quant'è che se ne parla?

 

è solo una idea.. nessuna critica a nessuno . ed ho capito dai

[Smith@@™]

si si. certo

sprecare nel senso che questo topic è iniziato in un modo e me lo immaginavo così.. visto che non esiste nel forum una vera guida sul dsdt.. e molti le cercano e la chiedono. una luce.

sai anche tu che l'hardware passa e va, e se uno oggi chiede o cerca cose legate ad un modello specifico non le trova se non in topic vecchi di un anno. veceversa, avere una guida pulita che non arrivi ad avere 500post con domande e risposte nello specifico di ciascuno, credo (dico credo) sia meglio.

da quant'è che se ne parla?

 

è solo una idea.. nessuna critica a nessuno . ed ho capito dai

 

Ok. Spiegata cosi' e' tutt'altra cosa

 

Ciao

[BarboneNet]

Quello che non capisco è se il bios viene moddato e poi quando parte Osx il dsdt inserito non è quello che dovrebbe essere o se invece modificando troppo il dsdt non si riesce più ad integrarlo nel bios per errori nel flasharlo con la .rom modificata

 

il codice diventa incompatibile e non si riesce ad inserire nel bios. ce la fai....ma doo il flash non parte piu la mobo.

[scrax]

1-a scrax di non "sporcare" il bel lavoro che sta facendo (e che io davvero considero inumano per la voglia e la fatica necessarie ) con risposte o domande più legate al troubleshooting, magari (vedi 2)

2-ad un adm: di mettere questa cosa in uno stickye, e lasciarlo così intonso come una guida, e sotto invece permettere a tutti di chiedere ed ottenere una soluzione

Secondo me non hai tutti i torti però al tempo stesso questo post è ancora molto abbozzato e come guida è troppo sintetica a mio parere. Quindi per ora proverei a sfruttare questo topic come raccoglitore di idee e suggerimenti e contributi per realizzare la guida finale che intendi tu.

 

Per esempio il top che potremmo avere è un dsdt tutto commentato riga per riga dove si spiega a cosa serve quel pezzo di codice. Son d'accordo che la cosa è molto ardua ma il mio modo di pensare è "un Top2Bottom sul palazzo delle nazioni unite" (leggi puntare al massimo per avere almeno un minimo).

 

Quindi in sintesi vi chiedo, se volete, di aiutarmi nella stesura della guida. Postando parti e spiegazioni che secondo voi servono, come in un wiki anche se qui sarò io per cause tecniche a dover tanere il primo topic aggiornato con le vostre aggiunte e renderlo più completo. Una volta che il tutto inizia a prendere una forma meno sintetica si può pensare di spostarlo o anche aggiungerlo a quello di Giorgio su Kernel, Darwin, Efi ecc, o no?

 

Tipo se qualcuno vuole scrivere la prima parte su come estrarre il dsdt con un metodo, poi un'altro ci aggiunge un altro metodo ecc. io mi riprometto di mantenere tutto insieme e di dare credito a chiunque contribuisca (come già faccio con il topic su Chameleon ad es.)

 

Piccolo esempio di aggiornamento al primo topic:

 

Nota: aggiungere spiegazione base sulla struttura del DSDT (parentesi, commenti singola linea, commenti a blocchi, struttura base di un blocco di codice ecc.)

Modificato:

Scope (_PR) {	 // qui verranno definiti i parametri dei core (comuni per tutti)
// Modificare in base ai propri p-state (0x03 è il numero in esadecimale dei p-state impostati ad es. con 11 p-state ci vuole 0x0B)
	Name (PSS, Package (0x03){	
		Package (0x06){Zero,Zero,0x0A,0x0A,0x082A,Zero},	 // p-state 0 (max freq)
		Package (0x06){Zero,Zero,0x0A,0x0A,0x0724,One},	  // p-state 1 (unico valore da modificare è 0724)
		Package (0x06){Zero,Zero,0x0A,0x0A,0x061D,0x02}	 // p-state 2 (061D sono i valori di Fid e Vid per questo p-state)
	})
	//Name (PSD, Package (0x05){0x05,Zero,Zero,0xFC,0x04})	 //rimosso per snellire il codice in quanto sembra sene occupi AppleLPC.kext di questo
	Name (CST, Package (0x04){0x03, 
		Package (0x04){ResourceTemplate (){Register (FFixedHW,0x01,0x02,0x0000000000000000,,)},One,One,0x03E8}, 
		Package (0x04){ResourceTemplate (){Register (SystemIO,0x08,0x00,0x0000000000000814,,)},0x02,One,0x01F4}, 
		Package (0x04){ResourceTemplate (){Register (SystemIO,0x08,0x00,0x0000000000000815,,)},0x03,0x55,0xFA}
	})
	Processor (CPU1, 0x01, 0x00000810, 0x06){
		Alias (PSS, _PSS)	   // alias per non riscrivere i valori dei p-state per il secondo core
		//Alias (PSD, _PSD)	//rimosso l'alias che riprendeva i valori di _PSD
		Alias (CST, _CST)
	}
	Processor (CPU2, 0x02, 0x00000810, 0x06){
		Alias (PSS, _PSS)	   // alias per non riscrivere i valori dei p-state per il terzo core
		//Alias (PSD, _PSD)	//rimosso l'alias che riprendeva i valori di _PSD
		Alias (CST, _CST)
	}
/* Parte necessaria solo per i quadcore (cancellare questa linea per decommentare la parte)
	Processor (CPU3, 0x03, 0x00000810, 0x06){
		Alias (PSS, _PSS)	   // alias per non riscrivere i valori dei p-state per il terzo core
		//Alias (PSD, _PSD)	//rimosso l'alias che riprendeva i valori di _PSD
		Alias (CST, _CST)
	}
	Processor (CPU4, 0x04, 0x00000810, 0x06){
		Alias (PSS, _PSS)	   // alias per non riscrivere i valori dei p-state per il quarto core
		//Alias (PSD, _PSD)	//rimosso l'alias che riprendeva i valori di _PSD
		Alias (CST, _CST)
	}
*/ linea da cancellare se si ha un quad core
}

 

 

ORIGINALE:

Scope (_PR) {
	Name (PSS, Package (0x03){	// Modificare in base ai propri p-state
		Package (0x06){Zero,Zero,0x0A,0x0A,0x082A,Zero},
		Package (0x06){Zero,Zero,0x0A,0x0A,0x0724,One},
		Package (0x06){Zero,Zero,0x0A,0x0A,0x061D,0x02}
	})
	//Name (PSD, Package (0x05){0x05,Zero,Zero,0xFC,0x04})
	Name (CST, Package (0x04){0x03, 
		Package (0x04){ResourceTemplate (){Register (FFixedHW,0x01,0x02,0x0000000000000000,,)},One,One,0x03E8}, 
		Package (0x04){ResourceTemplate (){Register (SystemIO,0x08,0x00,0x0000000000000814,,)},0x02,One,0x01F4}, 
		Package (0x04){ResourceTemplate (){Register (SystemIO,0x08,0x00,0x0000000000000815,,)},0x03,0x55,0xFA}
	})
	Processor (CPU1, 0x01, 0x00000810, 0x06){
		Alias (PSS, _PSS)
		//Alias (PSD, _PSD)
		Alias (CST, _CST)
	}
	Processor (CPU2, 0x02, 0x00000810, 0x06){
		Alias (PSS, _PSS)
		//Alias (PSD, _PSD)
		Alias (CST, _CST)
	}
	Processor (CPU3, 0x03, 0x00000810, 0x06){
		Alias (PSS, _PSS)
		//Alias (PSD, _PSD)
		Alias (CST, _CST)
	}
	Processor (CPU4, 0x04, 0x00000810, 0x06){
		Alias (PSS, _PSS)
		//Alias (PSD, _PSD)
		Alias (CST, _CST)
	}
}