FreeJHack

Mi associo agli Auguri di Buone Feste a tutti...

Ottimo, bravi 👍

Tanti cari Auguri di Buone Feste a tutti voi

Contraccambio gli auguri.

Beh, vista l'ora ormai tarda, Buona Pasquetta fuori porta a tutti...

Contraccambio auguri di Cuore a tutti voi...

Buone Feste

47 minuti fa, Gengik84 ha scritto:

Si FakeCPU sicuramente come anche un FakeID per la grafica

Ritieni ci possano essere problemi/complicazioni di configurazione? Non vorrei perderci molto tempo, altrimenti prendo un NUC8...

Considera che va in un magazzino a svolgere un'unica funzione con una mia app, non installo praticamente software.

@Gengik84Buongiorno,

come da oggetto, necessito di installare Mojave su NUC10i3, non posso andare oltre (app a 32bit), ti risulta fattibile?

Necessita fake CPU?

Grazie

PS: perdona, per errore l'ho postato in AMD

3 minuti fa, Gengik84 ha scritto:

LPC su hardware Skylake e successivi ha poco senso

Hai ragione, ma ho notato che su alcuni PC è l'unico modo per visualizzare la dialog

4 ore fa, A23SS4NDRO ha scritto:

A che serve?

Eventi interni. Per esempio, quando premi il pulsante Power, compare la dialog di Stop/Riavvia/Spegni...

Suggerisco compatibilità con 9cc3

21 ore fa, A23SS4NDRO ha scritto:

che differenza ci fosse

Come hai evidenziato nella tua domanda e come avrai notato come hackintosher, ci sono diversi metodi per ottenere "apparentemente" lo stesso risultato.

Apparentemente; perché in realtà ogni metodo porta con se alcune implicazioni e differenze.

Se verifichi tramite IORegistryExplorer le varie proprietà di un Device, noterai che entrambi i metodi le aggiungono/inseriscono, ma i due metodi lo fanno in modo diverso: il primo utilizza il metodo ACPI sfruttando il fatto che durante il boot il sistema operativo (OS) chiama le routine (_INI, _STA, _DSM,...) dei vari device, pertanto, aggiungendo un Device Specific Method (_DSM) sei certo che l'OS carichi la funzione specifica che il device necessita, nel tuo caso, inietta le proprietà. (...ecco perchè, al contrario, a volte consigliano di patchare _DSM con XDSM, in modo da disattivare specifiche funzioni Windows non necessarie o dannose per MacOS)

Il secondo, inietta direttamente le proprietà nel device a prescindere dall'esecuzione di un _INI o _DSM, però l'injecting è fatto prima del boot dell'OS, quindi in qualche caso può essere più efficace o addirittura necessario: per esempio, se vuoi cambiare/patchare il nome di un device, non puoi farlo durante il boot dell'OS, sarebbe troppo tardi, lo devi fare prima, ecco perché OC o Clover preparano/patchano il PC e poi lanciano il boot dell'OS.

Questa è una domanda che richiederebbe risposte lunghe e complesse, spero, però, di averti risposto e chiarito, almeno in parte, le tue perplessità.

Se vuoi approfondire ulteriormente, in rete trovi i manuali in pdf riguardo l'ACPI che altro non è se non il "ponte" tra l'hardware fisico e l'OS che lo vuole utilizzare.

Un saluto.

4 minuti fa, Gengik84 ha scritto:

come nei veri mac

In realtà anche nei veri mac non sono tutte presenti.

Di seguito un estratto DSDT originale da un MacBookPro14,1

@Gengik84Nel ringraziarti per HC, ti segnalo che nella sezione USB potrebbe non visualizzare correttamente i power supply limit.

Come vedi le proprietà sono presenti

Chi non usa il metodo ACPI per creare un device USBX e come me usa l'injecting tramite USBPorts.kexts (o simile...),

si trova che queste proprietà non vengano visualizzate

Non è un grande problema, lo segnalo in quanto potrebbe essere d'aiuto e anche per indicare un metodo alternativo per aggiungerle e per verificarne la presenza...

Un caro saluto a tutti.

Ringrazio e contraccambio.

Tanti Auguri di Buone Feste e Sereno 2021 a tutti...

1 ora fa, iCanaro ha scritto:

ho DSDT che mi elaborò Gengik a marzo e quello ora con questa modifica

Dato che nella cartella EFI/CLOVER/ACPI/patched puoi mettere solo un DSDT.aml, deduco che hai usato solo quello con la modifica _Q11 e_Q12.

Se il DSDT di Gengik contiene altri patch necessari, puoi aggiungere anche quelli di _Q11 e _Q12 e usarlo, come preferisci. Ma puoi usarne solo uno, ovviamente.

Verifica che sia settato anche AutoMerge nella sezione ACPI/DSDT di clover configurator o solito PList se non usi il configuratore

1 ora fa, iCanaro ha scritto:

se controlli che abbia fatto a modo

Si, il patch è corretto

Deve funzionare, sono abbastanza certo che _Q11 e _Q12 siano i metodi chiamati quando premi i tasti Fn+F8 o F9. Diversamente si dovrà installare il kext ACPIDebug e verificare quali siano le query inviate dall'hardware quando premi i tasti.

Se vuoi, allega la EFI, IOReg e il bootlog che verifico. 

