Leaderboard

Patch rework in process. Currently hardcoding some values. Awaiting a possible integration into OpenCore to inject values into the kernel to future proof the patch that breaks most often. Stay tuned.

In questo thread cercheremo di dare una indicazione ottenuta insieme a diversi utenti sulle patches del kernel che gli utenti di CPU AMD possono usare in sicurezza per far partire i propri PC con il sistema operativo Apple. Analizzeremo le patches fornite da AMD - OSX Github, non andremo piu' a ritroso perche la situazione precedente non mi e' chiara abbastanza per parlarne in modo piu' preciso e corretto, magari se qualcuno di voi vuole aggiungere una "memoria storica" sull'argomento e' il benvenuto! Partiremo quindi dalle patches scaricabili da questo link: https://github.com/AMD-OSX/AMD_Vanilla scaricate il giorno 6-07-2021, lo specifico per evitare eventuali cambiamenti effettuati sulle stesse patches e non creare quindi confusione. Per comodità vengono allegate al thread. Le allego in quanto alcune volte vengono cambiate sia come find / replace e come denominazione nel commento ufficiale, a volte senza un apparente motivo. Quindi, la nostra base di patches sarà quella ufficiale. Si partirà da 46 patches funzionanti da High Sierra per arrivare fino alla beta 1 di Monterey (Ovviamente passando per Mojave ,Catalina BigSur). Per iniziare ci siamo concentrati sugli ultimi sistemi come BigSur e Monterey beta 1 ma, personalmente , ho iniziato la scrematura delle patches da HighSierra per poi affinarle in Big Sur, arrivando ad un numero totale di 14 patches per il Kernel ed una per i kext, diventate poi 13 (grazie a @carlo_67 leaf tolta) per poi arrivare al numero definitivo di 11 patches (grazie a @iGPU) . Queste undici patches consentono un utilizzo completo di Big Sur senza alcun tipo di problema evidente. Specifico e rendo piu' evidente questo concetto, non essendo trasparente e spiegato in dettaglio il significato di molte patches, potrebbe, in un caso ipotetico remoto, che una patch eliminata magari serva, ad esempio, con una particolare funzione di OSX o una combinazione speciale di operazioni effettuate e programmi utilizzati Nello spoiler metteremo tutti i nomi delle patches ufficialmente utilizzati e dichiarati nel patches plist di AMD-OSX GitHub , per chi non lo sapesse, le voci base e commenti nel plist sono il punto dove in XNU vengono cercate e poi sostituite alcune parti del kernel attraverso la tecnica del find/replace (e soprattutto una competenza specifica sull'argomento). Per decompilare il kernel questo e' il comando: otool -tV /Users/fabio/Desktop/kernel_12 > ~//kernel.txt Non e' un argomento trattato in questo thread la spiegazione di come trovare le locazioni delle patches, ma il commento ed il kernel decompilato sono un buon indizio e inizio. AMD OSX Patches ufficiali al 06-07-2021 (valide per tutti gli OSX fino a Monterey beta 1 e per le CPU definite con 17H-19H) Ora prenderemo le stesse patches postate nello spoiler qui sopra e selezioneremo solo le utili per far partire qualsiasi versione di Big Sur, aiutandoci con la dicitura presente nei commenti delle stesse patches. AMD OSX Patches ufficiali al 06-07-2021 (valide solo per Big Sur e per le CPU definite con 17H-19H) Arriviamo ad un totale di 25 patches che inserite nella apposita sezione del config.plist faranno partire tutte le versioni di Big Sur dalla 11.0 alla 11.5 beta 4 presente oggi Ora, e' ben chiaro che fino a qui non e' che ci sia stato tutto questo gran lavoro, pero' diciamo che per un utente che utilizzasse solo BigSur sarebbe una buona ripulitura del proprio config.plist Come nota a margine ricordo che gli utenti TRX40 non necessitano delle patches 44/45 (fix PAT) anche grazie alle prove effettuate dall'utente @Pavomesi fa. Ora la parte interessante per il momento confermata da tutti gli utenti TRX40 tranne alcuni che necessitano dell CPU Topology patch, ma potrebbe anche essere non piu' necessaria utilizzando una combinazione di quirks, chiedo ad @Arrakis e @Ploddlesdi intervenire al riguardo anche sull'argomento della necessità di utilizzare o meno il quirk DummyPowermanagement. Su piastre madri MSI non serve, su gigabyte e su piattaforma x570 sembrerebbe di si. Nello spoiler seguente le patches che fino a pochi giorni fa erano utili a me e a molti utenti anche X570 per lavorare con OSX Big Sur: AMD OSX Patches ufficiali - prima riduzione (valide solo per Big Sur e per le CPU definite con 17H-19H): Quirks: Quindi una bella sforbiciata di patches necessarie! Siamo passati da 25 patches a 15! Con una prova effettuata da @carlo_67 si e' potuto ulteriormente affinare questa lista togliendo la patch: algrey - _cpuid_set_generic_info - Disable check to allow leaf7 - 10.13/10.14/10.15/11.0/12.0 per cosi' arrivare a 14 patches per il kernel e per il boot di BigSur AMD OSX Patches ufficiali - seconda riduzione (valide solo per Big Sur e per le CPU definite con 17H-19H) Quirks: Ora, ricordo che il set ridotto di patches e' stato piu' volte descritto e discusso anche con utenti con motherboard Gigabyte come ad esempio @Arrakiscon il quale si capi' all'epoca che c'era la necessità di mantenere nella lista la patch: XLNC - Disable _x86_validate_topology - 10.13/10.14/10.15/11.0/12.0 ora XLNC ma all'epoca credo fosse denominata Algrey. il link di seguito: Il set di patches veniva costantemente pubblicato, e lo e' tuttora , nella mia EFi nel thread principale dedicato alla piattaforma TRX40: Detto questo grazie al lavoro di @iGPUè stato possibile rimuovere due ulteriori patches: 37 algrey - Remove Penryn check to execute default case - 10.13/10.15/11.0/12.0 38 algrey - Get DID and VID from MSR - 10.13/10.14/10.15/11.0/12.0 Cosi da 25 patches siamo passati alle 12 mostrate nello spoiler sottostante: AMD OSX Patches ufficiali terza riduzione (valide solo per Big Sur e per le CPU definite con 17H-19H) Quirks: Niente male no? Pubblicheremo a breve i quirks necessari per avere le condizioni necessarie e (forse) sufficenti per tutti per utilizzare le riduzioni proposte in questo articolo Ovviamente si ringraziano tutti i curatori del Github ufficiale AMD-OSX e ancora in modo piu' ovvio apprezzeremo il loro intervento per chiarire la necessità delle patches ulteriori consigliate ufficialmente AMD_Vanilla-opencore.zip

I have WiFi/BT AIC working, including Airdrop (as I described here) in Monterey ß1. See the Kernel/Add section in the EFI I uploaded for what needs to be on/off and for which macOS. If you are using an AIC for BT, you must inactivate the internal AX200 or you will have a conflict (I've commented on this several times in the past few posts; follow the links). However, if you're using the internal AX200, a different scheme is needed and Airdrop is not presently supported.

I've downloaded and can boot without problem into Big Sur. I did change MmioWhitelist and PlatformInfo/Generic for my mobo. All other settings are the same. I later added SmallTree to get my I211 port active. Only problem is that AMD-SMC kext won't work, so I cannot yet monitor temps. Kext is loading as shown when running "Kextstat | grep -v com.apple" in Terminal. I'll work on shortly. I copied AMDRyzenCPUPowerManagement.kext from one of my backups into the kext folder, over-writing the one in your folder and now it works. Strange. *** BTW, I'm also using HackCheck. It's really nice software. Hats off to gengik84! *** Another finding is that I have no Airdrop with your EFI (no complaints, just describing for others ); this is because there are no Broadcom kexts nor DevProp injections which help on my setup. Also, there is no SSDT to remove XHC/HS05 USB power from the Internal AX200 which then leads to interference with the Broadcom AIC. Once I rebooted with a custom SSDT (7-SSDT-TRX40-USB-Rename-NoIntelBT.aml), provided in the previously posted EFI, Airdrop is working. This can be verified by using HackCheck: on the USB tab, you can see how there is no HS05 (part of the renamed, thru the SSDT, XHC device) because it was simply not declared in the SSDT. Easy. In the same EFI posted above, there is also an alternative SSDT (8-SSDT-TRX40-USB-Rename-WithIntelBT) that does declare HS05 for those wanting to use the internal AX200. (Note that your mobo might require that the USB devices be changed a bit; if an IORE is posted, I can help adjust for you.) Temporary attachment EFI v070 for testing by fabiosun (of no interest to anyone else).

Release v0.7.1 Added SyncTableIds quirk to sync modified table OEM identifiers Added CPU Info (MSRs) dumping to SysReport Updated builtin firmware versions for SMBIOS and the rest Fixed PowerTimeoutKernelPanic on macOS 12 Fixed transparency click detection on OpenCanopy boot entries Added PCI device info dumping to SysReport Fixed SetApfsTrimTimeout on macOS 12 Documented requirement for SetDefault.icns width to match Selector.icns width Added explicit warn and safe fallback to builtin picker on failure to match the above Added VSCode source level IDE debug config example to debug docs Added other minor debug docs updates Fixed incorrect timeout of built-in picker on IA32 Added support for custom kernels on ESP partition Fixed DEBUG ASSERT on pressing change entry keys with single boot entry in OpenCanopy Added recommended Apple12 and Windows11 flavours Added TpmInfo tool to DEBUG TPM status Fixed incorrect OpenCanopy initial display when default entry beyond right of screen Fixed ProvideCurrentCpuInfo MSR patch on macOS 12

Yes it is that kext but in different case is not stable for us

Questi sono i miei quirks

@Ploddles check here to find right combinations (patches and overall quirks) (only in Italian Language for now)

I have updated to OC 0.7.1 and added new patches for Monterey. I seem to need a few more patches than the rest of you to be able to install and boot Monterey, but I still need to try a few more combinations of the patches to minimise the extra ones I am using. I will post my EFI once I have narrowed it down a bit. Nice to see that the Threadripper Processor is still being automatically identified in System Info, but Bluetooth isn't working as yet.

11.4 release Clover 5138

@Shaneeethank for this news 😉 if you can, take a look here (for now only google translation here): Maybe it is possible to speed up the process of searching for new patches as it is possible to use much less of them What do you think about it?

@Gengik84 alla fine ordinata questa mobo: Scheda Madre CPU resta uguale penso che non cambi molto dalla prima scheda madre se non il formato Saluti Perdu

nel tuo caso mettere quel path in DeviceProperties è errato e ovviamente sei costretto a usare alcid=x, altrimenti l'audio non ti funziona Quel path riguarda vecchi hardware precedenti a skylake successivamente quello corretto è PciRoot(0x0)/Pci(0x1F,0x3) Alla fine possiamo lasciare qui, a parte il discorso audio parli comunque di tools di verifica del config di opencore

quel problema con Monterey non ha nulla a che vedere con questo quello che va bene su BigSur è da mantenere, non farei modifiche azzardate per un beta sistema che stai usando. Questo è sempre bene ricordarlo. Comunque in caso continua sul tuo topic perchè qui saremo poi OT.

quello che uno riesce a fare e che funziona aggiungere la voce nei boot-arg è la cosa più facile e che chiunque dovrebbe riuscire fare usare deviceproperties richiede uno sforzo maggiore per chiudere, IMHO però o usi un metodo o usi l'altro, insieme non ha molta logica ti avvisa appunto delle voci che non ci sono nel sample, ma riguardo deviceproperties che uno aggiunge, si può ignorare; puoi anche settare OCConfigCompare per fare in modo non rilevi tali voci in deviceproperties

In PciRoot(0x0)/Pci(0x1f,0x3) se aggiungi la voce layout-id e la valorizzi con il numero che ti serve puoi anche scegliere il setup come alcid

Ma non credo che sia strettamente necessario metterlo, a meno che tu non voglia usare un dato canale per altri motivi, di solito quello che viene assegnato di default va quasi sempre bene. Beh una voce mancante o in più in valore assoluto è un errore in effetti, questo non pregiudica l'avvio della macchina ma qualcosa che non va bene c'è.. poi definirlo errore o mancanza è relativo 🙂

Ciao se hai aggiornato i kext non ti serve -lilubetaall in boot-args come anche keepsyms=1 utile per generare debug in caso di di kernel panic 🙂