dreamwhite

1 minute ago, damiandrake said:

E' quello che ho visto su Insta? Ci sta, ci sta molto

Yep, è una macchina discreta ma svolge il suo sporco lavoro. D'altronde per la programmazione non serve chissà quale potenza. Un 4C/8T basta e avanza

Sul mio Dell Inspiron 5370 Monterey gira discretamente, incluso il trackpad con le gestures, la mappatura delle USB etc...  L'unica cosa che al momento non funziona è il bluetooth della mia DW1830 il quale dipende da BrcmPatchRAM...

La butto li: hai scaricato ed installato l'ultimo aggiornamento di sicurezza di High Sierra? Di solito quando scarichi High Sierra tramite App Store/script come munki, non scarichi l'ultima versione ma una precedente (17G66 per la cronaca).
Verifica gli aggiornamenti disponibili tramite App Store e riprova >)

On 4/26/2021 at 11:10 AM, Gengik84 said:

Per non fornire quella comunemente chiamata "pappa scodellata", in caso sarebbe stato molto meglio indicare all'utente come estrarre acpi, log etc

quindi mettere binari debug, SysReport, Target ... bla bla etc... invece di passare una efi debug.

Mi intrometto al volo, senza sviare il topic. Sono perfettamente d'accordo su quanto hai scritto, anche se, per ragioni pratiche, soprattutto con utenti che sono alle prime armi, è meglio fornire una "pappa scodellata" mirata ad ottenere le informazioni di debug per evitare di "perdere tempo" sulle operazioni più cruciali. Chi è più "smanettone" poi può tranquillamente analizzare in seguito la EFI e capire nello specifico quali sono le opzioni utili al debugging (in questo caso SysReport attivo e Target su 67).

On 4/26/2021 at 11:10 AM, Gengik84 said:

Riguardo a AppleXcmpCfgLock nessuno ne vieta l'uso e di fatto può essere verificato il tutto dopo e in caso rimosso.

Ipotesi che un utente non volesse patchare il bios per proprie ragioni, inevitabilmente dovrebbe usarlo

Ci sono pareri discordanti riguardo AppleXcpmCfgLock ma personalmente sono più per l'idea della soluzione pulita. macOS richiede il libero accesso all'MSR 0xE2? Si. Allora va sbloccato ove possibile. Le patch, in quanto tali, vanno comunque trattate con le pinzette, e gli utenti che sono "temerari" e vogliono sfidare la sorte, si assumono la piena responsabilità in caso di riavvii randomici e/o altro, come accaduto al sottoscritto.

Purtroppo (e non ne faccio una colpa) la maggior parte degli utenti neanche sa nello specifico cosa sia il CFG Lock, nè tantomeno perchè serva disattivarlo. A tal proposito, proporrei di fare una sezione di Q&A sul forum, se non già presente, in cui si cerca di dare una risposta alle domande più comuni, del tipo:

- Da dove si parte con la creazione di una EFI di OpenCore? Cosa mi occorre?

- Cos'è il CFG Lock?

- ecc...

Cosa ne pensi?
Saluti
 

2 hours ago, Gengik84 said:

Figurati, nessun problema

Poi non ho un account a pagamento su gitbook, quindi ci sono molte limitazioni

come riguardo a inviti, repo, team etc..

Mi intrometto al volo: e se al posto di usare gitbook (che nella versione free è molto limitante) usaste github pages? Se la memoria non mi tradisce, Dortania usa github pages + un motore di rendering in vue (che io ricordi)

3 hours ago, Gengik84 said:

io ho lo stesso "nome" ossia TableID della tua tabella

uso proprio questo e su TableLenght ho 0

Buonasera a tutti 🙂

@Gengik84 volevo chiederti: ha senso impostare la voce "All" su true per quanto riguarda il drop della tabella ACPI delle USB?

On 3/10/2021 at 11:10 PM, LeoVanex said:

Ehh, io sono dovuto correre a soluzioni un tantino estreme, altrimenti avrei risolto con più facilità... Come scritto nella guida ho provato anch'io "setup_var", con diverse versione di grub modificate, ma NADA!!

L'unico funzionante è questo magico tool, usato anche sul mio fisso con Haswell per disabilitare il VT-d (e quindi per rimuovere la tabella DMAR dallo stack ACPI). Avendo il processore con suffisso K quella voce era nascosta/non selezionabile normalmente.

 

