iGPU

The issues I have with bare metal so far: 1. Shutdown problem 2. TB - no USB functionality 3. Questionable graphics (rumor; I've not fully checked out) 4. No SIP control with Big Sur (but same issue on VM, so not a bare metal problem) I've got about 4 or 5 things to check out tonight/tomorrow for the shutdown issue. I think it's solvable. I'll certainly post here once I have more info. As for sleep, fixing shutdown can help with that too. The way I deal with all Macs (hacks or not) is to completely turn off energy saver. I don't allow sleep, just let the monitor go to a screen saver. If I'm really worried about energy and I'm not using the machine, I simply turn it off. (How much more green by turning off can you get?) So for me, sleep has always been a non-issue. I'd like to see an automated approach to the data analysis; it should be easy to do for the slide calculation (in fact, I was wondering why during OC debug that it wasn't done already.)

On attempting to refine the config file, I found that WEG does prevent a boot into bare metal BS (but is okay for Catalina). If left enabled, then one must enter the boot-arg "-wegbeta". Similarly, AMDRyzenCPUPowerManagement kext prevents a bare metal BS boot (but is okay for Catalina). Lilu, VirtualSMC, AppleALC, the ethernet kexts, the AirportBrcm kexts and NVMeFix are all okay, using latest versions. booter-fileset-basesystem and booter-fileset-kernel are not required as shown below. Most importantly, this config.plist file boots into both Catalina and Big Sur bare metal (one config to rule them all...). Booter and Kernel Quirks: NVRAM: UEFI:

I think that a fresh install is tricky. It was easy to install via VM. I kept an EFI on an external USB drive and used that to repeatedly attempt to boot into Big Sur. When it didn't work, I shut down computer and transferred the USB drive (1 TB SSD) to my laptop where I edited the EFI/config file. And cyclically repeated this process until it booted into Big Sur. For first boot, I'd disable most SSDT and kexts. One key were the Booter/Quirk settings. I've since removed most of the boot arg (only using slide=128 brcmfx-driver=2) and have still gotten into BS. That reminds me, what is your SMBIOS? I have things set up for iMacPro1,1. If you're running as MacPro7,1 things may be more finicky. (I personally think iMacPro1,1 is much better and more reliable; but to each their own.) From readings, having car-active-config in the delete section is important for OC NVRAM behavior, shown highlighted below:

Cannot get SIP to disable in Big Sur; it only seems to disable in Catalina. (BTW, native NVRAM is still working with same set up as described in recent posts for Catalina.) The car-active-config in OC for booting into BS was set to: FF0F0000 as described "here for Disabling SIP". After booting into BS Recovery and disabling both csrutil and csrutil authenticated-root, the status in BS is below:

You won't see anything attached to USB devices; it's just a take off point, like PMCR which was 'attached' to MCHC, but actually appears elsewhere. And no you do not need to enter for each USB device; it doesn't work that way. In reviewing your IORE, if you want to change this section to have USB ports, use the attached SSDT file labelled D1B8. If you want to do the same at the USB device at D0B8, use the file labelled D0B8. Each will re-name to XHC1 and XHC2. Yes, the other file may not be necessary for you, but it was for my MSI mobo. While the TRX40 has our USB devices showing up exactly the same, the responses may be a bit different.

Ok, I'm posting this from Big Sur running in bare metal! A 2nd NVMe drive in the computer contains Big Sur (the other is for Catalina). So I simply booted into a working Big Sur; no installation was done. My current config.plist file will boot into both Big Sur and Catalina. The AMD patches were identical; I changed nothing in that section. I initially could not get a boot with WEG enabled. Now -wegbeta" is added based on information from a later post here. But you can see what kexts I had either enabled or disabled from the config file. AvoidRuntimeDefrag = enabled seemed key to getting Big Sur to boot. You'll need to update ACPI sections, MmioWhitelist (which now blank); look at everything! Especially notice the NVRAM sections which reflect the changes for Catalina and Big Sur. You'll also need to update the PlatformInfo section with your own SNs. I've pasted in values (but not verified to be un-used). EDIT: MmioWhitelist is very important for bare metal functionality.

@fabiosunAfter testing FixShutdown-USB and having completed the slide calculations discussed above (meaning native NVRAM), I went into Catalina recovery, ran "csrutil disable" then "reboot" and then booted into Catalina. The OC config file does have SIP turned off (E7030000). The following is shown in Terminal: Re-booted into Recovery, re-enabled SIP and back into Catalina: So I can go back and forth, disabling or enabling SIP. Since we both have MSI mobos, so I think this should work for you once you get native NVRAM working! Also, please look over this area at this link (look near bottom, above "Post Install" for "Disabling SIP"). There are differences for OpenCore and SIP, esp with Catalina and Big Sur. *** SilentKnight, a free tool to verify macOS firmware, can be downloaded from here: SilentKnight reports in spoiler:

I don't think that will matter. I have now tested and computer shuts down, clicks off... but then immediately clicks back on again. So better, but not perfect. (This might be a USB connected device problem that I'll need to sort out; so hopefully just my problem.) Attached is the SSDT-TRX40-FixShutdown-USB file. It must be paired with two other files and used in the ACPI section in the order shown below. The order is important because FixShutdown attaches to site XHC that is created by the other two files. All of the TRX40 mobo's IORE files, which I've seen, have these USB devices so I think everyone can use them. However, for you @meina222, you'll need to edit the BYD8 file to remove, as I recall, PRT5 in order to cancel your BT/WiFi device. Back-to-the-future: we now know that proper Shutdown requires a good MmioWhitelist for your mobo. See this post to create that list.

As for SSDT-Shutdown, I've already confirmed that the patch (below) has indeed a _PTS function inside our DSDT file (bottom). So the call should work. Next step is finding attachment site for the SSDT call. The original site is "_SB.PCI0.XHC_.PMEE" which doesn't exist on our mobo. I have created an XHC, but I think wrong site for attachment. I originally tried the USB site at D0B8 and the computer would not boot. Again, the patch is enabled along with the SSDT-Shutdown file; neither by itself will work.

Yes, this is the next SSDT I was going to work on. It must be paired with a patch. The problem was attaching it to a USB device. Through yesterday, I was still sorting out USB devices with custom SSDT files. I'll work on it shortly. All ports are now accounted for and re-named. (I can provide custom SSDTs if anyone wants. I just need more recent IORE file to study). *** As far as USB go, I seem to recall one of your posts indicating that you'd created a USB-Ports kext to limit USB ports. In my exposure to AMD platforms, I've not yet seen a USB device that has more than 10 USB connections. The 15 USB macOS limit is per device not per machine. So I've seen no need to create any USB limits for AMD to date. (Intel is different, they have sometime 20 USB connections on one device.)

Those very duplicate boot entries is why OpenCore has this (red box) to eliminate those duplicate entries. It sounds like you should enable this Quirk.

I've just finished extensive re-editing of my previous post. A notable error was fixed (Booter/Quirks/ProvideMaxSlide should remain at "0") and the slide value placed in boot arg section. EDIT: slide not needed.

I'll lay out the steps I went through to derive the MmioWhitelist. But first I want to say that aside from the slide value of 128, I'd tried various OC combinations to obtain native NVRAM including using the new SSDT-NVRAM. None worked. Only when combining the Quirks reported above and MmioWhitelist and using the SSDT-TRX40-NVRAM did native NVRAM work on bare metal. Steps for deriving MmioWhitelist (make certain that you have an alternative bootable EFI, as you'll see below): A. MmioWhitelist Determination EDIT: Updated from future link at step 4. Initial steps for creating the debug file are still accurate. 1. Run OC debug version (≥ v059; even if you can't fully boot into macOS, you'll have sufficient data written out on the next boot with a non-debug, working version). a. debug OC settings (spoiler): b. after running OC-debug, you'll see following on the EFI boot partition; choose one to open (spoiler): 2. Edit debug text. Once the above text file is open and search for MMIO (spoiler; press press <Cmd><f>, enter "MMIO", then repeatedly press <Cmd><g> until you see list below). a. note the MMIO value range and the permissible Slide value range: b. the 0xYYYYYYYYYY values are copied one-by-one into a calculator (I use the calculator in Hackintool): 3.After converting each of the MMIO hex values into decimals, enter those values (and any optional comments) into Booter/MmioWhilelist (spoiler). Initially, leave all entries disabled (no): 4. Back-to-the-future: we now know a simpler way to create an MmioWhitelist for your mobo. See this to create that list. A proper MmioWhitelist is needed for proper Shutdown functionality as well as native NVRAM. B. Slide Calculation (left as an FYI reference, but not seemingly needed, so don't waste your time with it) 1. memmap calculations a. to run memmap, you need to have OpenShell enabled in OpenCore: b. boot into OC menu system and select "Open Shell" (or however you named it above). you'll then see "shell> ", type "fs0:" then type "ls" and see if you see the EFI folder. Is so, then type: "meemap > meemap.txt" fs0:\> meemap > meemap.txt fs0:\> exit c. after typing exit above, you'll return to the main OC menu and boot normally into macOS d. open the EFI partition (if you have more than one, it may not be on the boot EFI, so look around at other drives) e. locate the file mammal.txt and copy to desktop. once this file is open, you'll see something like this (here, only top portion of the large file): f. OC guides say to start at bottom of list (Start column only). if you do, you'll calculate a slide value something like 2047; some such nonsense. instead start near top and find the largest value that is ≤ 255. The optimum is highlighted by red box above. the value immediately below calculates to a slide of 1018, which is also nonsense. The one in the red box will calculate to 127 as shown next, so this is the largest value that is ≤ 255. g. calculations are done in 2 basic steps using the macOS calculator ( type <cmd> <3> to select the Programmer mode): i. the value from above red box is 000000001000B000 which is 0x1000B000 in hex. we'll do all math in hex. next, subtract and divide this value as follows (copy and paste from here; the trailing zeros are important): ( 0x1000B000 - 0x100000 ) / 0x200000 = 0xFF0B000 / 0x200000 = 0x7F ( 0x7F = 127 in decimal ) ii. the 2nd step is verifying above result to see if the decimal value of 1 needs to be added. verification means taking the above answer, 0x7F and reversing the calculation to see if we get the original hex value. If we do, then 0x7F is our final answer (and slide is the decimal value of this, or 127). If it calculates to a different value, then we must add the decimal value of 1 to 127, which means the true slide value is 128. Reversing the equation: ( 0x7F x 0x200000 ) + 0x100000 = 0xFE00000 + 0x100000 = 0xFF since 0xFF ≠ 0x7F, the actual slide value is 127 + 1 = 128 2. Using the Slide calculation result the result of step 1-g-ii above is your slide value to be entered into the boot arg section as shown in the spoiler below. the ProvideMaxSlide value's default is 0, which means that OC will accept a boot arg slide value ranging from 0 to 254. any value other than 0 will be the maximum value of a slide boot argument; best to leave as default 0. (And oddly enough, this is the same value I'd chosen from above MmioWhiltelist section of 128.)

Any from v059 will do (I think v060-final is about the best). Most data is written while booting and so even if it doesn't fully boot, you'll get this data. *** Well, shutdown almost works. Before activating NVRAM, computer would effectively do a re-start. Now, the switches click off but then immediately it powers back on and boots (panic reboot). At this point, the panic reboot could be triggered by USB devices connected to the computer. I'll need to test some more tomorrow.

I based on what I reported above. The value range came from OC's debug report associated with MmioWhitelist. I simply tried the first one, 128 and it worked. EDIT: a Slide is not needed.

Yeehaw! I got NVRAM working (again, I do not know if the values below are CPU or mobo dependent; but worth a try). Test in Terminal: a) enter: sudo nvram myvar=test b) verify: nvram -p | grep -I myvar c) reboot d) run nvram -p | grep -I myvar (if you only run "nvram -p" you'll see all stored values) e) clear test: sudo nvram -d myvar Use the following settings in OpenCore: 1. Slide =not needed 2. The MmioWhitelist value (its derivative in complicated; better described in future post here). 3. DevirtualiseMmio enabled 4. SSDT-NVRAM EDIT: we now know that proper Shutdown requires a proper MmioWhitelist for you mobo, see above link for MmioWhitelist.

Until we get system shutdown working, using the ResetSystem.efi works: It creates an Auxillary shutdown button: So when macOS is shutdown, the computer starts up again, I press the space bar to reveal "Shutdown" and this turns the computer off. (BTW, those buttons are not stock but were present in the EFI I uploaded earlier in this thread.)

At the bottom of the MMIO debug section, it said: 18:289 00:002 OCABC: Only 128/256 slide values are usable! 18:291 00:002 OCABC: Valid slides - 128-255 So maybe a slide value needs to be entered? I'll give that a try too. EDIT: SLIDE IS NOT NEEDED. *** I'll try combining that with a SSDT-NVRAM. I'll upload so that you all can try too. In the Docs section, there is an SSDT-NVRAM that is used to attach PMCR to LPCB (so that it is activated before PCI devices). But in our TRX40s, LPCB does not exist. It was, as described, an arbitrary attachment site. I decided to use MCHC, since it has a similar structure in IORE (based on my studying earlier today an Intel Z390 Designare). MCHC is created in the SSDT-EC-USBX-v2 that I uploaded earlieir, and accordingly, SSDT-NVRAM must come after as follows: The binding looks like this in IORE:

I did some more testing of MmioWhitelist and DevirtualiseMmio, and I don't understand it. Back-to-the-future: we now know that proper Shutdown requires a proper MmioWhitelist for you mobo. See this post (future) to create that list. I thought the idea was to be able to disable DevirtualiseMmio, since this is supposedly confounding NVRAM. I obtained a set of MmioWhitelist that allowed booting, but while DevirtualiseMmio was enabled. I then disabled DevirtualiseMmio and used the bootable MmioWhitelist to attempt to boot into Catalina. It did not boot. I then reversed the enabled/disabled items in MmioWhitelist, and this too did not boot (DevirtualiseMmio was again disabled). So I fail to see the benefit of MmioWhitelist since no matter what their settings, DevirtualiseMmio needs to be enabled. Can someone please enlighten me?

CFG Lock doesn't apply to AMD.

I've been mostly working on NVRAM (which does not work) and Shutdown. No success with either, but maybe getting closer as I'll describe below. Meanwhile, I've managed to get better creation of EC and MCHC, as compared to how they function on the Intel side. They should work on all of our TRX40 mobos. I think I also have one for NVRAM, but I was reading on Discord (responses to fabiosun) about how our use of DevirtualiseMmio may have broken NVRAM. So I've spent most of this afternoon chasing down MmioWhitelist. I found the following using OC debug (this may only apply to the 3970X chip: I honestly don't know. The numbers to the right are the calcuated values of the hex humber on the left. They end up being plugged into OC: When I ran tests, turning each one on at a time and re-booting, I found that I could boot into macOS, with DevirtualiseMmio enabled, if the following were enabled: 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 18 and the following disabled: 15, 16, 17. That's what's reflected in the above table. Now I'm trying to figure out what to do with this information. From the Discord comments, it sounds like we want to now disable DevirtualiseMmio to get NVRAM working. More testing later.

Has anyone been able to boot bare metal into Big Sur?

NVRAM is not working on Catalina bare metal with OC v061.

I've tried a couple of SSDT/patches and so far no success in preventing the shutdown reboot loop. I had this issue with a Z390 build. I think I fixed it by settings in BIOS and boot loader, but that was on Intel

I sourced an old GB-Titan Ridge AIC (previously flashed). The TB part works great, but not the USB. Very odd. I know that the card is good as it does have proper TB/USB when used in other machines, including an AMD X570. Shown below is what's seen when a TB HD is connected to one port; ideal result: The other port has a USB-C drive connected, but the drive does not mount: Without a TB SSDT, there is only 1 device shown under the 15ec USB section. This is not correct. There should be 4 items listed, not 1: