A23SS4NDRO

Correzione dello screenshot qui sopra per quanto riguarda il layout-id della scheda audio, funzionano correttamente (per ALC295) i seguenti layout-id: 13 - 28 - 77 Non 21 come risulta dalla foto (1500000 in hex swapped - little endian) Quindi consiglio di mettere: layout-id (data) 0D000000 Oppure: 1C000000 Oppure 4D000000

Puoi attivarlo tramite Devices Properties. Mando una guida: https://dortania.github.io/OpenCore-Post-Install/universal/iservices.html#fixing-en0 seguila dallo screenshot che mando in poi: Puoi usare tranquillamente DPCImanager o Hackintool:

Da aspettarci minimo un annetto prima che tigerlake sia compatibile, difatti Icelake è uscito a ottobre dell'anno scorso e solo ultimamente 0xFireWolf ha trovato modo per fare il submit delle patch su WhateverGreen con l'ultima sua PR Poi il chip WiFi 6 sarà integrato nella CPU... Se apple ha detto che rilascerà ancora macchine intel specialmente lato laptop allora si dovrà adeguare anche al WiFI intel integrato nella cpu, cosa che non è affatto male aver supporto nativo del WiFi oob

He linked his github repository

Per compilare hai aperto un tuo fork e fatto il merge e poi usato xcode (aprendo il .xcodeproj)?

I think you should test the latest whatevergreen with the latest PR merged (maybe in a couple of hours) Seems like a DVMT fix was required other than the other issues such as "Unsupported CPU/SKU" https://github.com/acidanthera/WhateverGreen/pull/64

Serve ifrextractor, è una utility che sta su https://github.com/Longsoft/Universal-IFR-Extractor Per il download: https://github.com/Longsoft/Universal-IFR-Extractor/releases

Bene a sapersi! Posso chiedere quale sia il repo su cui ora sta lavorando? Github/Bitbucket/SourceForge?

Ho capito, sarebbe stata una buona idea migrare il codice di quella PR su un suo repository privato... Quella versione che hai allegato l'hai compilata tu da OC 0.5.9? Oppure l'ha passata lui? Si chiama sempre ControlMsrE2 o esiste una versione differente (CFGLock.efi?)

Buonasera a tutti, recentemente mi sono rivisto una veccha pull request da parte di derBrumbaer e ho pensato che il suo lavoro (non integrato in OC per alcune "codestyle issues", come ad esempio l'indentazione del codice etc non piaceva a vit, che cortesemente ha segnalato cosa avrebbe voluto che fosse cambiato) ma poi derBrumbaer giustamente se l'è un po' presa per tutto il tempo che ci ha investito e tutte le osservazioni di vit9696. Inoltre, numerosi utenti hanno avuto problemi in passato ed ancora oggi nell'identificare l'offset sebbene ci siano parecchie guide, tra cui: https://github.com/dortania/OpenCore-Post-Install/blob/master/misc/msr-lock.md https://github.com/macos86/Estrazione-BIOS-da-exe/blob/master/Estrazione_BIOS_Lenovo.md https://github.com/macos86/Estrazione-BIOS-da-exe/blob/master/Estrazione_BIOS_Dell.md https://github.com/macos86/BIOS-Manual-Mode-InsydeH2O/blob/master/GuidaInsydeH2O.md Consultabili anche tramite GIthub Pages, gentilmente configurato da @Gengik84 https://macos86.github.io/Estrazione-BIOS-da-exe/#/ Ho pensato (siccome su github il test di Travis era passato) di farmi un fork dell'attuale repository di OpenCore e integrarci le modifiche che aveva proposto derBrumbaer e compilare per poter almeno vedere le potenzialità di questo tool. Utilizzo (letto dal codice sorgente ma anche presente in interfaccia se si lancia il tool da OpenShell nel caso di OC o da una qualsiasi UEFIShell) Test con laptop con CFG sbloccato: Test con laptop con CFG da sbloccare: In ogni caso allego una versione di ControlMsrE2.efi che esce da OpenCore-0.6.1-DEBUG e una versione OpenCore-0.6.1-RELEASE: Fatemi sapere se vi è stata d'aiuto, farò presenti qui di seguito i test effettuati sui modelli "problematici" sia per l'estrazione del BIOS (per trovare l'offset, cosa che questo driver fa da sé) sia per poi sbloccarlo, di fatto parecchi Lenovo avevano problemi sull'utilizzo di setup_var e simili. Chissà magari se uno sistema il codice della pull request come piace a vit magari riusciamo ad averlo mainstream... ControlMsrE2.efi-DEBUG.zip ControlMsrE2.efi-RELEASE.zip

Aggiornato un po' tutto, ultimo update di 10.15.6 19G2021 e Clover 5121, appena big sur è stabile vorrei provarci anche su una macchina così "antica/legacy"

Aggiornamento: sistemata la patch connettori per HDMI, posto qui il risultato: <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd"> <plist version="1.0"> <dict> <key>PciRoot(0x0)/Pci(0x2,0x0)</key> <dict> <key>AAPL,ig-platform-id</key> <data> CQClPg== </data> <key>device-id</key> <data> pT4AAA== </data> <key>framebuffer-patch-enable</key> <data> AQAAAA== </data> <key>framebuffer-con1-enable</key> <data> AQAAAA== </data> <key>framebuffer-con2-enable</key> <data> AQAAAA== </data> <key>framebuffer-con1-alldata</key> <data> AQEJAAAIAADHAQAA </data> <key>framebuffer-con2-alldata</key> <data> AgAKAAAEAADHAQAA </data> </dict> </dict> </plist>

Domanda, ma per gli NVMe non ci stà già supporto TRIM nativo? Comunque grazie a @dreamwhite ed a @ArisCuber19 ho trovato che è possibile trovare il path PciRoot dell'NVMe e metterlo in DevicesProperties con sotto la stringa "built-in 01" senza dover abilitare la patch kernel... Il trim viene difatti abilitato di default per tutti gli NVMe impostati come built-in, posso confermare i test sia sul 970 evo (non ufficiale apple senza patch con TRIM nativo) che sul WD Black NVMe da 250GB anche lui nativo built in (non ufficiale Apple con trim abilitato senza alcuna patch e senza trimforce enable)

https://dortania.github.io/Anti-Hackintosh-Buyers-Guide/Motherboard.html

Purtroppo il problema sta nell'aver scelto il binomio letale Z390+Gigabyte