E pensare che RU esiste dal 1993 e lo sviluppatore è un ingegnere dei BIOS American Megatrends! (https://www.ami.com/)

Uhm addirittura disabilitare il VT-D? O_O

Personalmente lo attivo sempre e se devo avviare OpenCore (e quindi macOS) mi assicuro che DisableIoMapper sia attivo 🙂

Avere il VT-D disattivo generalmente non causa chissà quali problemi, tuttavia se vuoi sperimentare passthrough di periferiche PCIe tramite KVM su Linux é indispensabile 🙂

23 hours ago, Lorys89 said:

salve a tutti, lo uso da tempo ru.efi, e sulla mia z490 itx c ho disattivato la parte cnvi della wifi, sul dell optiplex 3060 mff che esce di serie con slot nvme gen2 l ho passato a gen3 o sul dell ice lake disattivato cfg e altre mod, ottimo tool, e complimenti per la guida. 

 

inoltre aggiungo il link all ultima versione pre release

 https://github.com/JamesAmiTw/ru-uefi/files/5796244/RU.zip

 

Potresti allegare un dump dell'output.txt (ergo chiamato Section_PE32_Image.txt)? Che io ricordi non tutte le schede madri consentono lo sblocco CNVi

1 minute ago, LeoVanex said:

Grazie! Esattamente, la cosa interessante è che le voci si possono modificare indipendentemente se sono visibili o meno sul BIOS standard 😉

Yep I know ^^

Più che altro non ho mai avuto occasione di usare in prima persona ru.efi dal momento che le modifiche che ho applicato al mio laptop le ho fatte tramite modGRUBShell.efi usando setup_var ^^

21 minutes ago, LeoVanex said:

DISCLAIMER: In questa guida andremo a modificare alcune opzioni nel BIOS, per cui NON mi assumo alcuna responsabilità in caso di brick o malfunzionamenti vari.

 

REQUISITI:

1) PC con firmware UEFI

2) Ultima versione del BIOS già installata

2) Windows per estrarre i file del BIOS (e Mac in caso ifrextract vi da problemi)

3) Chiavetta USB (qualsiasi dimensione va bene)

4) TANTA PAZIENZA E BUONA VOLONTÀ

 

1ma PREMESSA: Ciò che mi ha spinto a scrivere questa guida è stato il consiglio di @peppinix1000 e di @Gengik84, oltre alle mie avventure/disavventure raccontate nella sezione BACKGROUND!

 

2da PREMESSA: Il titolo che ho impostato al thread è abbastanza generico per 2 motivi:

1) Non ho indicato i vari produttori di laptop quali Acer, ASUS, Dell, HP, Lenovo etc..

2) La guida ha più rilevanza sui portatili, ma può benissimo essere applicata sui fissi

 

3za PREMESSA: La guida è universale sull'uso del tool RU.EFI, ma non tratta nello specifico come estrarre il BIOS su ogni computer

 

BACKGROUND:

  Reveal hidden contents

