iGPU

First, I just re-tested the EFI I uploaded, leaving it exactly the same with no entry for MmioWhitelist, and it booted into Catalina without any problem. Second, in your first post here, you mentioned things were working well with the EFI. What exactly did you change from that point where it was working, to the point when it did not? (No matter what, not booting doesn't mean the drive's contents are affected.) And what you've shown does not indicate a problem with BIOS. Where it stops suggests some change in settings, particularly with one of the Quirk settings. Did you change any of those or anything else? To try and get you "re-set", I included 2 extra config.plist files in the EFI folder as an internal backup. First re-name your current config.plist file to save your MmioWhitelist work. This way you can access that list later. Then, duplicate the extra named "config-basic-genPI.plist", then rename this duplicate "config.plist". This new config file should boot as it re-sets things to what I originally uploaded. As for the MmioWhitelist, since few of us have the exactly the same mobo with the same components, no one can work up an MmioWhitelist for anyone else. Each person has to do it on their own, but only if you want native NVRAM. If you don't want to go the MmioWhitelist route, leave the MmioWhitelist array empty and setup an NVRAM plist by reading the OC Docs. Assuming you ran the MmioWhitelist test correctly, and you wish to try it once more, I would suggest that you set all entries in the list you displayed to 'Yes', except set 15, 16 and 17, setting those to 'No'. ***** And here I would remind anyone else that one always should have an alternative method of booting into a drive (even running a VM). With bare metal, at the very least, you want to have a USB thumb drive with a known, good EFI for access to your drives. Personally, I have 2 NVMe drives (1 Catalina, 1 BS), 1 SATA with Catalina and an external USB with BS. Each can have a unique EFI, but one has an older, working EFI so that there is always bootable access. The known, working EFI is how I tested the MmWhitelist. When a boot failed, I simply forced a shutdown and re-booted using the alternative EFI. Furthermore, the external drive can be connected to my laptop to work on a problematic EFI separate from the Hackintosh.

