Leaderboard

FYI As of yesterday, OpenCore has with latest commits made some notable structural changes to the config file. So unless one studies it carefully there'll be errors in the config file if one simply adds in the latest commit without adjusting the config.plist file. These changes are primarily architectural indicating strings ("Arch") being stored in the Kext section in many locations as well as adding a "Scheme" to the Kext section. #33 below is a Kext patch entry. Each Add, Block and Patch entry within the Kext section now has an "Arch" element. The choices for this string are Any, i386, x86_64. I can imagine an Apple kernel architecture being an option in the future, which is why I'm setting them all to "Any" (the only other choice for our machines would be "x86_64"). I adjusted the config file, tested last night and it's working. However, the changes presently offer nothing for the TRX40, so no need to update any EFIs.

fabiosun, Are you enabling "Above 4G decoding"? While researching TB issues, I came across a recommendation for a user of NVIDA card to enable it, esp with the TB card in place to avoid KP. If you do keep it enabled, the SSDT-TB will possibly need adjustment as it could shift the device location. Let me know.

Dont worry @iGPU its not your problem or fault with my corruption - its part of life experimenting :-) . Each board is different. Your work is excellent and some terrific findings. Many thanks for doing what you do.

OK Im back up after a re-clone of my Proxmox M2 nvme MacOS Catalinaa drive to the corrupted EFI/OS SSD 2tb drive. We begin again... Ive been using most of Fabiosun's EFI suggestions and his config recommendations, but note Im still using MacPro 7,1 like my Proxmox boot. I didnt want to use Mac1,1. All is good and GfX in Davinci, Final Cut, Logic is up to speed of Proxmox. NO real difference. However, the firewire Fireface card is rock solid now it seems. All good. RESTART cause s a quick KP Restart and wont boot back in. Shutdown gives me a Restart which will boot back in but doesnt click shutdown. So now need to enter MMIO to see if I can get Shutdown working. So now I'm using BIOS 'Above 4G' as with it off using Macpro7,1 it wouldn't boot hanging on PCI begin. (I guess I could've usde the nscpi=0x2000 thing but didnt bother). Remember, Im using a config based on my Proxmox settings and adding in/editing in any useful stuff from @fabiosun plist. Just wanna thank @fabiosun for his tireless support. What a guy! Now here's the interesting news. A comparison of MMIO with Above 4G selected: (Above 4G Left, Above 4G Disabled on Right). I've attached my config (fill in your serials/UUIDs) for Asrock Creator users. Ensure Above 4G is on and this is PRE MMIO configurations. Later if Im successful in getting the MMIO stuff working Ill post the final config. Download: Asrock TRX40 Creator Macpro7,1_config.plist.zip EFI: Kexts & Stufff I used * remove any EFI (like I did above_) you are not using - only use what is declared in config... I have to tidy mine up! My setup utilises two Radeon VII cards - so check your graphics as it will be different to mine. Especially Whatevergreen.

Dato che nella cartella EFI/CLOVER/ACPI/patched puoi mettere solo un DSDT.aml, deduco che hai usato solo quello con la modifica _Q11 e_Q12. Se il DSDT di Gengik contiene altri patch necessari, puoi aggiungere anche quelli di _Q11 e _Q12 e usarlo, come preferisci. Ma puoi usarne solo uno, ovviamente. Verifica che sia settato anche AutoMerge nella sezione ACPI/DSDT di clover configurator o solito PList se non usi il configuratore Si, il patch è corretto Deve funzionare, sono abbastanza certo che _Q11 e _Q12 siano i metodi chiamati quando premi i tasti Fn+F8 o F9. Diversamente si dovrà installare il kext ACPIDebug e verificare quali siano le query inviate dall'hardware quando premi i tasti. Se vuoi, allega la EFI, IOReg e il bootlog che verifico.

Si. Ma potrebbe non essere necessario @iCanaro dai, dai sistemiamolo... ci metti poco. Devi patchare le due query dell'ACPI: ho dato un'occhiata al DSDT contenuto in origin.zip che hai postato, ho ragione di credere che le due query della luminosità siano proprio la _Q11 e la _Q12. Cerca nel DSDT i due metodi delle due query e sostituiscili con questi: Method (_Q11, 0, NotSerialized) // _Qxx: EC Query { Notify (PS2K, 0x0405) } Method (_Q12, 0, NotSerialized) // _Qxx: EC Query { Notify (PS2K, 0x0406) } Aggiungendo il DSDT patchato alla cartella ACPI/patched della EFI di clover dovrebbe funzionare il controllo luminosità da tastiera Fn+F8 e Fn+F9. S vuoi usare OC, il patch è leggermente diverso: Method (_Q11, 0, NotSerialized) // _Qxx: EC Query { If (_OSI ("Darwin")) { Notify (PS2K, 0x0405) } Else { XQ11() } Return (Zero) } Method (_Q12, 0, NotSerialized) // _Qxx: EC Query { If (_OSI ("Darwin")) { Notify (PS2K, 0x0406) } Else { XQ12() } Return (Zero) } ma in questo secondo caso dovrai anche aggiungere due rename nella sezione ACPI->Patch come da immagine: o l'equivalente tramite PList se non usi il configuratore.

