trx40 [Discussion] - TRX40 Bare Metal - Vanilla Patches

[meina222]

I need to install snagit or something. Sorry for the bad resolution. Mine are there but look a bit more involved

 

[iGPU]

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.

 

 

 

Edited September 7, 2020 by iGPU
obsolete; provided link to future fix

[iGPU]

17 hours ago, fabiosun said:

Uhm... my system shutdown normally

only in reboot I can see (maybe) a kp but I am not sure because it has no consequences at all

Whitelisting is useful togheter the research of a proper slide value for owned system

it is possible to calculate your exact memmap and the use a slide value

not tested for now because in my bare metal main problem is sip 

 

@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:

Spoiler

After first disable:

 

After re-enabled:

 

 

Edited August 16, 2020 by iGPU
added SIP link for OpenCore

[meina222]

I applied the files. Attached is my IO reg. Do you see anything regarding your FixShutdown SSDT?

 

Also don't we need to do this for every controller? XHC, XHCI etc. ?

 

Also my USB reporting doesn't look quite right - Hackintool sees 2 XHC0 controllers

 

TRX40Designare.zip

Edited August 16, 2020 by meina222

[iGPU]

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.

 

 

Edited September 18, 2020 by iGPU
removed config.plist file

[meina222]

For me an EFI that installed Catalina booted but failed during Big Sur installation. Let me try your config. I wouldn't think the whitelist/nvram would be critical for that so I will remove for now. My USB mappings don't seem to work in Catalina. I've attached my IOReg, but so frustrated I think I will just backup my EFI and try BigSur again clean.

 

p.s. to be precise the file that defines XHC and XCHI works and disables my AX200 after I delete port5. The other XHCx rename file - I don't think it works so I disabled it.

 

p.s. 2 - studying your efi shows you use more renames. Let me try with just basics on the install. Will worry about those later.

Edited August 17, 2020 by meina222

[iGPU]

On 8/16/2020 at 4:06 PM, meina222 said:

I applied the files. Attached is my IO reg. Do you see anything regarding your FixShutdown SSDT?

 

Also don't we need to do this for every controller? XHC, XHCI etc. ?

 

Also my USB reporting doesn't look quite right - Hackintool sees 2 XHC0 controllers

 

TRX40Designare.zip 13.52 MB · 0 downloads

 

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.

 

Spoiler

 

 

 

 

On 8/16/2020 at 5:19 PM, meina222 said:

For me an EFI that installed Catalina booted but failed during Big Sur installation. Let me try your config. I wouldn't think the whitelist/nvram would be critical for that so I will remove for now. My USB mappings don't seem to work in Catalina. I've attached my IOReg, but so frustrated I think I will just backup my EFI and try BigSur again clean.

 

p.s. to be precise the file that defines XHC and XCHI works and disables my AX200 after I delete port5. The other XHCx rename file - I don't think it works so I disabled it.

 

 

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.

 

Edited August 23, 2020 by iGPU

[iGPU]

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:

 

 

Edited August 17, 2020 by iGPU

[meina222]

BigSur didn't work for me - tried to adapt your config plist and got a message that my platform is not supported by MacOS. Anything special about your boot args that would trigger this? I should clarify - I tried to install it again.

 

The idea of bypassing the installer via the VM is an great one!

 

Thanks - your latest SSDTs split my controllers. I now need to set correct capabilities.

Edited August 17, 2020 by meina222

[iGPU]

39 minutes ago, meina222 said:

BigSur didn't work for me - tried to adapt your config plist and got a message that my platform is not supported by MacOS. Anything special about your boot args that would trigger this? I should clarify - I tried to install it again.

 

The idea of bypassing the installer via the VM is an great one!

 

Thanks - your latest SSDTs split my controllers. I now need to set correct capabilities.

 

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:

 

 

 

[meina222]

My smbios is iMacPro. The failed install earlier in the day was MacPro7,1 but the latter works great in a BigSur VM. My VMs are on a zfs pool though and I only had 1 NVME spare so can't try BS the way you did as no NVME has it. I will carbon copy clone it and retry later in the week.

 

I am confused by NVRAM and all the quirks. Why is it so important to have native NVRAM? Is there anything critical related to power management / sleep / shutdown which emulated NVRAM can't meet? I honestly would prefer emulated if the only thing it does is persist info between boots. And I would prefer not to mess with SIP. I have no special hardware beyond the patched CPU I'd like to run unlike @fabiosun .

 

The OC manual only briefly mentions csr-active-config without explaining what it is.

 

Gotta say I have some gaps in knowledge that make this TRX40 quite challenging. I imagine same is true for X299 but at least many more samples exist out there. 

[iGPU]

On 8/16/2020 at 8:38 PM, meina222 said:

My smbios is iMacPro. The failed install earlier in the day was MacPro7,1 but the latter works great in a BigSur VM. My VMs are on a zfs pool though and I only had 1 NVME spare so can't try BS the way you did as no NVME has it. I will carbon copy clone it and retry later in the week.

 

I am confused by NVRAM and all the quirks. Why is it so important to have native NVRAM? Is there anything critical related to power management / sleep / shutdown which emulated NVRAM can't meet? I honestly would prefer emulated if the only thing it does is persist info between boots. And I would prefer not to mess with SIP. I have no special hardware beyond the patched CPU I'd like to run unlike @fabiosun .

 

The OC manual only briefly mentions csr-active-config without explaining what it is.

 

Gotta say I have some gaps in knowledge that make this TRX40 quite challenging. I imagine same is true for X299 but at least many more samples exist out there. 

 

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:

Spoiler

 

NVRAM:

Spoiler

 

UEFI:

Spoiler

 

 

Edited September 18, 2020 by iGPU

[fabiosun]

I am giving up on bare metal because for now I can’t install nvidia web driver in a correct way

i use high Sierra as you know and in proxmox I have not problem

i have solved SIP problem which help to load one kext for nvidia

others 3 kext s are not loading.

to have a correct sip behavior I have enabled AvoidRuntimeDefrag quirk

with this I can enable and disable sip totally from high Sierra recovery

without nvidia driver loaded I can’t test all the things I have in my mind to do

i have an idea that proxmox is far better than bare metal, but thunderbolt study is better in bare metal because it depends only from our efforts and not from Linux missing bridges devices...

if I recover my mental energies 😂

I will try to understand well nvram problem 

latest observation and studies by @igpu are now correct in my opinion

 

On discord thread hackintosh Slav says to isolate mmio which could avoid proper nvram working

idk if it is related or not...

[meina222]

@fabiosun - I think I am also close to giving up but not yet. I am still baffled by the restarts on shutdown and lack of sleep but I guess this is not uncommon for early hacks - all in all the fact that this is the only issue (and perhaps the seemingly worse power management) is not bad at all. I will definitely go through @iGPU's exercise. I feel like I want to script this so you can avoid all the manual steps - just auto parse the OC debug output from 1 run and generate X pre-calculated configs that you can then just drop and re-try. I'll see what I can do - it'd be fun exercise.

 

To me the biggest draw of Proxmox is the isolation layer it provides and the ease of back ups / replication / reinstalls - no worries if I brick my VM with an update, and much less likelihood of a break. That paired with superior power management in the newest Linux kernel, makes it quite compelling. Due to the AMD reset bug I am now forced to emulate a bare metal workstation - host shutdown on macOS shutdown via hook, but when the reset bug is finally solved with new hardware this will be close to perfect setup minus the TB and less physical ports.

 

Btw Linux kernel / Proxmox 5.8.1 is out. This is labeled as 'stable' by the Linux community - suitable for production use. Fabian has a release already in 2 flavors (reset and no reset, but this does not affect our OS).

 

[fabiosun]

hi @meina222if you know my history in trx40 task you will see I do not give up easily..

but here my main problem is GPU

I do not want a radeon VII because it similar in benchmark to my Nvidia and I am waiting for Big Navi

I have tested all I can for Nvidia and High Sierra

but I am alone in this..and I am not able to debug clearly where my problem is

 

However I have my disk ready and an usb pen to test if something new happen

 

Redoing all debugging in MMIO as I did in the past to have this system working ...mmmhh now I have less strength for this..because trx40 in Proxmox works 🙂

 

If you have any ideas to test or a Nvidia to try on your rig..I will happy to be into this game again! 🙂 🙂

 

[iGPU]

5 hours ago, meina222 said:

@fabiosun - I think I am also close to giving up but not yet. I am still baffled by the restarts on shutdown and lack of sleep but I guess this is not uncommon for early hacks - all in all the fact that this is the only issue (and perhaps the seemingly worse power management) is not bad at all.

 

 

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.)

[fabiosun]

5)