REMOVING THE SNAPSHOT PARTITION FROM BIG SUR Now, the 'subsequent' post on removing Snapshots... what I'm about to post is based on the posts of fusion71au on the InsanelyMac forum here. I've adapted it for the limitations I've found in how Recovery behaves on the TRX40 builds, especially with regards to Big Sur. There are 2 parts to this section, and so I'll divide into 2 posts. This post will deal with removing Snapshots, the other how to try to prevent a sealed Big Sur install. The 2nd part is here. The key to getting this to work is disabling both csrutil and csrutil authenticated-root as discussed in my EFI post. In fusion71au's post, he recommends disabling these in Recovery. I could not get csrutil to persist being disabled after one re-boot (csrutil authenticated-root remained disabled after re-boot). Accordingly, I turned to using 77080000 for csr-active-config to keep these two disabled after disabling them in Big Sur Recovery (listed as 11.0). These same OC NVRAM settings are used for both booting into Big Sur as well as Recovery. (The boot arguments -no_compat_check and amfi_get_out_of_my_way=1 will be important for the 2nd part dealing with sealing.) To clarify, keep using 77080000 throughout and attempt to disable both csrutil and csrutil authenticated-root in Recovery, and then return to Recovery 11.0. Once you've then re-booted back into Recovery 11.0, there are several steps required to remove the Snapshot partition(s). In order, type the following into Terminal. Note that when in Recovery, you are automatically the Administrator, so adding "sudo" is not needed for Recovery-based terminal commands. 1. Run: diskutil list which will show sometime like the following. What you're after is the main Big Sur disk "BigSur" (not "BigSur - Data") and the <disk identifier> which here is "disk3s5". The Snapshot partition, here shown as "disk3s5s1", may or may not be visible at this stage. 2. Next, open a 2nd window in Terminal (so you can easily refer to the listing made in step 1) and type: diskutil mountDisk <disk identifier> (such as diskutil mountDisk disk3s5) You should get a response: "Volume(s) mounted successfully". 3. Then type: mount -uw /Volumes/BigSur (<--- using your disk name without a trailing "/" symbol) You'll get no response unless there's an error. 4. Now type: /System/Library/Filesystems/apfs.fs/Contents/Resources/apfs_systemsnapshot -v /Volumes/BigSur -r "" (<--- again, use your disk name; the final characters are 2 double-quote marks) You'll get a response such as "Attempting tagging of snapshot on volume: /Volumes/BigSur 5. Next, type: diskutil apfs listSnapshots /Volume/BigSur You'll get a response shown below; what we're interested in is the <uuid of snapshot> highlighted in the red box: 6. Then type: diskutil apfs deleteSnapshot disk3s5 -uuid 3F27525D-9224-4FBA-9411-EF20292CB299 (repeat this for each snapshot seen on that disk; remember that you can copy and paste inside terminal, making it easy to enter the uuid) 7. Optionally, verify that you've removed all of the Snapshots from your Big Sur disk by typing: diskutil apfs listSnapshots /Volume/BigSur You should get a response "No Snapshots for disk" if all were deleted; otherwise, you'll see something like the image in step 5 again. 8. Once you've deleted all of the partitions, re-boot into Big Sur desktop and run the following in Terminal (now you need to use "sudo"): a. sudo mount -uw / (this should return no errors) b. diskutil info / (this should return something like "disk3s5" and not return a Snapshot partition like "disk3s5s1") At this point you can change files and folders for which you've previously had no access. For example, I copied a file from the desktop that contained the description for the AMD processor used in the window "About Mac" from a file that I'd altered from a similar folder in Catalina, using the command: sudo cp /Users/<username>/Desktop/AppleSystemInfo.strings /System/Library/PrivateFrameworks/AppleSystemInfo.framework/Versions/A/Resources/en.lproj/AppleSystemInfo.strings Normally, you'd have no access to this folder as it is read-only. However, since we removed the Snapshot and gained access to read-write, I could make this change to the "About Mac" window as shown below. (And while this isn't profound, it does show you how you can get access to files and folders that are otherwise off-limits in Big Sur.)

I'm not sure what you mean. The EFI allows Shutdown (Restart was always working). Are you in Catalina or Big Sur?

I've noticed that I sometimes must do a "Reset NVRAM" when changing from Big Sur to Mojave. (I've not yet had to re-flash BIOS on this MSI mobo.) Yous SSDT looks okay. Did you use the minimal SSDTs from above EFI; it should have injected to SBRG and MCHC. The SSDT-NVRAM might not work until you get MmioWhitelist working. Is there an issue I'm missing?