https://github.com/corpnewt/OCConfigCompare to compare config.plist in an easy and super fast way

PREVENT SEALING DURING BIG SUR INSTALLATION This is part 2 of the 'subsequent' post on preventing a Big Sur drive being 'sealed'. Presently, this step can only be done during Big Sur installation. Up until BS ß4, there was a technique for avoiding the sealing step that involved stopping the installation of Big Sur during the 3rd re-start (literally pressing the power button and shutting off the computer). However, with BS ß5, this technique reportedly does not work (I did not try it to verify). Instead, it is recommended (again by fusion71au on the InsanelyMac forum here) to use the app Hax2 (attached below), which was derived from ASentientBot's post on MacRumors. This app, along with it's associated files are to be placed on the root section of your macOS drive (ex: MacHD/User/myName/Hax2/) used to run the installation. While it reportedly can use an installer placed on a mounted USB thumb drive, I could only get Hax2 to work by placing the BS ß Installer in the applications folder where it normally is located. Prior to using, as mentioned in part 1 of this 'subsequent' post (here), you need to have the following in the OC boot arg section: -no_compat_check and amfi_get_out_of_my_way=1 as well as 77080000 for car-active-config. I also when into Recovery on the drive containing the Hax2 and ran csrutil disable and csrutil authenticated-root disable and then rebooted into the drive containing Hax2. At this point, the drive destined for the Big Sur installation should be erased using Disk Utility. Next, run Hax2 (you'll need to give permission by <Control> clicking on Hax2 and selecting Open. Hax2 will do some processing and then open the BS Installer. However, if you have not properly used the boot arguments noted above, Hax2 will give you an error window as shown in Spoiler below; select Stop, fix the boot issue in your EFI, re-boot the computer and try again. Once Hax2 is running without an error window, and after the Big Sur Installation window has opened, do not yet run the Installer. Instead, look at the Installer icon in the menu bar and make certain that it's the ß5 and not some other BS Installer you may have inadvertently left on another drive by opening it in the Finder (Spoiler below): If it's the correction version, run the Installer and select the proper destination drive. I re-ran all of this tonight and repeated the installation: At each re-boot do make certain that the booting EFI contains those same boot arguments noted above ( -no_compat_check and amfi_get_out_of_my_way=1 ) After the Installation is complete and you've finally logged into Big Sur, re-start the computer and log into the Big Sur Recovery 11.0. At this point, you'll want to run the first part of this post to remove the Snapshot partition (see a synopsis in the Spoiler below). Once the Snapshot partition was removed, re-boot back onto the desktop. When you're back on the Big Sur desktop, you can now run in Terminal: sudo mount -uw / and then diskutil info / (mentioned in the first post) and you'll see the following, showing that the Big Sur installation is not sealed: The main advantage of removing the seal is that the Big Sur drive will now be visible when the computer is booted into an older macOS. The image below was booted into Catalina and shows one Catalina drive and two Big Sur drives. One Big Sur drive has had the seal removed and is visible as "MacHD". The other Big Sur drive is only visible as "Update" since this drive is still sealed. Hax2.zip

They were the included SSDTs from the original PVE-OC iso, and I haven't removed it (probably should). ALS is for Ambient Light Sensors (not needed). I think the main one should be SSDT-EC. This is what's showing up for me. I have not modified it unlike for Bare Metal.

https://dortania.github.io/OpenCore-Post-Install/#how-to-follow-this-guide

From my readings, I wouldn't be surprised if MmioWhitelist needs adjustments if one changes BIOS versions, changes BIOS settings, or changes AICs. If true, more reasons why none of us can share MMioWhitelist data unless everything is exactly the same. I don't know about getting Shutdown on Catalina. I only had it happen sporadically, while Shutdown on Big Sur is very consistent, but rather drawn out. I don't understand the fascination with MacPro7,1. The hardware similarities are greater between the iMacPro1,1 and our builds; there are less memory and PCI issues without resorting to kext kludges. (I found on the X570 builds more instability issues which users only resolved once they returned to using the iMacPro1,1 SMBIOS.) Testing on TRX40 with CPU and GPU speeds showed no difference. , But to each their own.

Thank you for your offer but now I have lost again my GPU acceleration..Nvidia is very hard to configure in bare metal Nvram/sip is a big problem to understand some problem I have I have resetted my nvram via opencore boot menu option..and now some Nvidia kexts loaded again ..and Nvidia web driver is checked I hope to fix it..but I can't find a clear way to reproduce a working situation