dreamwhite

Avrei una domanda: in base a quale criterio andrebbero escluse le regioni con più pages? Sul mio laptop è bastato "skippare" solo l'ultima regione (0xFF000000)

Mi son dimenticato di aggiornarvi sullo stato di AirportItlwm. Ho automatizzato la compilazione di quest'ultimo tramite GitHub Actions. Al momento ho testato solo con la v2.2.0-alpha e funziona correttamente

Salve a tutti, per evitare strani equivoci o altro ho deciso di mia spontanea volontà di scrivere una piccola guida che potrebbe tornare utile a coloro che si vogliono cimentare nell'"impresa" di installare macOS con OpenCore sul proprio hardware. Come ben sapete, ogni PC è a se stante, e ha chiaramente componentistiche diverse da quelle di un vero Mac, in particolar modo per quanto riguarda la scheda madre. Per iniziare, dopo aver configurato il BIOS appositamente (vedi questo link), è indispensabile avere un dump delle tabelle ACPI nonchè una lista di informazioni che potrebbero tornarci utili in fase di creazione della EFI Più nello specifico: - stato del CFG Lock, nel caso di schede madri Intel - MAT Support - lista dei dispositivi PCI connessi Per fare ciò, vi sono due strade: - scaricare l'ultima stable release di OpenCorePkg DEBUG, creare una EFI vuota (senza ACPI, Kext, Patch, lasciando attivi solo i driver OpenRuntime.efi e AudioDxe.efi) e abilitare la voce Misc/Debug/SysReport - utilizzare una EFI pre-built che ho creato, scaricabile al link https://github.com/utopia-team/opencore-debug/releases/latest Ci tengo a precisare che quest'ultima è stata creata solo con lo scopo di "velocizzare" questa fase di "info gathering". Liberi di usare l'alternativa che più preferite Una volta creata/scaricata la EFI che verrà usata per il SysReport, basterà solamente avviare la EFI sul PC di destinazione e, appena raggiunto il picker menu di OpenCore, spegnere il PC. Sul dispositivo di boot utilizzato (e.g. pendrive USB) verranno creati: - un file di log in formato .txt - una cartella "SysReport" contenente al suo interno ACPI, Audio, CPU, PCI e SMBIOS. Rispettivamente: - il file di log in formato .txt contiene informazioni relative allo stato del CFG Lock e il MAT Support e tant'altro - ACPI contiene il dump delle tabelle ACPI relative alla scheda madre; sono indispensabili per creare gli SSDT ad-hoc per la propria scheda madre (abbasso i prebuilt di Dortania 😂) - Audio contiene il dump di tutti i codec audio rilevati (onboard, HDMI ecc) - CPU contiene un file formato .txt con le informazioni relative alla CPU; personalmente non l'ho utilizzato più di tanto ma potrebbe essere utile dargli una lettura - PCI contiene un file formato .txt con la lista di tutti i dispositivi PCI connessi; personalmente, stufo di dover fare copia e incolla dei vendor-id e device-id ho "scritto" (metto fra virgolette giusto perchè non ci vuole chissà quale laurea per farlo) un parser: https://github.com/utopia-team/PCILookup - SMBIOS contiene dei file in formato .bin che possono essere utili per scoprire il modello della scheda madre, versione del BIOS e tante altre info. Sulla base di questi file, potete tranquillamente creare una EFI da zero seguendo le guide che il forum approva Stay tuned ✌️

Dopo svariate prove sono riuscito ad automatizzare la compilazione delle kext slimmed nonchè della generazione delle docs utilizzando GitHub Actions. Quando verrà rilasciata una nuova versione di AppleALC mi basterà creare una release e il progetto in automatico verrà compilato e caricato nella sezione Release

Ho aggiornato giusto ieri sera il repository con le kext specifiche per ogni codec, nonchè la lista in formato MD

(emoji del bambino felice) Commit utilizzati: - OpenCorePkg: https://github.com/acidanthera/OpenCorePkg/commit/7dfca8eacdf9350957ae5cbd424165bb5f6bae68 - Lilu: https://github.com/acidanthera/Lilu/commit/9008be3761602282a542a32b68716b2b86bdb1a1 N.B. Hanno pushato un altro commit su OpenCorePkg: https://github.com/acidanthera/OpenCorePkg/runs/7231244601 "andate in pace" 😝

Nuovo commit su acidanthera/Lilu: https://github.com/acidanthera/Lilu/runs/7230956896

Penso sia inutile continuare a discuterne... Lilu 1.6.1 va in KP. Allego foto: Finchè non risolvono con Lilu - che è la base di pressochè qualsiasi kernel extension che usiamo - non possiamo fare nulla...😅

Se usi un SMBIOS di un iMac con una GPU integrata ed esporti in H.264 o HEVC utilizzerai solo ed esclusivamente la iGPU. Viceversa, se usi un SMBIOS di un iMac con processore sprovvisto di iGPU, aka iMacPro1,1 o MacPro, utilizzerai solo la dGPU.

A dire il vero non c'è neanche bisogno di fare tutto questo sforzo. Basta dare uno sguardo alle specifiche UEFI per capire come avviare un qualsiasi binario .efi da una chiavetta USB: 1. formattare la chiavetta USB in formato MS-DOS FAT (aka FAT32) con tabella di partizionamento GPT 2. posizionare la EFI sulla partizione visibile della USB rispettando il seguente tree: 3. Dal boot-menu del PC in cui si intende avviare la USB, selezionare la "Partition 2" relativa alla chiavetta USB (e.g. "UEFI: Sandisk Partition 2") Side note: la famosa partizione EFI non è altro che una partizione formattata in FAT32 con i flag boot e esp attivi , che fanno si che questa non venga automaticamente montata come una normale partizione :)

Buongiorno, la tua é una domanda del tutto intelligente a cui ho trovato, nel corso degli anni, una risposta suddivisa per sistema operativo: - Windows => cloni la partizione NTFS e da Gestione dischi estendi il tutto - Linux => idem come Windows oppure, se sei su btrfs crei uno snapshot read-only e lo copi fisicamente sul disco di destinazione e lo ripristini - Mac => Backup di Time Machine e via

Eccomi 😄 OpenCore 0.7.2

Può essere dovuto ad una errata configurazione della EFI? 😅 Ho avuto problemi del genere con il CFG Lock e il DVMT non configurato correttamente...

Figata 😄 Avrei una sola curiosità: per quale motivo MCHC-SBUS contiene un device come questo dello screenshot? Non sarebbe più "corretto" usare il sample di acidanthera? Che differenze ci sono rispetto alla vostra versione? Grazie 😄

Dopo ore spese su questa build, config esasperati et similia, siamo riusciti a risolvere con una clean install di macOS. Non ho idea del perchè l'installazione precedente (sempre effettuata tramite installazione vanilla) abbia dato questi problemi. Forse passando da macOS Catalina a Big Sur qualcosa è andato storto? 😅

Update Abbiamo provato altri headless AAPL,ig-platform-id senza alcun esito: 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 ID: 9BC50003, 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 ID: 9BC40003, 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 Abbiamo provato anche a spoofare invano il device-id della iGPU (9BC8 - Comet Lake) in 3E9B (Coffee Lake). Domani proveremo a reinstallare macOS e vedremo se i problemi persistono o meno...

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?