BIG SUR INSTALLATION EFI I'm posting here an EFI that not only boots the TRX40 bare metal into Catalina or Big Sur, but also allows a Big Sur Install from either a USB Installer, or, having the installer app within the Applications folder. I tested both methods of Big Sur install with destination drives that are internal and external USB. [ Debug Version added at bottom ] There are a few important details that I'll point out below. In a subsequent post, I'll show how removing Snapshots can allow proper read/write of the disk (and this may allow you fabiosun to get your kexts loaded, but I cannot check, so I don't know for certain). That post was divided into 2 parts here and here. Besides booting Catalina and Big Sur, this EFI also seems to have a consistent, properly functioning Shutdown in Big Sur (but not so regularly in Catalina). Shutdown also works from Big Sur Recovery. However, while Shutdown works from the Apple menu, it does not seem to work when using the log-in screen Shutdown button, but gives the usual panic re-boot. I would recommend not changing anything in this EFI (except perhaps for very select items like Ethernet discussed towards the bottom). This EFI uses OC v061 commit from 25 Aug. This commit allow proper booting of Big Sur Recovery without resorting to ScanPolicy 0 or the need to Enable/Yes JumpstartHotPlug (ScanPolicy discussed more below). There are no re-name SSDTs nor any fancy stuff: this is basic, functional EFI. First off, there are 3 config.plist files as shown below. The active one is simply a duplicate of config-basic-genPI-BSinstall.plist as a backup. The other config file, config-basic-genPI, is the same but without boot args (-v, -no_compat_check, and amfi_get_out_of_my_way=1), Those boot arguments will be discussed in the subsequent post, but they're really only useful during a Big Sur install and are otherwise not necessary. Notice that the Slide boot argument is removed. It seems not necessary and avoids conflict with other mobo builds. Config files: Boot Arguments: The other thing to point out is the csr-active-config value of 77080000. This value was gleaned from user "fusion71au" on the InsanelyMac forum and disables both csrutil and csrutil authenticated-root. Disabling these two allows for working with Snapshot files (that will be discussed in the subsequent). This 77080000 value can be used for both Catalina and Big Sur. Some may need to remove npci=0x2000; it is required for me as I leave "Above 4G decoding" disabled in BIOS. Moving onto ScanPolicy shown below. With this latest v061 commit, a proper ScanPolicy (rather than 0) can be used that limits filling the boot menu with useless EFI folders. This scan policy allows for the following drives to appear in the OC boot menu: APFS, HFS, SATA, SASEX, NVME, USB and PCI devices (the latter includes virtual disks, so this is a good ScanPolicy for a Proxmox VM config file). The Auxillary items (like Reset NVRAM) are accessed by pressing the spacebar on the keyboard while viewing the OC boot menu. (Another item that can be activated while viewing the OC boot menu is turning on verbose mode by pressing <Cmd><v>; p 33 of included Docs.) An important new OC setting is changing SecureBootModel to Disabled. The Default value, recommended by the OC Docs, will prevent many things from working, such as the Aquantia kext patch. Don't change this unless you have a good reason. The next issue to discuss is MmioWhitelist. There are references on the Dortania OC Guide for AMD (which has been discussed earlier on this thread) that are incorrect for the TRX40 build. I've tested these values and they don't work; but I've included for illustrative purposes. The MmioWhilelist array that is active (shown below) is actually empty. The other inactive one contains the MmioWhiltelist for my mobo (MSI Creator, which I posted earlier in this thread). I do not know, nor can I test, whether this will work for any other mobo. I would encourage deriving your own for your mobo. Finally, as far as ACPI, kexts and drivers, only a minimum are included. As mentioned earlier, the only other section you might adjust is if you need a different Ethernet driver from what is included in this EFI: SmallTree82576 and Aquantia AQC107. The AQC107 is activated by a kext patch which is Enabled/Yes (and was discussed by Pavo on the InsanelyMac forum). These two cover a majority of our builds and allow at least one Ethernet port to work. BT/Wifi kexts are included and presently Enabled/Yes; these will work with swapped cards as well as PCIe AICs. WEG is Enabled/Yes but partially disabled thru the -wegbeta boot argument. If WEG is left fully Enabled, Big Sur will not boot in bare metal. Lilu, VirtualSMC and AppleALC are Enabled/Yes as is AppleMCEReporterDisabler. Since this EFI is more inclusive and robust, I will delete the EFI folder presented on page 1 of this thread and replace it with a link to this post. As usual, you need to supply SN and SystemUUID values in the PlatformInfo/Generic section before using. EFI-v061-8e2755f-BareMetal-USB-installer-Public.zip Debug version (this is same as above, but does not contain the Install boot-args). The config file is different, adjusted to give more reports, so do not swap between release and debug versions. EFI-v061-8e2755f-BareMetal-USB-installer-Public-Debug.zip

See my comment to Ploddles. The things you're seeing on boot are some of the things I had to delete from his config file. Better to start with the EFI from GitHub or the EFI I uploaded here several days ago.