many apps need to be patched to work and some does not work well as in proxmox

6)

if some thing change in the kernel...pufff ..our rig does not boot anymore

 

these 2 points are common in every AMD rigs

 

3) Nvidia web driver seems to have problems to activate (only for me maybe)

 

[Ploddles]

Yeah, finally got bare metal Catalina installed. 😀

 

Turns out that it didn’t like having 2 graphics cards in the machine during install - with just the one it flew along nicely. After the install I put the other one back in just to check but it didn’t miss a heart beat. The 2nd card was an Nvidia 1050, which I know can’t be used in Catalina but was installed for Proxmox when I was trying to get that to work and passing through the RX580.

 

i have the usual restart issue that everyone else seems to have,  but have now seen the other SSTDs that @iGPU has shared and also a new config file that works with Catalina and Big Sur. I will have a play with those later in the week. I did try an install of BS (with my Catalina config file) but that just hangs after the first reboot.

 

If anybody wants my IOReg file to look at to compare between different motherboards just let me know, I have the Gigabyte Xtreme.

 

There are a lot of files floating about in this thread and it can be hard to keep an eye on what is what and remember to update as things are discovered and files are modified. Would it be a good idea to have somewhere, maybe a sticky post or section in the downloads section, where new/updated files can be upload/downloaded to save everybody jumping  around looking for things and trying to remember what each one if for, eg common SSDTs for all boards and then those specific to MSI, Gigabyte etc etc? Just an idea but could be a pain to administer depending on how it is done.

 

Anyway, thanks for your help guys, glad to be finally up and running. Now to try the Adobe fixes later this evening.

[meina222]

@iGPU - I did the white list exercise last night. Haven't calculated my slide yet as it was getting late. It required only 4-5 reboots as I noticed the same pattern - bottom 2 addresses can left ON, then the next 2 fail so I have to leave them OFF, then once I hit the 5th to be ON, I enabled everything above it (as I think it only make sense to hit one continuous area where you gave to de-virtualize), and it booted with only the 2 ON, 2 OFF, everything else ON configuration.

 

I now have the same result as you - when I shutdown, I hear a click and the board tries to power cycle but then comes immediately back up. This is good news as this means all platforms share the same quirk. My addresses were of course different. Tonight I will try slides and test NVRAM.

Edited August 18, 2020 by meina222

[meina222]

Tonight the bare metal hack started experiencing extreme instability where even my rescue USB would immediately reboot after a black screen when the GPU driver is supposed to load while my NVME would boot, stay fine for 2-3 min and then suddenly reboot without me doing much. What could be the cause? Corrupt NVRAM or mis-calculated slide? Why would the rescue USB fail so bad?

[fabiosun]

Mmio adjustement could be tricky

if you do not have any big problem i will stay away from touch it

trx40 works for now but it is not clear why..

patches are the same, bios version in my case seems to be irrelevant

Only opencore could have done the job for us

but opencore’ s devs do not support AMD cpu

so it is so difficult to understand and also on AMD-osx people is not interested on a ‘niche’ product as trx40 

[iGPU]

23 hours ago, meina222 said:

@iGPU - I did the white list exercise last night. Haven't calculated my slide yet as it was getting late. It required only 4-5 reboots as I noticed the same pattern - bottom 2 addresses can left ON, then the next 2 fail so I have to leave them OFF, then once I hit the 5th to be ON, I enabled everything above it (as I think it only make sense to hit one continuous area where you gave to de-virtualize), and it booted with only the 2 ON, 2 OFF, everything else ON configuration.

 

I now have the same result as you - when I shutdown, I hear a click and the board tries to power cycle but then comes immediately back up. This is good news as this means all platforms share the same quirk. My addresses were of course different. Tonight I will try slides and test 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?

Edited August 19, 2020 by iGPU

[iGPU]

On 8/16/2020 at 8:38 PM, meina222 said:

I am confused by NVRAM and all the quirks. Why is it so important to have native NVRAM? Is there anything critical related to power management / sleep / shutdown which emulated NVRAM can't meet? I honestly would prefer emulated if the only thing it does is persist info between boots.

 

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.

Edited August 19, 2020 by iGPU

[fabiosun]

Nvram is also used to store nvidia driver status (web driver or OS X default nvidia driver)

[fabiosun]

a bit OFF Topic 

 

Clover boot loader booting fine on an AMD 3950 x thanks @iCanaro for filming 🙂

more infos here: