dreamwhite

Salve a tutti, di recente ho aiutato un utente ad installare macOS Big Sur 11.5.1 (20G80) sulla seguente build: CPU: i7-10700K MOBO: Asus ROG Z490-E GPU: Sapphire Radeon 5700Xt RAM: 32GB HyperX Predator 3200MHz Il sistema funziona correttamente con iMac20,1, fatta eccezione per l'export di video in formato H.264 che abbiamo testato con Final Cut Pro X e iMovie. Chi lavora nell'ambito video sa bene come H.264 e HEVC siano essenziali per la compressione video. Purtroppo, non sono ancora riuscito a far funzionare l'export in H.264 nonostante abbia configurato il BIOS correttamente (iGPU Multi Monitor attivo, DVMT Pre-allocated a 128MB e RC6 Render Standby disattivato), così come la EFI che allego di seguito: EFI.zip Sotto suggerimento di @A23SS4NDRO ho riletto meglio l'issue 190 di dortania/bugtracker e ho testato CPUFriendDataProvider fornito da vit9696 sul suo thread di AppleLife invano. Allego per comodità il kext generato da vit9696: CPUFriend vit9696.zip Allego inoltre uno screenshot (scattato con Big Sur 20F71) di VideoProc che conferma l'accelerazione della iGPU: Ho controllato più e più volte l'AAPL,ig-platform-id che WhateverGreen ha calcolato automaticamente per la modalità headless ed è 0300C89B che è coerente con quanto descritto nel FAQ.IntelHD.md di WhateverGreen ID: 9BC80003, STOLEN: 0 bytes, FBMEM: 0 bytes, VRAM: 1536 MB, Flags: 0x00001000 TOTAL STOLEN: 1 MB, TOTAL CURSOR: 0 bytes, MAX STOLEN: 1 MB, MAX OVERALL: 1 MB Model name: Intel HD Graphics CFL Camellia: CamelliaDisabled (0), Freq: 0 Hz, FreqMax: 0 Hz Mobile: 0, PipeCount: 0, PortCount: 0, FBMemoryCount: 0 Avete idee su come risolvere? Mi preoccupa fortemente che H.264 non funzioni su piattaforme Comet Lake, nonostante questo sia l'unico utente che ha avuto problemi con H.264. Grazie mille in anticipo e buona serata dreamwhite

Senza un dump delle ACPI fatto tramite il SysReport di OpenCore, è pressochè impossibile iniziare a parlare di EFI...

Buonasera, scusatemi per l'orario ma vorrei partire con una premessa: non ho (abbiamo) mai avuto intenzione di denigrare il vostro lavoro, ne tantomeno screditarlo 😅. Anzi! Proprio per evitare malintesi abbiamo sottolineato come la "PR" non sia un nostro lavoro, quanto un vostro (cito Gengik, così come chiunque abbia contribuito alla scrittura di quell'SSDT). Ho allegato il link del topic su macOS86 anche per dimostrare come non fosse assolutamente farina del mio (nostro) sacco. Rispondo al "Vi avrei aiutato in cosa?" con una domanda: c'è un motivo se Gengik, e/o altri staffer di macOS86, consiglino tutt'ora l'utilizzo di SSDT-Basic, SSDT per giunta pubblico - cito le parole di foskvs - per giunta decompilabile e tranquillamente analizzabile. Giusto? 😅 Riguardo ai nomi, proprio per evitare di screditare e rubare il lavoro altrui, come accaduto altrove (ssdt serie 300 et similia di HL ykwim), abbiamo mantenuto intatto il metodo BSTA. Dispiace e non poco questo "attacco" pubblico. Spero si risolva nel migliore dei modi, eventualmente con la correzione del testo delle issue sottolineando ancor di più come il nostro """"lavoro"""" non sia altro che aggiungere un metodo, per giunta scritto da voi (Gengik e/o altri staffer di macOS86). In futuro prenderemo nota e chiederemo prima di agire 😕 Buona serata 😛 P.S. forse l'utilizzo di "with the help of Gengik84" è inappropriato. Era meglio scrivere "we took the BSTA method from Gengik84 topic ecc"