Spinto sia dalla curiosità che dal risultato ottenuto qualche mese fa da @Gengik84 nel suo laptop (https://www.macos86.it/topic/2461-hp-pavilion-ce2072nl/), mi sono cimentato a creare il mio secondo Hackintosh sul portatile HP 15-da1000nl, di cui ho già pubblicato i risultati qui ( https://www.macos86.it/topic/4165-hp-laptop-15-da1000nl/                        ).

Ho iniziato seguendo a tavolino le ottime guide di Dortania, configurando per bene la EFI, con tutte le accortezze del caso per il mio portatile. Nonostante la massima attenzione, ricordo che all'inizio il boot non partiva mai, kernel panic perenne. Girovagando qua e là in rete, ho scoperto che il problema era relativo alla grafica, in particolare DVMT Pre-Allocated. Sul mio pc, questo valore è impostato di default su 32M. macOS richede 64M o superiori.

Vado allora nel BIOS a cambiare questa impostazione e non trovo nulla a riguardo!

Provo a seguire il thread di Gengik linkato sopra, e @A23SS4NDRO suggerisce una combinazione per entrare nella modalità avanzata del BIOS (Ctrl+F10). Non va neanche stavolta. Vi risparmio le innumerevoli prove fatte, video su YouTube che suggerivano altre combinazioni di tasti... Sad story: non sono riuscito ad entrare nelle impostazioni nascoste. Per poter fare il boot con successo, ho applicato questa patch nel config.plist > DeviceProperties > iGPU

 

framebuffer-patch-enable   |   data   |   <01000000>

framebuffer-stolenmem   |   data   |   <00003001>

framebuffer-fbmem   |   data   |   <00009000>

 

Fin qua tutto ok, macOS si avvia e si installa correttamente. Se non fosse che arrivo al desktop, collego il monitor esterno 4K e la risoluzione viene limitata a 1440p. Vengo a scoprire che questo è dovuto sempre a DVMT Prealloc impostato a 32M, d'altronde sto sempre usando una patch...

 

Ho provato allora ad usare il metodo setup_var ma niente, mi esce errore come in questo caso (https://www.reddit.com/r/hackintosh/comments/g3n7ku/thinkpad_cfg_lock/)

 

Stavo per demordere, ma alla fine dopo lunghe ricerche nel web ho trovato queste risorse un po nascoste, tutte facenti riferimento a questo potente tool: RU.EFI

Ne parla anche un link di Dortania, guardare "Note 2" in fondo alla pagina, questo il link: https://dortania.github.io/OpenCore-Post-Install/misc/msr-lock.html#turning-off-cfg-lock-manually

Qua sotto, invece, linko altri riferimenti da cui ho preso spunto per capire meglio come funziona questo fantastico tool:

• https://www.reddit.com/r/hackintosh/comments/hz2rtm/cfg_lockunlocking_alternative_method/

• https://www.reddit.com/r/hackintosh/comments/k3qt2h/dell_t7810_how_to_disable_cfg_lock/

• https://homanhuang.medium.com/how-to-hack-pc-bios-cfg-unlock-412d7128d0e3

• https://www.reddit.com/r/hackintosh/comments/kdjwuh/changing_dvmt_preallocated_using_the_ruefi_expert/

• https://nstarke.github.io/0037-modifying-bios-using-ru-efi.html

 

Come potete capire da questi link, alcuni hanno usato questo tool per disabilitare il CFG Lock. In generale è meglio disabilitare sempre queste opzioni a livello di BIOS, così si possono disabilitare le eventuali patch sul config

• DVMT Pre-Allocated: 64M   ===>     Rimuovere framebuffer-patch-enable, framebuffer-stolenmem e framebuffer-fbmem

• CFG Lock: Disabled              ===>     AppleXcpmCfgLock <false>

• VT-d: Disabled                     ===>     DisableIoMapper <false>

• XHCI Hand-off: Enabled       ===>     ReleaseUsbOwnership <false>

 

Dunque, ora che avete compreso le premesse, proseguiamo con la effettiva GUIDA!

 

GUIDA: Bene, cominciamo! Elenco qui sotto gli step da eseguire

1) Scaricare il BIOS più aggiornato per il proprio portatile dal sito web per produttore

2a) Se il BIOS scaricato è in formato .bin o .rom (o semplicemente è un file binario), salta al punto 3

2b) Se il BIOS scaricato è un eseguibile .exe, estrarre il contenuto in una specifica cartella

3) Usare un tool che estrae il BIOS in formato testuale leggibile

4) Cercare nel file di testo le voci desiderate da modificare e appuntare alcuni valori

5) Usare RU.EFI da chiavetta USB e modificare manualmente i valori!

 

