dreamwhite

Salve a tutti, apro questo topic in quanto sto riscontrando dei problemi nell'attivazione dell'accelerazione grafica della iGPU di un i7-9700K. In questi giorni sto aiutando un utente nel configurare il suo hackintosh. Più nello specifico, ha acquistato il seguente hardware: MOBO: Gigabyte Z390 Designare CPU: I7-9700K Il sistema operativo installato è macOS Mojave 10.14.6 e stiamo riscontrando dei problemi nell'attivazione dell'accelerazione grafica. Abbiamo usato OpenCore come bootloader e abbiamo provveduto a sbloccare il CFG Lock. La cosa strana è che pur giocando fra le impostazioni del DVMT, non riusciamo ad ottenere i famosi 1536MB di VRAM. Pur togliendo -igfxvesa la VRAM riconosciuta è di 7/31MB, quindi con conseguenti artefatti grafici et similia. Vi allego le impostazioni del BIOS relative alla iGPU e la EFI di OpenCore 0.5.9 con -igfxvesa (da aggiornare ovviamente) creata da me medesimo. Grazie mille per chi sarà d'aiuto ❤️ EFI.zip

Salve a tutti, premesso che l'autore originale di questa guida è @Gengik84, ho deciso di riscrivere la stessa per evitare confusioni o altro. La seguente guida si applica solo a piattaforme con processore Intel e con bootloader OpenCore (odio Clover xD). In seguito vedrò di pubblicare una guida per piattaforme AMD. La prima domanda che sorgerà spontanea a tutti: "perchè mai mappare le porte USB?" Cito testuali parole di Aleksandar Vacić, prese da un articolo sul suo blog: "When you choose some Mac model to emulate – say iMacPro1,1 – macOS will load USB hardware map for that particular machine. Apple knows exactly what their models use as hardware configuration so they don’t really need to scan for available ports or other hardware (like Windows or Linux must do). Everything is known before-hand. One thing they know is that none of their machines have more than dozen ports per USB controller thus in 10.11 (El Capitan) they introduced hard limit of 15 ports per controller." Per coloro che hanno difficoltà a tradurre, banalmente questo trafiletto dice: "Quando decidi un SMBIOS da emulare - diciamo iMacPro1,1 - macOS caricherà la mappatura USB per quella particolare macchina. Apple sa a memoria le configurazioni hardware delle sue macchine perciò non ha bisogno di scansionare le porte di altri hardware (come invece è fatto per Windows e Linux). Tutto è noto in anticipo. Una cosa che loro sanno bene è che nessuna delle loro macchine ha più di una dozzina di porte USB per singolo controller, così a partire da macOS 10.11 El Capitan, hanno introdotto un limite fisso di 15 porte massimo per controller". Q: Ok e quindi? Cosa me ne potrebbe importare? A: Se hai più di 15 porte USB (contando le porte USB 2.0 e 3.0), potresti avere addirittura qualche porta disattiva, qualora queste superino il limite prestabilito. Nel corso della guida verrà spiegato come calcolare il numero di porte USB presenti sulla propria macchina ed eventualmente come aggirare il limite delle 15 porte USB. Requisiti Sito e manuale della scheda madre/laptop Dispositivo USB 2.0 (un mouse, una tastiera et similia) Dispositivo USB 3.0 (una chiavetta USB 3.0, un HDD esterno et similia) Chiavetta USB su cui mettere OpenCore Tabelle ACPI estratte tramite SysReport MaciASL Hackintool Saper montare una partizione EFI Modificare il config.plist di OpenCore Iniziamo Come prima cosa è bene contare le porte USB presenti sulla propria macchina seguendo il seguente criterio: le porte USB 2.0 vengono contate come porte singole le porte USB 3.0 vengono contate come se fossero due porte USB, per via della retrocompatibilità eventuali periferiche collegate agli header interni della scheda madre vengono contate come porte singole (esempio: porte del front panel del case o Fenvi T919) non rientrano nella mappatura eventuali porte del controller ASMedia non rientrano nella mappatura eventuali HUB USB collegati alla macchina: questi sono pur sempre collegati ad una singola porta USB Esempio Scheda madre: Asus Z370 Prime A II (link sito) Secondo la pagina ufficiale della scheda madre abbiamo fino a 12 porte USB (inclusi gli header USB della motherboard): La seguente è una foto del back panel della scheda madre stessa: Procedendo da sinistra verso destra e dall'alto verso il basso, possiamo contare ben: 1 porta USB 3.1 Gen 2 Type-A, appartenente al controller ASMedia (la porta color verde acqua) 1 porta USB 3.1 Gen 2 Type-C, appartenente al controller ASMedia (la porta Type-C) 2 porte USB 2.0 Type-A 2 porte USB 3.1 Gen 1 Type-A Q: Dunque quante porte della scheda madre dobbiamo mappare? A: Escludendo le porte appartenenti al controller ASMedia, dobbiamo mappare le 2 porte USB 2.0 Type-A e le due porte USB 3.1 Gen 1 Type-A, per un totale di 6 porte USB: 2 porte USB 2.0 4 porte USB (2 USB 3.0 e le due porte USB 2.0 retrocompatibili con le USB 3.0) N.B. Qualora il numero di porte USB calcolate sia superiore a 15, bisogna abilitare il quirk config.plist/Kernel/Quirks/XhciPortLimit 1. Estraiamo le tabelle ACPI Prima di spiegare come estrarre le tabelle ACPI ci terrei a ringraziare @A23SS4NDRO per il testing di questa procedura. Per prima cosa, scaricare la EFI di Debug di OpenCore e dopo averla messa nella partizione EFI della chiavetta USB, avviare il PC dalla stessa. Compariranno diverse scritte: non c'è motivo di temere. Una volta arrivati al boot-menu spegnere il PC, riavviare su macOS e montare la partizione EFI della USB. Oltre alla cartella EFI precedentemente posizionata, troverete due nuovi elementi: cartella SysReport opencore-DATA_DI_OGGI.txt Il risultato è simile alla seguente foto: Arrivati a questo punto, aprire la cartella SysReport/ACPI e identificare la tabella ACPI contenente la mappatura delle porte USB. Q: Come diamine identifico questa tabella? A: Generalmente la tabella ACPI che definisce il comportamento delle porte USB si chiama SSDT-xxxxxx.aml: aprire ogni singolo file che si chiama così e cercare "HS01". Iterare questo procedimento finchè non viene identificata la tabella giusta. Qualora non sia stato possibile identificare la tabella ACPI, ripetere il procedimento appena spiegato con il file chiamato DSDT.aml Esempio: nel mio caso la tabella ACPI che definisce il comportamento delle porte USB si chiama "SSDT-2-xh_OEMBD.aml". So per certo che è la tabella ACPI giusta dal momento che fra le external references ci sono le varie porte USB disponibili sulla mia scheda madre Q: Ok. e adesso cosa faccio? A: Adesso occorre identificare il nome delle porte USB tramite Hackintool. E' bene iniziare dalle porte del back panel per poi procedere con le porte del front panel 2. Identificazione delle porte USB tramite Hackintool Aprire Hackintool e recarsi nella sezione USB: Cliccare sull'icona della scopa ed in seguito cliccare sull'icona del refresh button. Il risultato è simile alla foto di cui sopra. Arrivati a ciò, staccare ogni periferica USB esterna collegata al PC (mouse, tastiera ecc...). Prendere una periferica USB 2.0, come da requisiti, e collegarla ad una porta USB del back panel. Iterare questo procedimento per ogni porta USB. Il risultato dovrebbe essere simile al seguente: Nel mio caso, le seguenti porte USB2.0 sono state testate: HS01 (è la porta retrocompatibile USB3.0) HS03 HS04 (è la porta retrocompatibile USB3.0) HS06 (lettore schede microSD) N.B. non tutti i lettori di schede (micro)SD sono mappabili via USB. Dipende dalla motherboard in questione. Fanno eccezione le seguenti porte, che sono interne alla motherboard (nel mio caso un laptop): HS05 HS07 Ripetere la procedura per le porte USB 3.0 e segnarsi le porte. Nel mio caso: Le porte USB 3.0 sono: SS01 SS03 SS04 3. Mappare le USB modificando il metodo _UPC Prima di mappare le porte USB è bene segnare da qualche parte il valore della "Table Length", che trovate in cima al file, come da foto: Nel mio caso, la Table Length ha un valore di 1879. E' bene ricordare questo valore perchè servirà in seguito per caricare la mappatura patchata. Iniziamo la mappatura aggiungendo il metodo GENG tramite il menù patch. Trovate in allegato la patch: patch.txt.zip Applicate la patch e cercate la prima porta USB 2.0 della lista che avete appuntato prima. Esempio: "HS01" Nel mio caso, le porte USB sono definite come segue: 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) } Dove: Connectable è un valore booleano che disattiva/attiva la porta USB (rispettivamente 0/1) Type specifica la tipologia di connettore USB Per semplificarvi la vita ho creato un elenco di valori di Type N.B. lo "switch" presente nella porta USB identificata dal tipo 0x09, sta ad indicare che la porta assume il comportamento di una USB3.0 in funzione del verso in cui viene inserita la periferica Q: Dunque come mappo? A: Devi cambiare il valore di ritorno del metodo "_UPC" come segue: le porte USB 2.0 sono identificate dal nome "HSxx" e come valore di Type "0x00" se sono porte USB 2.0 appartenenti al back panel, altrimenti "0xFF" (esempio: la Fenvi T919 ha come Type 0xFF) le porte USB 3.0 sono identificate dal nome "SSxx" e come valore di Type "0x03" o addirittura 0x07 qualora sia presente l'icona di una batteria di fianco alla porta stessa (che sta ad indicare "powered") non occorre modificare il metodo "_UPC" per eventuali porte USB Type-C Dunque nel caso di una porta USB 2.0 presente sul back panel, avrò un risultato simile a quanto segue: dove il primo parametro - "One" - sta ad indicare che la porta è attiva, mentre "Zero" indica la tipologia di connettore. Iterare questo procedimento per ogni porta USB 2.0 del back panel. N.B. Per le porte USB 2.0 del front panel il valore di Type deve essere "0xFF": Per le porte USB 3.0 invece, il valore di Type è "0x03" (o in casi estremi "0x07"): Per tutte le altre porte USB non rilevate dalla mappatura (ossia quelle non evidenziate in verde su Hackintool) assicurarsi che il metodo "_UPC" ritorni il valore "GUPC(Zero)". Esempio: Una volta conclusa la mappatura delle porte USB, salvare il file e posizionarlo nella cartella "OC/ACPI" della EFI. Infine, aprire il config.plist e, dopo aver aggiunto l'SSDT della mappatura USB (consiglio l'utilizzo di OC-Snapshot) recarsi nella sezione ACPI/Block e aggiungere quanto segue: Sostituire il valore del campo "OemTableId" con il "Table Id",che è possibile ricavare dallo step 3 alla voce "OEM Table Id", convertito in esadecimale. N.B. per evitare il drop di tabelle ACPI indesiderate, consiglio vivamente di lasciare vuoto il campo "OemTableId" ed utilizzare il campo "TableLength" Salvare il config.plist e riavviare. Per assicurarsi che la mappatura delle porte USB sia andata a buon fine, ripetere lo step 2 ed assicurarsi che siano presenti ed evidenziate in verde solo le porte USB mappate. Credits Ci tengo a ringraziare particolarmente: @Gengik84 per il suo thread originale (link) e la patch GENG che ho convertito in patch MaciASL @A23SS4NDRO per avermi aiutato con OpenCore e la creazione della EFI di Debug Il progetto ACPICA Apple Acidanthera per lo sviluppo di OpenCore e MaciASL Headkaze per lo sviluppo di Hackintool EFI OC 0.6.0 Debug.zip

Giusto! Ti faremo sapere. grazie ancora

Sull'alimentatore non vedo come possa essere vincolante dal momento che è fra i migliori disponibili sul mercato 😄 La motherboard già è stata cambiata da una TUF Gaming Plus II ad una Z370 Prime A II. La GPU è stata mandata in RMA e non ha mostrato alcun segno di cedimento hardware. L'ssd è stato cambiato da un samsung (non ricordo ora il modello preciso) con un Silicon Power (lo stesso di @A23SS4NDRO). Le RAM sono state controllate con Memtest86+ e non hanno evidenziato alcun problema sia con che senza XMP attivo. L'unica componente che non è mai stata cambiata è la CPU ma mi sembra assurdo dal momento che la macchina non ha alcun genere di freeze... Si potrebbe fare un tentativo cambiando la CPU con un i7-9700K ma sta a @dangiadecidere se sborsare altri soldi (dopo aver recuperato quelli del 9700).

Mah, mi sembra assurda questa cosa, dal momento che stesso @A23SS4NDRO ha la stessa macchina e stesso SSD e non ha avuto problemi di alcun genere :haha: Però nel caso proviamo

Buongiorno a tutti. Abbiamo provato (invano) ad effettuare l'aggiornamento a Catalina 10.15.6 tramite SWUpdate da macOS. Così come il sistema si riavvia così panica, e non riusciamo a darci una spiegazione. (la prova da fare sarebbe quella di abilitare AppleDebug e ApplePanic e rimettere Catalina 10.15.5). La soluzione è stata di creare una chiavetta clean di Catalina 10.15.6 e mettere la EFI di OpenCore vista 100mila volte da me e @A23SS4NDRO. Nel mentre che cerchiamo di venirne a capo, avete mai avuto esperienze del genere?

Signori, sono lieto di annunciarVi che Hackintosh.Zone è ufficialmente morto. Keep Vanilla away from those niresh-fags

Grazie mille!

D'accordo, quindi, se ho capito bene (correggimi se sbaglio): Per usare AGPMInjector posso usare tranquillamente WeG. Per usare invece RadeonBoost devo togliere WeG e AGPMInjector. Giusto?

Come speravo, siamo riusciti a risolvere i problemi di KP post spegnimento, dopo aver ricontrollato meticolosamente le impostazioni del BIOS ed i Quirks della sezione Booter. Di seguito i quirk attivi: Dichiaro "conclusa" questa EFI 🙂

Provo con DevirtualiseMmio disattivato. Per quanto riguarda RebuildAppleMemoryMap (e di conseguenza SyncRuntimePermissions) non penso occorra abilitarlo dal momento che ha MAT Support impostato su 0. Provo ad abilitare ProtectUefiServices

Salve a tutti, sto aiutando un utente col seguente hardware: CPU: i5-6500 GPU: Intel HD Graphics 530 MoBo: Gigabyte H170-HD3 Stiamo effettuando la conversione a OpenCore 0.5.9 ma ci blocchiamo al boot sempre sulla seguente schermata: Allego la EFI che ho creato: EFI.zip Dal log di OpenCore Debug non ha il MAT Support. Allego il log: OC DEBUG.zip Avete idee per risolvere questo problema? Grazie mille in anticipo 🙂

Salve a tutti, assieme ad @A23SS4NDRO abbiamo aiutato un utente a mettere macOS Catalina 10.15.5 sul suo PC: Mobo: Asus ROG X570-F CPU: Ryzen 7 3700X GPU: Sapphire Radeon RX5700XT Nitro+ La EFI è stata creata seguendo la guida di dortania Prima di effettuare l'aggiornamento del BIOS all'ultima versione disponibile, il sistema superava la fase del "pre-verbose" ma si bloccava subito dopo su "RTC: Online single RAM bank". Allego foto del blocco: (bastava un npci=0x2000 per risolvere...) Aggiungo inoltre che: con quella versione di BIOS potevamo disabilitare il Secure Boot molto semplicemente. Dopo aver effettuato un aggiornamento del BIOS UEFI all'ultima versione disponibile (2407 del 2020/07/03), e averlo configurato, sono sorti i primi dubbi: Con la nuova versione del BIOS UEFI ci sono due stati del Secure Boot: - Enabled (che indica che è attivo) - Setup Avete idee su come disabilitarlo? Noi abbiamo provato usando "install all keys" sull'ssd e successivamente cancellando tutte le chiavi: In ogni caso, dopo aver impostato "Secure Boot state" su "Setup", non siamo riusciti a superare la fase del "pre-verbose". Allego foto del blocco (chiedo venia per la qualità): Fra le numerose prove che abbiamo fatto, disabilitando il booter quirk "SetupVirtualMap" (che di norma dovrebbe essere abilitato), siamo riusciti ad avviare e successivamente installare. Tuttavia, nel momento in cui si prova a spegnere il PC, il sistema panica. Allego foto: Allego la EFI e il dump di SysReport: EFI.zip SysReport.zip Non riusciamo a spiegarci il perchè non siamo in grado di bootare se "SetupVirtualMap" è attivo... Avete qualche idea a riguardo? Grazie mille a tutti ❤️

Fantastico, grazie mille! Dunque se ho capito bene, AGPMInjector e RadeonBoost.kext sono pressoché la stessa cosa?

Buonasera a tutti, avrei alcune domande da porvi in merito a questo famigerato "RadeonBoost.kext". In particolare, leggendo da https://forums.macrumors.com/threads/tired-of-low-geekbench-scores-use-radeonboost.2231366/, risulta che non è necessario utilizzare WeG per la 5700Xt (e le altre schede della famiglia 5x00Xt). Mi viene spontanea una domanda a questo punto: WeG ha introdotto il boot-arg "agdpmod=pikera" che fixa i problemi di blackscreen dopo la prima fase di boot (in maniera "rozza": "blackscreen dopo la mela"). Se non bisogna usare WeG per il corretto funzionamento del kext "RadeonBoost", come si applica la patch del boot-arg "agdpmod=pikera"? Inoltre, i rename che applica WeG come verranno gestiti senza lo stesso kext? Bisogna ricorrere a delle patch tramite SSDT? Inoltre, ci sono particolari differenze rispetto ad AGPMInjector? Entrambi promettono di aumentare lo score di Metal (e di conseguenza di OpenCL). Sapreste delucidarmi meglio sull'argomento? Grazie mille ❤️