Salve a tutti, stavo navigando fra le varie voci del mio BIOS quando mi sono reso conto che il VT-d era disattivato. L'ho riattivato e per pura curiosità ho provato a bootare con il quirk DisableIoMapper disabilitato. Non ho avuto alcun genere di problema nel boot ma ho notato che in IORegistryExplorer c'è una nuova voce chiamata AppleVTD. Ho fatto alcune ricerche prima sul Configuration.pdf di OpenCore, poi su Google e ho notato che il VT-d può essere lasciato attivo, senza il quirk DisableIoMapper attivo, purchè venga modificata la tabella DMAR. So bene che il forum che citerò a breve non è tanto gradito, ma a quanto pare è l'unica fonte di "informazione" che ho trovato, in cui molte persone hanno confermato il corretto funzionamento di adattatori WiFi, così come periferiche TB3 (per lo più relative a schede audio). Di seguito il link del thread di moneygrabberx86 per maggiori info. Mi viene spontaneo chiedere: ha senso tutto ciò? E' corretto che AppleVTD venga caricato? Quali potrebbero essere i problemi derivanti da questo kext caricato? Purtroppo in rete non sono ancora riuscito a trovare informazioni a riguardo, per tanto chiedo ai più esperti di fornirmi gentilmente una spiegazione 😅 Grazie mille in anticipo per le risposte e buona serata dreamwhite

La butto li: hai testato gli altri layout-id? Hai visto se HPET sia necessario o meno? In alcuni casi disattivando il device HPET sono riuscito a risolvere ^^

Comunque, piccola precisazione: _STA è un metodo, non una variabile, ergo non è corretto usare l'operatore di assegnazione Name 😄

Certo, più che altro il mio discorso volge all'ottimizzazione. Prendiamo ad esempio SSDT-PLUG: possiamo sia usare quello generico, che fa una serie di If CondRefOf, oppure usare quello specifico per il proprio hardware. Differenze all'atto pratico non ne sono, fatta eccezione forse per i tempi di boot (idealmente)

Mi accodo ^^

Buongiorno a te 🙂 Inizio sottolineando come la mia era una semplice curiosità piuttosto che una provocazione 😅 Chiaramente quando parli di BSOD relativi ad errori ACPI su Windows intendi l'avvio di Windows stesso da OC, giusto? Inoltre, non sarebbe più "giusto", una volta identificato il valore della variabile _UID, rimuovere da SSDT-PNLF stesso l'algoritmo di identificazione dell'UID per altre generazioni e definire il valore della variabile _UID, come fatto nel caso di SSDT-PNLFCFL?

My bad, ero convinto ci fossero 2 OSI. Comunque come te concordo che sia meglio avviare Windows dal proprio bootloader o quantomeno non da OpenCore. Personalmente non ho Windows, ma ho impostato come bootloader principale systemd-boot con due entry: una per Arch e una che punta ad OpenCore.efi

Mi intrometto nel thread perchè ho ancora qualche dubbio: perchè non mettere un all'inizio dell'SSDT così il codice viene eseguito solo se il sistema operativo, o meglio il kernel, è Darwin? Potrebbero esserci delle complicazioni su motherboard con BIOS legacy/primi UEFI? La vedrei come una soluzione più pulita piuttosto che riempire gli SSDT di n-Darwin...

Salve a tutti, ho acquistato di recente un monitor Acer modello EG240YPbipx (165Hz, 2ms, Freesync Premium, IPS, FHD). L'ho collegato al mio laptop in firma (Dell Inspiron 5370) e funziona anche in modalità clamshell. L'unica piccolezza è che dalle informazioni di sistema il monitor viene rilevato come un monitor 30,5 pollici, quando è un monitor 24 pollici 😅. Premesso che è un'"""issue""" di priorità bassissima, c'è qualcosa che posso fare per far si che le dimensioni effettive del monitor vengano rilevate correttamente? Grazie a tutti e buona giornata

Successfully updated ^^

Prezzo decisamente spropositato per una scheda video con soli 4GB di VRAM. Inoltre quali sono i principali task che fai con il pc? Video editing? Produzione audio?

Può essere che non gli funzioni l'audio dato che AppleALC è in posizione 0 nella lista di kext, e non dopo Lilu? L'ordine di precedenza delle kext (quantomeno le dipendenze) è molto importante

Mmmmmh capito. Giusto per curiosità: che senso ha disabilitare la SIP? Non è più "sicuro" avere la SIP attiva? Sto cercando di immaginare i possibili edge-cases per cui serva la SIP disattiva ma oltre a iniettare delle kext in (S)LE (cosa che può fare tranquillamente OC e schif (ehm) Clover) e effettuare operazioni particolari con gli snapshot di sistema, non mi viene niente. Idee?

Domanda: perchè la SIP è su 0x67? Ricordo male o da Catalina in poi sono cambiati i bitmask della SIP?

Figurati ^^ Uh caspita, ecco perchè ho perso qualche modifica in passato...