Per quanto riguarda i primi 3 step, le informazioni che vi mostro saranno del mio specifico portatile HP, per cui in questa fase andrò veloce 😉. Se avete il portatile di un altro OEM (Acer, ASUS, Dell, HP, Lenovo etc.), o se state usando un fisso (scheda madre: GIGABYTE, ASUS, ASRock etc.), chiaramente le schermate/tool potrebbero essere differenti. Ci sono numerose guide che indicano come fare questo, una tra tutte questa, scritta da @A23SS4NDRO, @Gengik84 e @dreamwhite (https://macos86.github.io/Estrazione-BIOS-da-exe/)

 

Step 1: Vado sul sito support > drivers di HP e scarico il BIOS più aggiornato, nel mio caso versione F.35 Rev.A. Questo è il nome del file: sp111739.exe

Step 2: Vado ad estrarre il contenuto del BIOS in una cartella specifica. Apro il file, accetto termini e condizioni, scelgo la terza opzione "Copy BIOS image to any file location. (Advanced users)"

 

  Reveal hidden contents

 

 

 

 

Il problema a questo punto è stato capire quale file .bin utilizzare per l'estrazione in formato testuale leggibile. HP piazza i file del BIOS, aggiornamenti etc. nella EFI. Dunque, ho cercato tra le cartelle e ho scoperto che il mio HP usa il file 08532.bin

Step 3: Il produttore del BIOS è Insyde, perciò ho usato questo tool: PhoenixTool (disponibile qui: https://mega.nz/file/ZxBDmAxK#f44DavumKImYgtIwmFvhHxQQSpAA11JEvOD8B1c8T74)

 

 

 

 

Ora chiudiamo il programma e andiamo su Documents\DUMP. Qui troveremo una miriade di file. Ci interessa il file che inizia con FE3542FE-*.ROM e che pesa di più

 

 

Copiamo questo file in una cartella separata

 

 

Scarichiamo questo tool ( https://github.com/LongSoft/Universal-IFR-Extractor/releases  ) estraiamo l'.exe dove è presente il file .ROM e apriamo il Prompt dei comandi

> cd Documents

> ifrextract.exe FE3542FE-C1D3-4EF8-657C-8048606FF670_905.ROM output.txt

 

Apriamo output.txt e cerchiamo la voce che vogliamo modificare nel BIOS. Partiamo da CFG Lock

 

 

Ci sono tante informazioni, noi dobbiamo appuntare da qualche parte queste

1) Offset della variabile: 0x3E

2) VarStore: 0x3

3) I valori che assume la variabile: 0x0 (Disabled), 0x1 (Enabled)     [Viene indicato che CFG Lock di default sta su Enabled]

 

Per quanto riguarda il punto 2 si deve ricavare il nome della sezione dove risiede CFG Lock e il valore GUID: cercare "VarStoreId: 0x3 ["

 

 

Bene, segnamo come nome CpuSetup e come GUID: B08F97FF-E6E8-4193...

 

Next one: DVMT Pre-Allocated

 

 

- Variabile: 0x107

- VarStore: 0x2     [Da scoprire poi il relativo Nome+GUID]

- Valore predefinito: 0x1 (32M)

- Valore da impostare: 0x2 (64M)

 

Cerchiamo "VarStoreId: 0x2 ["

 

 

- Nome: SaSetup

- GUID: 72C5E28C-7783-43A1...

 

Continuare con tutte le altre voci che si vogliono modificare...

Bene, ora scarichiamo RU.EFI tool (http://ruexe.blogspot.com/)

Lo zip è criptato, ricordatevi di copiare/incollare la password

 

Ora collegate la chiavetta usb al pc

1a) Se la chiavetta è già formattata in FAT32, skippate allo step 2

1b) Per tutto il resto, formattate l'usb in MBR, FAT32

2) Create nella root dell usb una cartella EFI e all'interno un'altra cartella chiamata BOOT. Copiate RU.efi in BOOT e rinominatelo BOOTX64.efi

 

PRIMA DI PROSEGUIRE: Questo tool ha un autonomia di 5 minuti esatti dalla prima schermata di benvenuto, dopodiché il computer si spegne e si riaccende automaticamente. Consiglio di usare un cronometro se non siete abbastanza veloci 😉 Ovviamente potete eseguirlo quante volte volete, unica cosa fate attenzione al tempo!

 

Bene, ora fate il boot da chiavetta e vi ritroverete l'interfaccia di RU!

 

Questo tool è esclusivamente navigabile da tastiera, perciò ora vi mostro come usare le varie combinazioni. Gli screenshot sono in format .bmp, aprite lo zip allegato per vedere step-by-step i vari passaggi che vi scrivo

01) Welcome screen: premere Invio

02) Questa è la schermata iniziale predefinita

[Consigliato] 03) Ctrl+L per cambiare colore all'interfaccia

[Consigliato] 04) Premere il numero indicato per cambiare aspetto (io ho scelto 1 - Monochrome)

05) Ecco l'aspetto in bianco e nero. Decisamente più discreto, ma aiuta la leggibilità del testo (e soprattutto affatica di meno le pupille, specie di notte!)

06) Alt+= per andare nelle variabili UEFI

07) Qui dobbiamo prendere dal taccuino il nome della variabile UEFI dove andare a modificare la singola opzione. Nel caso di CFG Lock è CpuSetup

