dreamwhite

On 9/12/2022 at 3:12 PM, TonyB said:

Ho seguito la tua guida con l'intenzione di abilitare il menù avanzato del mio notebook Clevo e sono giuscito ad abilitare senza problemi CFG Lock. Una volta entrato però nel bios il menù è sempre lo stesso, è possibile che CFG Lock non centri nulla col menù avanzato e inceve devo modificare un altro parametro?

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.

On 9/6/2021 at 3:35 PM, Giaccaz said:

Non fai altro che inizializzare  la pendrive in  Mac os esteso ( journaled) , dopodiche monti la partizione efi della pendrive e copi la tua cartella con opencore.

Ovviamente il tutto sotto osx

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

2 hours ago, schwarzkopf said:

ciao bouna sera volev ciedere se che qual cuno che mi po madare un efi cosi parte di novo mac os solo non che la faccio grazie per aiutu.

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 😄

19 minutes ago, Gengik84 said:

Si ma all'atto pratico non cambierebbe nulla

in condizionale fatto a modo funziona benissimo, usati oltretutto dagli OEM in gran numero.

Condizionali che ci sono su molti linguaggi di programmazione

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