Uh, my bad che non l'ho testato. Oggi proverò e ti darò conferma nel caso Update: su Big Sur 11.4 (20F71) la LAN funziona con il solo boot-arg ^^

Salve a tutti, mi scuso in anticipo con lo staff se ho sbagliato sezione e prego gli stessi di modificarla nel caso. Ho deciso di scrivere questa mini guida per fare un po' di chiarezza su come abilitare il NIC I225-V Intel su macOS Catalina e Big Sur. In rete ci sono diversi tentativi di abilitare questa scheda LAN tramite patch via ACPI, kext come FakePCIID et similia, ma nessuno di questi mi ha convinto particolarmente, in particolare la soluzione con FakePCIID. Dunque, come procediamo? Innanzitutto occorre avere un'installazione vanilla (e sottolineo vanilla) di macOS funzionante e un programma in grado di estrarre i PciRoot come gfxutil/IORegistryExplorer/Hackintool/HackCheck. Di seguito la procedura per ricavare il PciRoot tramite i programmi elencati: - gfxutil: da terminale scrivere gfxutil e identificare la periferica LAN (di solito si chiama GLAN o RPxx.SL05) - IORegistryExplorer: è un po' più complicato ricavare il PciRoot path ma identificando la periferica LAN (che avrà un path del tipo PCI0.RPxx@1C,4/SLxx@0) lo si può convertire tramite questa formula: PciRoot(0x0)/Pci(0xAAAAA,0xBBBBB)/Pci(0x0,0x0) - Hackintool: aprire la sezione PCI, cliccare sulla colonna "IOReg IOName" e cercare "ethernet". Identificata la riga, cliccare col tasto destro e infine cliccare su "Copy DevicePath" - Hack Check: aprire la sezione DeviceProperties e identificare la periferica LAN. Una volta fatto ciò, occorrerà apportare le seguenti modifiche al config.plist di OpenCore (sry ma non digerisco Clover): Creare un figlio in config.plist/DeviceProperties/Add contenente il PciRoot path della scheda LAN e una proprietà di tipo DATA chiamata "device-id" e contenente F2150000, come illustrato in figura: n.b. modificare di conseguenza il PciRoot path Inoltre, aggiungere in config.plist/Kernel/Patch la seguente patch: <dict> <key>Arch</key> <string>Arch</string> <key>Base</key> <string>__Z18e1000_set_mac_typeP8e1000_hw</string> <key>Comment</key> <string>i225-V Patch</string> <key>Count</key> <integer>1</integer> <key>Enabled</key> <true/> <key>Find</key> <data>8hUAAA==</data> <key>Identifier</key> <string>com.apple.driver.AppleIntelI210Ethernet</string> <key>Limit</key> <integer>0</integer> <key>Mask</key> <data></data> <key>MaxKernel</key> <string></string> <key>MinKernel</key> <string>20.4</string> <key>Replace</key> <data>8xUAAA==</data> <key>ReplaceMask</key> <data></data> <key>Skip</key> <integer>0</integer> </dict> N.B. questa patch funziona da Catalina fino a Big Sur 11.3 ed è molto importante che il Count sia impostato su 1. N.B. per macOS Big Sur aggiungere ai boot-arg dk.e1000=0. Per comodità allego un file .plist contenente tutte le modifiche da integrare al config.plist di OpenCore Spero sia di vostro gradimento questa mini guida config.zip

Ok ora mi è più chiaro. Che tu sappia questo problema è circoscritto alle sole Z390 Gigabyte o anche Z390 di altri brand (Asus, AsRock, MSI)?

Ehm 😅 perchè dici così? E' da un bel po' che le Z390 sono state documentate (vedi KASRL come ha proposto giustamente @A23SS4NDRO sopra al mio commento). Piuttosto mi verrebbe da dire che il problema sia dovuto ad una possibile (sottolineo possibile) versione datata del bootloader (Clover). Ha due alternative: aggiornare Clover o fare lo switch a OpenCore (consapevole che dovrà documentarsi a dovere prima di dover procedere) 🙂

Premesso che non hai allegato la EFI ne tantomeno un dump del sysreport, a occhio e croce direi "perchè hai aggiunto SSDT-AWAC e SSDT-PMC?".

Ehm non penso che questo boot-arg riesca a fixare l'accelerazione grafica... Mi spiego meglio: questo boot-arg viene usato nel momento in cui dopo un ciclo sleep/wake o un semplice cold-boot lo schermo è nero. Nel suo caso dovrebbe patchare la grafica tramite WhateverGreen ed eventualmente patchare i connettori video

La possibilità di lasciare attivo il VT-d nel BIOS attivo, e DisableIoMapper disattivo?