dreamwhite

Ho un dubbio: cosa succede se usi VirtualSMC + SMCProcessor? Non vorrei che sia un problema di SMCSuperIO che causa problemi

Nonostante la GPU funzioni, direi di aggiungere SSDT-BRG0 appositamente creato per il path della GPU. Ti allego l'ssdt già compilato. SSDT-BRG0.aml.zip Per quanto riguarda l'NVMe noto che manca NVMeFix. Valuta se aggiungerlo o meno (ci sono casi di determinati SSD che possono dare problemi). Per la Thunderbolt 3 non so se ti interessi o meno ma nel caso occorre un SSDT creato ad hoc per quella scheda Per il resto non sembra male la EFI. Giusto qualche piccolo appunto sulla sezione NVRAM visto che noto ForceDisplayRotationInEFI che non ha senso utilizzarlo a meno che tu non voglia ruotare il tuo monitor ahah

Perdonami la domanda stupida. Nel repository GitHub non ho trovato nulla a riguardo. Nello specifico che crash riscontri? P.S. puoi anche rimuovere SSDT-DTGP e rimuovere le relative references negli SSDT. E' un metodo vecchio che è l'equivalente dell'_OSI("Darwin")

Ouch suggerivo a @Lorys89 😅 Ad ogni modo si, provate tutte le altre soluzioni, alla peggio la soluzione "drastica" c'è

Hai provato ad aggiungere il driver .efi nel BIOS tramite UEFITool?

Ciao @Gengik84 volevo chiederti se fosse possibile implementare la lista dei layout id che puoi trovare a questo link: https://github.com/dreamwhite/ChonkyAppleALC-Build Sulla base del vendor name (che puoi tranquillamente ricavare dal vendor-id in hex) puoi reindirizzare gli utenti verso la pagina relativa al loro codec audio

Beta 9 su Dell Inspiron 5370:

Non so se la domanda sia rivolta a me but anyways: 1) avendo MAT Support su 1 e attivando di conseguenza i quirk necessari, non riesco a bootare. Si blocca su EXIT BS START 2) testando le varie regioni da whitelistare, risulta solo l'ultima quella problematica. Posso accontentarmi di questo o mi conviene aggiungere altre regioni?

Più che possibile. Molto spesso diverse voci sono "nascoste" nella GUI del BIOS e l'unica opzione per modificarle è tramite ru.efi o modGRUBShell.efi

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...