08) Con il tasto PgDn (Page Down) scorrete velocemente e andate alla pagina successiva

09) Freccia Giù per selezionare CpuSetup, poi Invio

10) Qui dobbiamo raggiungere l'offset della variabile, nel mio caso: 0x3E

11) Con Freccia Giù mi sposto alla riga 0030

12) Con Freccia Destra mi sposto alla riga 0E. In alto a sinistra si può vedere l'offset dove ci troviamo (immaginate battaglia navale!). Il valore è impostato su 01 (Enabled). Per disabilitarlo premo Invio

13) Digito 0 (la selezione inizierà a vibrare)

14) Premo Invio per confermare

15) Ctrl+W per salvare la modifica. Ci viene mostrato il popup, la modifica è avvenuta con successo!

16) Alt+= per tornare alla schermata precedente

17) Ora andiamo a cambiare DVMT Pre-Allocated. Il nostro taccuino ci dice che si trova nella sezione SaSetup

18) PgDn per andare avanti di pagina (1/5)

19) PgDn (2/5)

20) PgDn (3/5)

21) PgDn (4/5)

22) PgDn (5/5)

23) Freccia Su per selezionare SaSetup, poi Invio

24) Come prima dobbiamo andare nell'offset: 0x107. Per andare avanti di pagina Ctrl+PgDn

25) Mi trovo già nella riga corretta: 0100

26) Freccia Destra per andare alla colonna 07. Premo Invio

27) Digito 2 (Valore: 64M)

28) Premo Invio di nuovo per confermare

29) Ctrl+W per salvare

 

Fine! Ora che avete modificato con successo i valori potete semplicemente premere tasto Power, scollegare la chiavetta USB ed avviare 😉

 

CONSIDERAZIONI FINALI: sebbene sia scontato, ad ogni reset CMOS queste impostazioni verrano ripristinate ai loro valori predefiniti. Inoltre, in caso di aggiornamento del BIOS, gli offset possono trovarsi in altri punti per cui bisognerà rifare l'intera guida.

RU.zip 463.37 kB · 0 downloads

Fantastica guida! I miei più sentiti complimenti per la guida di ru.efi ^^

Vorrei apportare una piccola correzione alle voci BIOS da modificare (premesso che la procedura per il patching è corretta): disabilitare alcune voci come:

- Above 4G

- CSM Support

- Serial Port

- SW Guard Extension

- TPM State

Chiaramente queste voci vanno modificate solo nel momento in cui non sono visibili nel BIOS lato GUI

49 minutes ago, A23SS4NDRO said:

Ciao, questo comportamento è perfettamente documentato in questa sezione:

 

https://dortania.github.io/OpenCore-Install-Guide/extras/kaslr-fix.html

 

 

 

 

Consiglio caldamente di seguire la guida per sistemare - in modo tale che tu riesca anche a capire perché avviene, e associare al problema che hai una causa che hai imparato a riconoscere

 

https://dortania.github.io/OpenCore-Install-Guide/

Non voglio scatenare flame di alcun genere ma usare un bootloader che è la copia carbone di OpenCore (tutti i meccanismi di iniezione di OC sono stati implementati su Clover), per di più con alcune limitazioni (vedi NVRAM/Add e NVRAM/Delete che non sono minimamente presenti) è un po' da sadici.

Problemi quali slide sono facilmente risolvibili con la guida che ha giustamente linkato @A23SS4NDRO.
Non capisco questa ostilità nei confronti di OpenCore dal momento che non ci vuole una laurea in Ingegneria Nucleare per poter "assemblare" una EFI da zero.
Software come ProperTree, in combinazione con SSDTTime e GenSMBIOS facilitano il lavoro in una maniera allucinante.
Perché uno che inizia ora con hackintosh dovrebbe iniziare con un bootloader al tramonto che copia le features di OpenCore (risultando quindi in un mero duplicato senza alcun valore aggiunto o vantaggio)?

Sarei curioso di sentire i pareri sia del team quadrifoglio che del team occhio blu della morte ahah

Aggiungo: quale motivo pone in vantaggio l'utilizzo di un bootloader vecchio nei confronti di uno nuovo e rifinito più che bene dai developers?

25 minutes ago, iCanaro said:

per caso ti sei accorto solo ora (dopo qualche mese) che con bug sur la LAN funziona peggio che windows?!

ben'arrivato, meglio tardi che mai