OK, I had to re-work a lot of stuff. It became too complicated to just give you back just a config.plist file, so I entered everything in to an EFI that is for your Xtreme mobo. This is derived from v061, just after v060 was made a release version, so it is really v060. It has the things that should also work for BS as well as Catalina. It is the not a debug version. This is the exact version I used to boot in Catalina bare metal for the first time. You added a lot things to the config files that shouldn't be there. I removed them as most are not necessary for any AMD or Intel mobo I've ever used. The order of SSDTs, kexts and drivers are important and you'd moved things around into orders that were not anything I'd uploaded or recommend. I've put them back into a better order. Your BT kext entries, I've left disabled; I don't have those files and anyhow I would recommend getting the system reliably booting before working on them. I also revised some new SSDT's for you as you were using some for other builds that wouldn't work. The only one that may not work is the Ethernet one, as it has a nested substitution. It should work, but since it's in a separate file, it won't interfere with other SSDT files, should it not. After booting, run IORE and save it. I can look at it later if there's a problem. (If you use a large SSDT, which does many things, and one part is broken, the whole SSDT won't work: it's better to have many SSDTs each doing a few things.) If at a later date, you want to modify stuff, make a copy of the config file that's working and leave the original alone so you have something to go back to that works. Better yet, kept a copy of what's working on a USB stick to be able to boot from that. I keep an EFI backup folder that contains every version I've worked on for each mobo. (The Spoiler below shows an excerpt from the TRX40 build of saved EFI folders.)

WEG problems appear with Radeon VII and NAVI AMD GPUs (I've only used AMD GPUs, so no nothing about NVIDA issues). On Intel, if using WEG and one of those AMD GPUs, the computer would freeze within 10 min after booting with the mouse becoming jerky just before the freeze. The only way around it was to disable WEG. When this was done, on some GPUs, one of the HDMI or Display ports would become inactive (I can't remember which now). And when trying to boot bare metal into BS on TRX40, it was impossible with WEG enabled. I later found out, through trial and error, that if "-wegbeta" were added to boot arg, then WEG could be left enabled and successfully boot into BS.

The schema errors appear when your using a mis-configured config.plist file for the particular version of OC. (In other words, you've probably kept the same config.plist file yet swapped out different OpenCore.efi files that now have different entries.) Another common OC mistake is to update parts of the OC folder and forget to also update the BOOT folder. All parts of OC's EFI folder need to be of same commit (well, not ACPI or Kexts folders). I don't include HiiDatabase.efi in GitHub site, so declaring this is config.plist and not having in Driver's folder will give a critical halt. Most of the driver's are not necessary, and I've excluded them from the Driver's folder on purpose. So upload your config.plist file (without SN info; you can replace that portion later; I gave instructions in Section 6 on GitHub site) and I'll try to fix it, but I'll adjust for the latest commit on get GitHub site that I just updated a few minutes ago. If you again swap out OC parts, the config.plist file will break again. *** Are you booting into BS or Catalina? VIrtualSMC seems more an issue for BS than Catalina. WEG is not necessary for either. I don't think any of the SSDT are important for a boot. The renames are important for Hackintool USB, but booting is okay without, but I like to include "2-SSDT-PLUG" and "3-SSDT-TRX40-EC-USBX-MCHC-SBRG" as a minimum.

OC v061 latest commit, 22 Aug. (Oddly, it still says 12 Aug date, but each couple of days there are changes.)

Not completely true. I'm finding virtually the same, with ever-so-slightly greater values in bare metal. The only tests where the graphic values are less is Geekbench. Since LuxMark values are the same in VM or bare metal (and LuxMark is one of the few tests that can use 2 GPUs), I think the test is problematic, not bare metal. (I've summarized on GitHub, section 9). And Geekbench GPU-Metal test is basically the same in bare metal or VM; the problem is with OpenCL.

I'm not sure that you want a Microsoft boot folder inside the OC EFI folder. What specific SATA are missing? Are they formatted for OS X or other OSs as this will affect what shows up. (If you want other OSs, you'll need different drivers.) Load a IORE file for your build. You don't want to use DSDT in OC on this build. As for USBs, I've never seen more than 10 ports per device. The 15 port limit is per device, not per machine. **** I've not seen any reboots with any tests on bare metal or VM. Some tests crash, like the Corona test, but on forced exit, the macOS was fine.

