dreamwhite

Ci tenevo a precisarlo per coloro che si ostinano ad utilizzare la KernelPatch ^^

Salve a tutti, Vorrei far notare a tutti gli utilizzatori di questa patch... che esiste una soluzione migliore, come sottolineato proprio oggi da vit9696 nell'issue 1341 Link topic errato:

ah no? beh il firmware non è legato indissolubilmente al bootloader ed al relativo meccanismo di iniezione dell'smbios?

Salve a tutti, da ormai 1 anno che sono entrato nel mondo dell'hackintoshing, mi sono sempre incuriosito sul funzionamento del kext EFICheckDisabler. Per chi non lo sapesse, questo kext disabilita (in qualche modo) il controllo che viene effettuato sui veri Mac per prevenire modifiche firmware indesiderate. Vi lascio una foto dell'errore che potrebbe comparire La mia domanda è: su Clover questo kext era più o meno importante, visto il meccanismo di iniezione dell'SMBIOS. E su OpenCore invece? Ha ancora senso utilizzare questo kext? Grazie a tutti e buona giornata

Update nr. boh: probabilmente la causa per cui non riusciamo a mappare la porta DP della mobo è che l'utente utilizza un adattatore DP-HDMI. Per il momento non gli interessa il secondo monitor ma sta valutando l'acquisto (previa vendita della sua vecchia GPU 2070S) di una GPU compatibile

Update: siamo riusciti a mappare la porta HDMI (con1) con il BusID 1. Ora tocca alla displayport sperando che funzioni senza alcun problema

Perfetto! Ti farò sapere appena l'utente testa i seguenti config, che lascio qui allegati. Mi sono basato sul dump del framebuffer relativo all'AAPL,ig-platform-id 0x3E9B0000: ID: 3E9B0000, STOLEN: 57 MB, FBMEM: 0 bytes, VRAM: 1536 MB, Flags: 0x0000130B TOTAL STOLEN: 58 MB, TOTAL CURSOR: 1 MB (1572864 bytes), MAX STOLEN: 172 MB, MAX OVERALL: 173 MB (181940224 bytes) Model name: Intel HD Graphics CFL CRB Camellia: CamelliaDisabled (0), Freq: 0 Hz, FreqMax: 0 Hz Mobile: 1, PipeCount: 3, PortCount: 3, FBMemoryCount: 3 [0] busId: 0x00, pipe: 8, type: 0x00000002, flags: 0x00000098 - ConnectorLVDS [1] busId: 0x05, pipe: 9, type: 0x00000400, flags: 0x00000187 - ConnectorDP [2] busId: 0x04, pipe: 10, type: 0x00000400, flags: 0x00000187 - ConnectorDP 00000800 02000000 98000000 01050900 00040000 87010000 02040A00 00040000 87010000 Configs.zip

Utilizzando il config.plist allegato ho riscontrato un problema strano: Se la boot mode è "UEFI only" il sistema riconosce solo 7MB di VRAM Se la boot mode è "UEFI + Legacy" il sistema va in blackscreen... config.plist.zip

No in effetti ha 64MB di DVMT da bios (purtroppo MSI è molto castrata da questo punto di vista). Domanda: ho notato che hackintool ha già la patch grafica per i connettori della stessa scheda madre dell'utente. E' il caso di provarla o faccio manualmente la patch grafica?

d'accordo dai. alla fine la cosa che farò è riapplicare l'iGPU bus id patching sperando che funzioni tutto come si deve

mmmmh ok. una domanda: la boot mode deve essere impostata su "UEFI + Legacy" o solo "UEFI"?

Quindi consigli di mettere il platform-id 0x3E9B0000 (visto che viene consigliato da dortania proprio in riferimento ai black-screen) + device-id? Se si, quale device-id devo mettere?

Buon pomeriggio a te Gengik, si: in effetti nel config da me allegato non risultano le patch ma fra i vari test effettuati ho caricato solo le seguenti proprietà: - AAPL,ig-platform-id 0x3E9B0007 o 0x3E9B0000 - framebuffer-patch-enable 01000000 Da ioreg risulta che il platform-id è 0xFFFFFFFF ioreg -l | grep ig-platform-id

Salve a tutti, sto assistendo un utente nella creazione del suo hackintosh. Di seguito le specifiche hardware: - CPU: Intel Core i7-9700K - Mobo: MSI Z390I Gaming Edge AC - GPU: Nvidia RTX 2070S (disabilitata da BIOS) Siamo riusciti ad installare Catalina 10.15.7 ma abbiamo problemi circa l'attivazione dell'accelerazione grafica. Siccome il setup è only-iGPU e la CPU è di generazione Coffee Lake, l'SMBIOS più appropriato (stando alle specifiche di everymac) è iMac19,2 ma abbiamo provato anche con iMac19,1. Abbiamo provato di tutto e di più per abilitare l'accelerazione grafica ma il platform-id (0x3E9B0007 o 0x3E9B0000) non viene minimamente rilevato. Vi allego la EFI qualora vi possa essere d'aiuto:EFI.zip Avete idee? Grazie mille e buona giornata a tutti

Non voglio alimentare il flame ma la soluzione ideale è quella che porta al medesimo risultato senza fare diecimila giri 😉

Per curiosità personale, sai cos'è il TRIM? Sai che interazioni possono esserci fra il firmware dell'ssd e il sistema operativo? Detto ciò, la soluzione ideale, come suggerita da @A23SS4NDRO è quella di applicare una property "built-in" "01" sul PciRoot Path dell'NVMe. Una soluzione pulita e non invasiva come magari potrebbe essere una patch kernel poco documentata

😅 non avevo specificato che nonostante abbia provato ad applicare la patch al framebuffer (tramite DeviceProperties e aggiungendo manualmente le voci), e ai connettori, comunque non riusciamo ad avere 1536MB di accelerazione grafica. Abbiamo provato i seguenti AAPL,ig-platform-id: - 0x3E9B0007 - 0x3E9B0000 con device-id 0x3E9B. Nonostante ciò, se proviamo a bootare abbiamo 31MB di accelerazione grafica, oppure il pc si riavvia. Sono consapevole che le Gigabyte abbiano problemi di Memory Video Map, ma non pensavo fossero così complesse da patchare. Come ultima prova ho generato la patch del framebuffer usando Hackintool (menù Patch, System Configs, Gigabyte, Z390 Designare v1 e v2): Mi verrebbe da provare ad impostare Macmini8,1 come SMBIOS ma non penso sia quello appropriato. Meglio iMac19,2 Grazie mille per l'aiuto

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!