Mi duole dirlo ma non ho mai avuto problemi per quanto riguarda i dispositivi della LAN 😅
Sono su un laptop con scheda WiFi (non penso influisca sul discorso LAN) senza porta LAN

13 minutes ago, carlo_67 said:

e cambia posizione di caricamento

Buonasera, stavo passando per caso sul forum quando mi sono imbattuto in questo topic 😂

Premesso che non voglio puntare il dito contro nessuno in particolare, ne scatenare flame di alcun genere, avrei alcune domande da porre:

1. Perchè viene usato OpenCore Configurator? E' risaputo da secoli che i configuratori a lungo andare possono causare problemi di compatibilità con il config.plist relativo alla versione X di OpenCore. Inoltre sono closed-source peggio di non so cosa e sarebbe mille volte più saggio usare alternative come ProperTree (che include la funzione di snapshot della EFI) o PListEditPlus

2. Perchè non viene rispettato l'ordine di caricamento delle kext come scritto chiaramente nel codice sorgente di ocvalidate? (source)

Molto spesso mi è capitato di avere problemi con alcune kext proprio per l'ordine di caricamento delle stesse 😕

Veramente molto strano...

5 minutes ago, Gengik84 said:

sembra che tu faccia bene, ma non mi spiego come sia possibile che nel report vengano inserite le tabelle acpi che sono in uso ma che di fatto non sono originali (OEM) del tuo hardware

questa non è gran bella cosa...

Effettivamente non è tanto normale... Secondo me sarebbe meglio effettuare un SysReport partendo da una EFI di OpenCore debug forse?

5 minutes ago, Matteo88 said:

@Gengik84 ho effettuato la mappatura delle mie porte usb, ma ho notato che le usb3 vengono viste come usb2 e funzionano solo con una pendrive 2.0, mentre inserendo una pendrive 3.0 funziona solo nelle usb2.

le porte che dovrebbero essere funzionanti sono: SS03 e SS04 che vengono viste come HS03 e HS04.

allego ioreg dopo la mappatura e il relativo ssdtSSDT-5.aml.zipmappatura usb.ioreg.zip

@Matteo88 buonasera, domanda: hai già identificato le porte USB tramite IOREG? Non sempre c'è una corrispondenza diretta fra HS03 e SS03 (vedi Gigabyte Z390 Aorus Pro)
Nel caso tu non l'abbia fatto, disattiva temporaneamente la mappatura delle porte USB e procedi all'identificazione delle porte USB e nel caso aggiusta la mappatura

8 hours ago, Gengik84 said:

Windows nella maggior parte dei casi, ignora proprio le acpi

tanto è che per esempio se le considerasse, in molti portatili ci si ritroverebbe senza usb funzionanti perchè definite male oppure disattivate proprio nelle acpi Oem

Windows usa i driver e detto papale papale, se "ne frega" delle acpi

quei driver sono una "sorta" di injectall in hackintosh 😂

Detto questo, se ci fossero seri problemi (non  visti almeno per il momento), nessuno ti vieta, in caso, di aggiungere una condizione nelle varie usb definite per la mappatura, facendo appunto eseguire il codice solo su macOS e lasciando il resto invariato per altri sistemi

Altra cosa: calcola che i drop table non dovrebbero riversarsi su altri sistemi (se non erro), quindi è impossibile che una tabella oem patchata venga caricata senza che l'OEM originale sia bloccata

Hahaha benissimo. Grazie mille del chiarimento ^^

Grazie mille per il chiarimento ^^

A questo punto però mi sorge spontaneo un dubbio:
mettiamo caso che l'utente autore del topic in questione decida di fare un dual boot win/mac o linux/mac e avvia il sistema operativo tramite OpenCore (e che quindi inietta l'ssdt per la mappatura delle USB). Quando il sistema sarà avviato, Linux o Windows rienumereranno (godzilla had a stroke trying to write this and died) le porte USB oppure considereranno solo le porte USB definite nell'SSDT?

4 minutes ago, Gengik84 said:

l'attuale discorso della mappatura è che di fatto supera il limite, quindi 2 opzioni

1. alcune porte in esubero vengono omesse dal sistema o ssdt omesso dal caricamento

2. mantiene la patch per port limit ma in questo caso di fatto ha solo definito i connettori

 