DaVinci will probably not work on bare metal with AMD unless you do the mods I wrote about earlier In this thread. I've used those mods successfully on AMD X570, but not yet tested on the TRX40 platform. Logic Pro X is no problem, and no problem with Final Cut Pro. I've tested both. Reaper is also functional. Adobe doesn't play nicely with AMD, but I cannot comment as I refuse to pay Adobe a penny for rental fees. I stopped using after Mojave (I keep Mojave on Intel machines to use older Photoshop, which is 32-bit).

Thanks. (I re-wrote some of section 7 and 10 this morning, adding the NVRAM reset stuff --- very important as I found out again while attempting to do a fresh BS install under bare metal.) As for the "fs0:" that may not actually be your boot EFI partition. Look at other EFI partitions on your setup. You'll probably find the memmap file located on another EFI partition. I can't comment on the emulated NVRAM as I've not tried it on this build. I briefly used it on a Z390 Designare build and I wasn't convinced it was much better than doing nothing. The only time I think emulated NVRAM is to permit the system to boot. On some of the Z390 builds (like the ASRock Z390 ITX build I wrote on my thread here a while ago, emulation was critical for proper booting). I think OpenCore gets around this (somehow) whether you've got emulated NVRAM working or not. Native NVRAM is theoretically the superior approach. I think it gets fouled up when we get crashes or when we attempt to boot between OS X versions. I alluded to this above when I mentioned having to reset NVRAM while attempting to install BS bare metal yesterday. I finally got half way through the 2nd stage of install when it froze. I could not get it pass that point. And after trying to continue the install, I could not boot back into Catalina until I did an NVRAM reset. There were no BIOS problems, just corrupted NVRAM, but again, this was fixable with a reset. I don't know how any of this would have faired if I'd been using emulated NVRAM. As for Proxmox, I've had my share of corruption of the entire macOS requiring me to re-install things. I've not written much about it, but when I've been silent here for several days it was due to those issues. (And yes, I gave up on GB TRX40 Designare; the MSI seems better, although I don't like its BIOS interface, preferring GB or ASUS.)

Ok, I've updated the EFI to add the kext and take into account your IORE. You need to do something different from the Designare mobo besides the kext file (which is off by default). In the ACPI section, you mostly want to use the MSI and not the SSDT for the Designare as that will cancel your BT. Instead use the sections shown below. The two new entries for the GB Xtreme are #24 and 25 (and correct to Xtreme rather than Extreme as in image below). I don't think you want to enable the SSDT-GFX's.

Ah, I didn't know you were using OC Configurator. I don't use it (I only use to generate SMBIOS data). I had too many weird things happen in past and spent hours trouble shooting more than one corrupted config.plist file (you can find the problems, but you need to study the file in text mode which is laborious). The developers of OpenCore do NOT recommend using OC Configurator. Truly, the one I prefer is PlistEdit Pro. (Even Xcode can foul up the config file by substituting 'real' values for 'integer' values, leading to boot errors.) I've uploaded more changes this morning to the EFI folder on GitHub with the latest OC commit. It boots just fine. After using it, do a re-set of your NVRAM. Also, remember you'll need to adjust the ACPI section as I've extensively renamed SSDT files to allow us all to use them, no matter the mobo manufacturer, in what I think is a more coherent fashion.

No, I've not tried. I have performed an update for Catalina and that went well. I'll attempt an install later on a spare drive.

I'm happy to hear that you solved your problem. What exactly did you do to fix it?

fabiosun, On bare metal, the CPU scores are the same as under Proxmox with Geekbench or Cinebench 20. With Luxmark, the scores for Radeon VII are the same under bare metal and Promox (and only Luxmark uses both GPUs). only with Cinebench 15 do I see a decrease of 50%. So maybe a problem with Cinebench 15?

This weekend when working up a config.plist file to boot into Big Sur, I would see this if WEG is active. It is okay to leave WEG active, but add -wegbeta to boot arg. I've stressed adding npc-0x2000 several times on this thread whether or not "Above 4G decoding" is enabled or not. The kexts I've loaded with the EFI on GitHub should cause no problems. Overall stability and random reboots will occur if Energy Saver is not disabled. I posted this earlier in this thread and on the GitHub site, Section 7.

GitHub post referral deleted

I have not had issues with running 2 simultaneous GPUs (mine are the same in slots 1 & 3), but the only install I've done is from within Proxmox. I have updated Catalina in bare metal and it went better than an update from within Proxmox. As for the SSDTs, I'll add a branch to my GitHub and keep updates there. I can make links back to this thread to avoid writing/repeating on GitHub. Give me a few days to get organized. And as to your IORE, I'd like to see it. So far, much is the same since the TRX40 chip dictates what's in IORE than what the mobo manufacturer's do.

Attached are 2 SSDT for cancelling what I've renamed to XHC1 and XHC2. They don't help, but I'm posting if you want to learn how to cancel devices. If you were to use, you want to remove the re-naming sections for XHC1 and XHC2 from the other SSDT file. As for stability, I've left the computer running all day and night and it seems fine. I'll recheck today and if okay, provide a list of settings, but what I'd updated in the uploaded config.plist file that will boot into Catalina or BS has what seems to be stable settings; but I'll re-visit the settings later. As for BIOS, I've left: ErP Ready, disabled; Above 4G decoding, disabled; and both IOMMU and SVM, enabled. EDIT: Above is obsolete: a proper MmioWhitelist is necessary for Shutdown (and being aware of attached USB devices which can force a re-boot).

Here are some reasons native NVRAM is useful. MacOS reads and writes data in NVRAM during many different phases of operation. Some of them are: When booting the computer, NVRAM identifies the Startup Disk. When rebooting or shutting down, information is written or updated in NVRAM. When there's a system crash, a background process stores kernel panic information into NVRAM. When you're running the macOS installer (which is not MacOS), it reads and writes information to NVRAM to select the right intermediate startup disks. FaceTime and Messages store various "keys" in NVRAM. Information about paired Bluetooth devices is also stored in NVRAM. This allows Apple Magic Mouse and Magic Keyboard to connect via Bluetooth before macOS is booted. And other little details are stored in NVRAM. NVRAM is used by: Apple boot loader (boot.efi) -- this is not macOS, it's an EFI boot loader. macOS installer -- this is not part of main macOS macOS updater -- this is not part of main macOS When we use emulate NVRAM, it stores NVRAM data in a file called nvram.plist in the EFI partition of the boot disk. But it requires OC to read/write that file. However: Apple boot loader cannot read/write that file macOS installer cannot read/write that file macOS update cannot read/write that file So we don't get all the functionality of NVRAM with emulation. But with native NVRAM, all components of the system can access NVRAM.

I've spent more time working on the shutdown problem than it took me to get native NVRAM working... I have tested various things I've found on-line that may contribute to the problem: 1. BIOS: ErP Ready (enabled/disabled), Above 4G decoding, IOMMU and SVM (turning latter two off for bare metal). 2. macOS: removing Library/Preferences/PowerMangement*.* 3. Verifying that PowerManagement is working. 4. Testing various kexts (VirtualSMC, WEG, AppleALC); removing all un-necessary kexts 5. SSDTs: removing un-used USB (specifically D0B8 and D1B8; attaching FixShutdown to all USB sites; checking RHUB devices 6. USBPorts to limit/inject properties 7. Removing unnecessary devices from USB ports 8. Read about how some people have had this issue with AMD after moving from Clover to OC, so I tried to set up a Clover EFI (not yet successful) 9. Testing various settings within OC, such as Darkwake boot arg; DummyPowerManagement and other Quirks None of these have worked. I'm wondering if #8 is the issue and it's an OpenCore matter. Or perhaps OC is correlated and not causative; that is, maybe we need another patch. Any ideas on a kernel patch for shutdown?