20 ore fa, iCanaro ha scritto:

https://bitbucket.org/RehabMan/os-x-acpi-debug/src/master/

Si. Ma potrebbe non essere necessario

@iCanaro dai, dai sistemiamolo... ci metti poco.

Devi patchare le due query dell'ACPI: ho dato un'occhiata al DSDT contenuto in origin.zip che hai postato, ho ragione di credere che le due query della luminosità siano proprio la _Q11 e la _Q12.

Cerca nel DSDT i due metodi delle due query e sostituiscili con questi:

Method (_Q11, 0, NotSerialized)  // _Qxx: EC Query
{
    Notify (PS2K, 0x0405)
}

Method (_Q12, 0, NotSerialized)  // _Qxx: EC Query
{
    Notify (PS2K, 0x0406)
}

Aggiungendo il DSDT patchato alla cartella ACPI/patched della EFI di clover dovrebbe funzionare il controllo luminosità da tastiera Fn+F8 e Fn+F9.

S vuoi usare OC, il patch è leggermente diverso:

Method (_Q11, 0, NotSerialized)  // _Qxx: EC Query
{
    If (_OSI ("Darwin")) { Notify (PS2K, 0x0405) } Else { XQ11() }
    Return (Zero)
}

Method (_Q12, 0, NotSerialized)  // _Qxx: EC Query
{
    If (_OSI ("Darwin")) {  Notify (PS2K, 0x0406) } Else { XQ12() }
    Return (Zero)
}

ma in questo secondo caso dovrai anche aggiungere due rename nella sezione ACPI->Patch come da immagine:

o l'equivalente tramite PList se non usi il configuratore.

@iCanaro confermo che BT e wifi possono essere accesi/spenti a patto che non siano stati disattivati direttamente dal menu o nelle preferenze di sistema. Di fatto vengono ripristinate le condizioni precedenti all'attivazione del modo Airplane.

Per quanto riguarda Fn+F8 & F9, dovresti verificare le query inviate all'ACPI: spesso  sono _Q11 e _Q12, ma nel tuo caso potrebbero essere diverse. Anzi, se non funzionano lo sono di certo.

Suggerisco il kext ACPIDebug, ma penso che tu lo conosca bene...

4 ore fa, SaxMachine ha scritto:

FakeSMC perché mi andava in KP

... forse può esserti d'aiuto 

@iCanaro Ok, bene.

Considera che i maggiori benefici saranno per coloro che hanno sensori LPC (SuperIO) della ITE o Fintek (p.e. Gigabyte) perché il kext LPCSensor cerca la proprietà "vendor" per valutare la presenza di un determinato sensore. Senza quella proprietà il sensore non viene caricato...

Se utilizzate FakeSMC v.6.26-357.1800 (RehabMan-kozlek) e OpenCore 0.60 (0.5.9), dando un'occhiata al boot-log probabilmente avrete occasionalmente (o sempre) FakeSMC in backtrace e alcuni di voi potrebbero sperimentare anche un crash durante il boot (non sempre...).

Storia breve: questo è causato da un'incompatibilità tra FakeSMC (un po' vecchietto, ma valido...) e OpenCore. 

Ecco quello che potreste trovare:

Inoltre, utilizzando IORegistryExplorer, se controllate nella risorsa FakeSMCKeyStore risultano mancanti le proprietà "manufacturer" e "product-name", in alcuni casi utili e normalmente caricate da Clover.

come potete vedere nell'immagine sopra.

Ho modificato il kext in modo tale da eliminare il backtrace che potrebbe rendere critico il boot e caricare le due properties.

Per caricare le properties indicate, è necessario attivare nel file config.plist di OpenCore ExposeSensitiveData->Expose OEM information as a set of UEFI variables = true, in Misc->Security.

Sostituite FakeSMC.kext con la versione modificata e riavviate.

Dopo il boot, controllate il log e troverete la stringa "Trying OpenCore OEM properties..."

e con IORegistryExplorer verificate la risorsa FakeSMCKeyStore e troverete il "manufacturer" e il "product-name":

che nel mio caso è "Clevo", le vostre saranno, ovviamente, diverse.

NON è necessario sostituire i kext di supporto ACPISensors.kext, CPUSensors.kext, ...

E sufficiente sostituire FakeSMC.kext

Per chi vuole compilare (ricordarsi prima il versioning): https://github.com/FreeJHack/OS-X-FakeSMC-kozlek

in alternativa, allego il kext già compilato.

Spero possa essere d'aiuto...

FakeSMC.kext.zip

Il 5/9/2019 at 23:28, iCanaro ha scritto:

ma sinora esito negativo emoticon_uff

Verifica in IOReg se hai il device DCHU, la prima versione usava solo quello e se manca non carica il kext. Probabilmente nel tuo ACPI è presente solo il metodo WMBB (nel device WMI), devi aggiornare il file SSDT-ClevoService.dsl. Verifica anche le tue EC queries, se sono diverse vanno, ovviamente, aggiornate...

Prova la 1.2.0, ho aggiunto anche un agent per visualizzare l'intensità tastiera (usa OSD come per la retroilluminazione LCD) e attiva/disattiva bluetooth e Wifi (Airplane mode).

Richiede installazione in /L/E

Un saluto a tutti...

Coder da molti anni, spero di poter essere d'aiuto, tempo permettendo.

Ciao.