Quindi dovrebbe scegliere quali porte "sacrificare" (qualora fossero appunto 18 quelle totali in uso), per rientrare nel limite

esempio semplice: alcune porte farle lavorare in una sola modalità, tipo due usb posteriori, dove collega mouse e tastiera farle lavorare come sole 2.0 quindi disabilitando le rispettive SSxx

facendo così siamo già a 16, quindi ne rimarrebbe una sola da sacrificare

Alright, vedrò se l'utente sarà interessato a "sacrificare" 3 porte USB e nel caso procediamo alla disattivazione delle relative porte USB.
Domanda: in termini di stabiiltà del sistema, con e senza XhciPortLimit, vi è qualche differenza? Magari mi sbaglio, ma in generale il termine patch, mi fa pensare in automatico a qualche problema che potrebbe derivarne. Saresti così gentile da chiarirmi questo stupido dubbio?
Ciao e grazie

3 hours ago, Jolly said:

Naturalmente hai ragione, penso di aver colto quello che intendi dopo una disamina meno superficiale del SSDT; porte disabilitate tramite GUPC (ZERO) e definite tramite GENG. 

Non avendo dati sulla mappatura e visto che la scelta di cosa abilitare è soggettiva non posso esprimere più di tanto. Quello che ancora non mi torna è che a me sembra che le porte abilitate siano 18. Vorrei anche capire la scelta di disabilitare HS14.

Buongiorno a tutti (mi ero dimenticato di farlo nella risposta precedente haha).
Dunque, per quanto riguarda la scelta di abilitare 18 porte, mi sono basato principalmente sul fatto che la scheda madre dell'utente, una AsRock Z490M Pro 4, ha queste porte USB nel back-panel:

Dunque, partendo da sx verso dx contiamo:

4 porte USB-A logiche (2x 3.0 e 2x 2.0 retrocompatibili)

2 porte USB-A logiche (1x 3.0 e 1x 2.0 retrocompatibile)

2 porte USB-C logiche (1x 3.0 e 1x 2.0 retrocompatibile)

4 porte USB-A logiche (2x 3.0 e 2x 2.0 retrocompatibili)

totale porte: 12 porte USB

Ora, fatta questa considerazione, bisogna includere nella mappatura anche la porta USB dell'header interno a cui è collegata la Fenvi T919 che, stando a quanto ricordi è identificata in HS13, e le porte USB presenti sul front-panel del suo case.

Rieffettuando il calcolo (ossia considerando 2 porte logiche per ogni porta USB 3.1 gen 1) si arriva alla fatidica cifra di 18 porte USB totale, che richiedono per tanto l'attivazione del quirk XhciPortLimit.

Sia chiaro, è pur sempre possibile ridurre il numero di porte USB a quelle strettamente necessarie, ma ho preferito (magari sbagliando, non so) attivare tutte le porte USB possibili 😕

Se c'è da rieffettuare la mappatura delle porte USB non c'è alcun problema. Sia @Gengik84 , così come altri staffer di macos86.it, così come tanti altri, sanno come funziona il metodo GENG e per tanto non è un problema disattivare eventuali porte 🙂

Resto in attesa di vostre ^^

dreamwhite

2 hours ago, Gengik84 said:

Non hai ben chiaro ciò che Basic fa...

Dovrei rivedermi meglio SSDT-Basic, ammetto, ma in ogni caso, non penso che sia SSDT-Basic a fare la differenza con lo sleep dal momento che il problema è relativo a questa periferica CNVW 😕 Ma magari mi sbaglio

2 hours ago, Gengik84 said:

?

Non è questo di certo

se awac ritorna 0, RTC è disattivo...

quindi deve tornare 1 😉

My bad, In ogni caso basta verificare il metodo _STA delle due periferiche e far si che sia attivo solo RTC, dal momento che macOS è compatibile solo con quello.
A giudicare dalle sue ACPI (e dal fatto che boota anche), SSDT-AWAC è corretto.
Allego foto dei metodi _STA di AWAC e RTC provenienti dal DSDT dell'utente:

DEVICE AWAC

DEVICE RTC

Per far si che RTC sia attivo e utilizzabile da macOS occorre dunque impostare la variabile STAS su One.

Ergo, va bene SSDT-AWAC presente nella sua EFI.

Se ci sono correzioni da apportare, sono più che curioso di testarle, purchè siano in grado di risolvere il problema dello sleep wake. Ne stiamo uscendo pazzi 😢