Buon pomeriggio a tutti, da una prima analisi del kext IO80211Family.kext presente su Big Sur ho subito notato che è stato deprecato il kext "AirportBrcm4360", essenziale per il corretto funzionamento della scheda BCM94360CS2. Ciò non si applica tuttavia alla Fenvi T919, che fortunatamente usa il kext AirportBrcmNIC. Lascio in allegato entrambi i kext IO80211Family.kext relativi alle versioni 10.16 e 10.15.5 Da una serie di test ho dedotto che l'unico modo per far funzionare questa scheda, è quello di disabilitare completamente la SIP, (E7030000) e sostituire il kext IO80211Family.kext con quello presente sull'ultima versione di Catalina ad oggi presente, ossia la 10.15.5. Spero che con AirportBrcmFixup si riuscirà a risolvere qualcosa, dal momento che il boot-argument "brcmfx-driver=1" forza il caricamento del kext AirportBrcm4360. A presto dreamwhite Big Sur 10.16 IO80211.zip Catalina 10.15.5 IO80211Family.kext.zip

Come promesso, ho provveduto a caricare la mia EFI di OpenCore 0.5.9 sul mio repository di GitHub. Se avete suggerimenti per migliorare la stessa, feel free to contribute 😄

CoolStar, così come Acidanthera e i vari contributori, contribuirà allo sviluppo della nuova release di OpenCore 0.6.0. Da InsanelyMac (Link thread) ho appreso che la DW1830 (e forse anche la DW1560) continuerà a funzionare regolarmente su macOS Big Sur. C'è da vedere se la BCM94360CS2 continuerà a funzionare dal momento che vengono caricati entrambi i kext per Airport: AirportBrcmNIC e AirportBrcm4360.

AHHAHAHAHHA ti capisco. Non voglio fare ulteriori commenti che già quelli di ieri sono bastati. Proverò quel kext con l'XMP attivo e ti farò sapere. ancora grazie 😄

Tu dici? Ora che ci penso forse potrebbe essere questo: siccome l'XMP è attivo e in passato ho riscontrato problemi con l'XMP, forse abbiamo una chance con questo kext. Farò le prove del caso e ti terrò aggiornato. Per quanto riguarda le versioni di OC diverse, la versione presente nella "EFI INNOMINABILE" è una pre-release di OC 0.5.9 (che in teoria dovrebbe uscire oggi (?))

Buonasera (anzi notte) a tutti. Questa odissea non finisce mai 😂. Stiamo cercando di capire perché la EFI di @A23SS4NDRO dia questi problemi assurdi di freeze mentre quella del gruppo dell'innominabile no. Allego le due EFI. Quello che noto di diverso (aldilà degli SSDT per serie Z390 quando @dangia ha una Z370) risiede nell'SMBIOS (iMacPro1,1). La domanda che ora mi sorge spontanea è: per un i7-9700 + RX580 quale sarebbe l'SMBIOS più appropriato? iMac19,1 o iMacPro1,1? Sia io che @A23SS4NDRO abbiamo sbattuto la testa ovunque per questa caspita di EFI con OC senza arrivare a risolvere i famosi problemi di freeze improvviso. @Gengik84 illuminaci 👏 EFI ALE.zip EFI INNOMINABILE.zip

capisco, e posso confermare anche questa teoria dato che su alcune schede madri potrebbe dare problemi weg, in particolare con le gigabyte. Ha provato a patchare un connettore alla volta come da guida di dortania? https://dortania.github.io/OpenCore-Desktop-Guide/extras/gpu-patches.html

nella pratica?

Perdonatemi l'intrusione, ma in teoria WhateverGreen non dovrebbe applicare già di suo le patch per patchare il framebuffer?

Sisi infatti. La mia ipotesi (e penso che forse sia la più plausibile) è che le ACPI devono cercare di interfacciarsi con la maggior parte degli OS aka: cerchiamo di garantire compatibilità con quello che è possibile