Grazie a tutti per il contributo

dreamwhite

34 minutes ago, Jolly said:

@dreamwhite

non sono in grado di controbattere, le mie conoscenze non mi permettono dì argomentare adeguatamente. Tanto per capire, ti chiedo, per favore, di spiegarmi in quel Ssdt quali sono le porte disabilitate. 

Al momento non sono al PC e non credo di accenderlo prima di domattina. Banalmente le porte disattive sono quelle il cui metodo _UPC ritorna "GUPC (Zero)".

Domani ti elenco quali sono le porte e analizziamo insieme il problema 🙂

Buonanotte

9 minutes ago, Jolly said:

Per me il problema è "SSDT-3-xh_cmsd4.aml", non è configurato. Hai messo la patch di gengik, hai rinominato qualcheGUPC e similari ma non tutti e soprattutto  non hai disabilitato neanche una porta USB

Buonasera e perdonami l'intrusione. Ho seguito personalmente l'utente in questione e non vedo motivo di dire "non hai disabilitato neanche una porta USB". Dal momento che nella sua tabella ACPI relativa alle USB (per l'appunto SSDT-3-xh_cmsd4) è definito il metodo GUPC, questi consente la disattivazione della porta impostando Arg0 su "Zero".

Secondo l’Advanced Configuration and Power Interface (ACPI) Specification, version 6.3, pagina 673, il metodo _UPC ha come valore di ritorno il seguente Package:

Return Value Information:
    Package {
    Connectable // Integer (BYTE)
    Type // Integer (BYTE)
    Reserved0 // Integer
    Reserved1 // Integer)
}

Se la matematica non è un'opinione e gli array partono da 0, impostando il primo elemento dell'array (di indice 0,  per l'appunto), su Zero, il parametro Connectable, di tipo Integer, disattiva la porta, ergo non è necessario utilizzare il metodo GENG per la disattivazione della porta.

Sia chiaro, è pur sempre possibile modificare il metodo _UPC della porta per far si che ritorni "GENG (Zero, Zero)" ma lo vedo solamente uno spreco di righe di codice, dal momento che è gia definito un metodo GUPC all'interno della tabella.

13 minutes ago, Jolly said:

Poi secondo me scaricati SSDT-Basic ed elimina tutti gli altri

Riguardo ciò, non è sbagliata come idea ma, dal momento che la sua è una scheda madre di 10 generazione Intel con chipset Z490, richiede solamente i seguenti SSDT:

- SSDT-AWAC (dal momento che ha un clock AWAC che va disattivato)

- SSDT-EC-USBX (come tutti gli hackintosh Intel di 6 generazione e successive)
- SSDT-PLUG (come tutti gli hackintosh Intel)

Analizzando il log di pmset, tramite il seguente comando, risulta che la causa del wake sia dovuta alla periferica CNVW (che per deduzione penso sia relativo allo slot m.2 WiFi chiave A+E presente sulla motherboard ma non occupato):

 

pmset -g log | grep -e "Sleep.*due to" -e "Wake.*due to"

Onestamente non so cosa pensare, dal momento che neanche via IORegistryExplorer, la periferica CNVW è presente.
Ho pensato, così su due piedi, di aggiungere un eventuale SSDT-Disable_CNVW ma non so la sua efficacia... Sarebbe da testare

Spero di aver chiarito eventuali dubbi e perchè no, se occorre qualche altro chiarimento sono più che disponibile ad aiutarti ^^

A presto

dreamwhite

8 hours ago, fabiosun said:

@dreamwhite

io ho fatto il passaggio (enroll) con Hack check che vedi sopra..e poi mi ha trovato il tutto come un normale upgrade da developer seed

 

Proverò ad effettuare nuovamente l'enroll anche se mi sembra molto strano...

Vi aggiorno

UPDATE: tramite l'utility per l'enroll di Apple non sono riuscito a scaricare l'aggiornamento per la Beta 1 di macOS Bug Sure 11.3

Utilizzando Hack Check e eseguendo la procedura per l'enroll ho risolto.

@Gengik84 deduco che molto banalmente il comando eseguito nel backend sia

sudo /System/Library/PrivateFrameworks/Seeding.framework/Versions/A/Resources/seedutil enroll DeveloperSeed

giusto?

Sono l'unico che non trova l'update nel catalog developer di Apple?