iGPU

Just now, fabiosun said:

 

I would like to have this 🙂

why @iGPUwe do not have it?

maybe a different patched firmware?

or Gigabyte does this better than MSI?

I think he has USB exposed also without SSDT

 

I think it's because GB Designare is made to support TB. I think it has to do with power being injected, which is an area I've been studying. It might be possible using a custom DSDT.

7 minutes ago, meina222 said:

 

I often make this mistake and have the habit of double checking while typing, but not this time.

 

IOReg w fix attached. It's now structured as coded. Thanks! On to testing some functionality.

MyMacPro.zip 7.29 MB · 0 downloads

Hey, this is NOT fair!!

You've got USB-C activated!!

If you now load up Hackintool, you'll see XHC5 (I re-named it so that it will be distinguished from other XHCx devices).

7 minutes ago, Pavo said:

This is correct. 

This is incorrect Min 17.x.x with a Max of 20.x.x means used if set to enabled (yes) from High Sierra to BigSur. Not Catalina

Really? I thought the range is contiguous, so that min 17.00 and max 20.99 would be as fabiosun said (HS, Mojave, Catalina and Big Sur). The only way to isolate a patch is to duplicate.

Example, this will exclude Catalina, and only be active for HS, Mojave and Big Sur (if both enabled):

one patch set to:     : min 17.00, max 18.99

duplicate patch set:  min 20.00, max 20.99.

I see the error and didn't notice first time when reviewing your SSDT: you have typos.

Replace the "O" (ohs) with "0" (zeros). Notice how D0CA is correct: zeros have a slash through the symbol; the capital letter "O" does not. So SOD2 --> S0D2.

(This seems to be an American problem: people here say for 405: "four-oh-five", instead of saying "four-zero-five". I believe that this leads to such typos.)

32 minutes ago, meina222 said:

@iGPU, I applied the SSDT you shared (after DTGP and a few others). Didn't get reflected in IOReg. Here is what the logs says. 1st spoiler is showing that the table by CASEY is loaded.

 

But a bit further down I have ACPI error - AE_NOT_FOUND, SSDT:TBTITAN.

 

I don't know ACPI well to know if this is BIOS or SSDT issue, but I think I tried very similar structure yesterday following guides so maybe not SSDT bug?

 

 

 

  Hide contents

 

2020-09-06 10:06:53.862314-0400 0x71       Default     0x0                  0      0    kernel: (AppleACPIPlatform) ACPI:
2020-09-06 10:06:53.862314-0400 0x71       Default     0x0                  0      0    kernel: (AppleACPIPlatform) ACPI:
2020-09-06 10:06:53.862342-0400 0x71       Default     0x0                  0      0    kernel: (AppleACPIPlatform) SSDT 0x0000000069A97000 000893 (v02 CASEY  TBTTITAN 00000000 INTL 20200110)
2020-09-06 10:06:53.862343-0400 0x71       Default     0x0                  0      0    kernel: (AppleACPIPlatform) SSDT 0x0000000069A97000 000893 (v02 CASEY  TBTTITAN 00000000 INTL 20200110)
2020-09-06 10:06:53.862671-0400 0x71       Default     0x0                  0      0    kernel: (AppleACPIPlatform)
2020-09-06 10:06:53.862671-0400 0x71       Default     0x0                  0      0    kernel: (AppleACPIPlatform)

 

2

  Hide contents

 

020-09-06 10:06:53.898966-0400 0x71       Default     0x0                  0      0    kernel: (AppleACPIPlatform) ACPI Error:
2020-09-06 10:06:53.898967-0400 0x71       Default     0x0                  0      0    kernel: (AppleACPIPlatform) ACPI Error:
2020-09-06 10:06:53.899041-0400 0x71       Default     0x0                  0      0    kernel: (AppleACPIPlatform) [WT1A]
2020-09-06 10:06:53.899041-0400 0x71       Default     0x0                  0      0    kernel: (AppleACPIPlatform) [WT1A]
2020-09-06 10:06:53.899078-0400 0x71       Default     0x0                  0      0    kernel: (AppleACPIPlatform)  Namespace lookup failure, AE_ALREADY_EXISTS
2020-09-06 10:06:53.899079-0400 0x71       Default     0x0                  0      0    kernel: (AppleACPIPlatform)  Namespace lookup failure, AE_ALREADY_EXISTS
2020-09-06 10:06:53.899345-0400 0x71       Default     0x0                  0      0    kernel: (AppleACPIPlatform)  (20160930/dswload-462)
2020-09-06 10:06:53.899346-0400 0x71       Default     0x0                  0      0    kernel: (AppleACPIPlatform)  (20160930/dswload-462)
2020-09-06 10:06:53.899493-0400 0x71       Default     0x0                  0      0    kernel: (AppleACPIPlatform) ACPI Exception: AE_ALREADY_EXISTS,
2020-09-06 10:06:53.899494-0400 0x71       Default     0x0                  0      0    kernel: (AppleACPIPlatform) ACPI Exception: AE_ALREADY_EXISTS,
2020-09-06 10:06:53.899710-0400 0x71       Default     0x0                  0      0    kernel: (AppleACPIPlatform) During name lookup/catalog
2020-09-06 10:06:53.899710-0400 0x71       Default     0x0                  0      0    kernel: (AppleACPIPlatform) During name lookup/catalog
2020-09-06 10:06:53.899870-0400 0x71       Default     0x0                  0      0    kernel: (AppleACPIPlatform)  (20160930/psobject-310)
2020-09-06 10:06:53.899871-0400 0x71       Default     0x0                  0      0    kernel: (AppleACPIPlatform)  (20160930/psobject-310)
2020-09-06 10:06:53.900055-0400 0x71       Default     0x0                  0      0    kernel: (AppleACPIPlatform) ACPI Exception: AE_ALREADY_EXISTS,
2020-09-06 10:06:53.900056-0400 0x71       Default     0x0                  0      0    kernel: (AppleACPIPlatform) ACPI Exception: AE_ALREADY_EXISTS,
2020-09-06 10:06:53.900272-0400 0x71       Default     0x0                  0      0    kernel: (AppleACPIPlatform) (SSDT:SHAKTOOH) while loading table
2020-09-06 10:06:53.900272-0400 0x71       Default     0x0                  0      0    kernel: (AppleACPIPlatform) (SSDT:SHAKTOOH) while loading table
2020-09-06 10:06:53.900487-0400 0x71       Default     0x0                  0      0    kernel: (AppleACPIPlatform)  (20160930/tbxfload-319)
2020-09-06 10:06:53.900488-0400 0x71       Default     0x0                  0      0    kernel: (AppleACPIPlatform)  (20160930/tbxfload-319)
2020-09-06 10:06:53.901190-0400 0x71       Default     0x0                  0      0    kernel: (AppleACPIPlatform) ACPI Error:
2020-09-06 10:06:53.901190-0400 0x71       Default     0x0                  0      0    kernel: (AppleACPIPlatform) ACPI Error:
2020-09-06 10:06:53.901264-0400 0x71       Default     0x0                  0      0    kernel: (AppleACPIPlatform) [_SB_.SOD2.D2A2]
2020-09-06 10:06:53.901265-0400 0x71       Default     0x0                  0      0    kernel: (AppleACPIPlatform) [_SB_.SOD2.D2A2]
2020-09-06 10:06:53.901363-0400 0x71       Default     0x0                  0      0    kernel: (AppleACPIPlatform)  Namespace lookup failure, AE_NOT_FOUND
2020-09-06 10:06:53.901364-0400 0x71       Default     0x0                  0      0    kernel: (AppleACPIPlatform)  Namespace lookup failure, AE_NOT_FOUND
2020-09-06 10:06:53.901602-0400 0x71       Default     0x0                  0      0    kernel: (AppleACPIPlatform)  (20160930/dswload-292)
2020-09-06 10:06:53.901603-0400 0x71       Default     0x0                  0      0    kernel: (AppleACPIPlatform)  (20160930/dswload-292)
2020-09-06 10:06:53.901752-0400 0x71       Default     0x0                  0      0    kernel: (AppleACPIPlatform) ACPI Exception: AE_NOT_FOUND,
2020-09-06 10:06:53.901753-0400 0x71       Default     0x0                  0      0    kernel: (AppleACPIPlatform) ACPI Exception: AE_NOT_FOUND,
2020-09-06 10:06:53.901937-0400 0x71       Default     0x0                  0      0    kernel: (AppleACPIPlatform) During name lookup/catalog
2020-09-06 10:06:53.901937-0400 0x71       Default     0x0                  0      0    kernel: (AppleACPIPlatform) During name lookup/catalog
2020-09-06 10:06:53.902096-0400 0x71       Default     0x0                  0      0    kernel: (AppleACPIPlatform)  (20160930/psobject-310)
2020-09-06 10:06:53.902097-0400 0x71       Default     0x0                  0      0    kernel: (AppleACPIPlatform)  (20160930/psobject-310)
2020-09-06 10:06:53.902280-0400 0x71       Default     0x0                  0      0    kernel: (AppleACPIPlatform) ACPI Exception: AE_NOT_FOUND,
2020-09-06 10:06:53.902281-0400 0x71       Default     0x0                  0      0    kernel: (AppleACPIPlatform) ACPI Exception: AE_NOT_FOUND,
2020-09-06 10:06:53.902466-0400 0x71       Default     0x0                  0      0    kernel: (AppleACPIPlatform) (SSDT:TBTTITAN) while loading table
2020-09-06 10:06:53.902467-0400 0x71       Default     0x0                  0      0    kernel: (AppleACPIPlatform) (SSDT:TBTTITAN) while loading table
2020-09-06 10:06:53.902683-0400 0x71       Default     0x0                  0      0    kernel: (AppleACPIPlatform)  (20160930/tbxfload-319)
2020-09-06 10:06:53.902684-0400 0x71       Default     0x0                  0      0    kernel: (AppleACPIPlatform)  (20160930/tbxfload-319)
2020-09-06 10:06:53.903604-0400 0x71       Default     0x0                  0      0    kernel: (AppleACPIPlatform) ACPI Error:
2020-09-06 10:06:53.903605-0400 0x71       Default     0x0                  0      0    kernel: (AppleACPIPlatform) ACPI Error:
2020-09-06 10:06:53.903664-0400 0x71       Default     0x0                  0      0    kernel: (AppleACPIPlatform) 2 table load failures, 16 successful
2020-09-06 10:06:53.903665-0400 0x71       Default     0x0                  0      0    kernel: (AppleACPIPlatform) 2 table load failures, 16 successful
2020-09-06 10:06:53.903823-0400 0x71       Default     0x0                  0      0    kernel: (AppleACPIPlatform)  (20160930/tbxfload-342)
2020-09-06 10:06:53.903823-0400 0x71       Default     0x0                  0      0    kernel: (AppleACPIPlatform)  (20160930/tbxfload-342)

 

 

 

Attached is System DSDT (before SSDT apply)

SystemDSDT.zip 14.78 kB · 0 downloads

I'll look this over.

FYI.

I have worked for hours trying to sort out why I could not get Shutdown to properly work. I won't even list all of the things I investigated (but they involved BIOS, ACPI, kexts, DevProp, MMIO and other OC settings). Shutdown would work perhaps 1/10 times; just enough to tease and lead me in one direction and then another.

I finally found the source of the problem. It was my keyboard (here). It was triggering the panic reboots. Once the keyboard was removed, Shutdown began working well (Sleep is also working).

Bottom line: remember to check hardware issues when things aren't working as expected.

16 hours ago, meina222 said:

I think I need @iGPU's help as I have no idea how this SSDT is supposed to work.

 

I tried compiling one based on the link above, matching my ROM and my PCI path, but it doesn't seem to have any effect.

 

Attaching IOReg and SSDT I tried to use. @iGPU - any input on SSDT is much appreciated. For me this is right now pattern matching without really understanding the details. 

 

SSDT-TBOLT3-2.aml.zip 1.71 kB · 1 download MyMacPro.zip 7.28 MB · 1 download

Try this one and let me know what happens.

As I've said, USB does not presently work on this build. I'm in contact with people (such as CaseySJ) and it will take time. In the meantime, the TB functionality is excellent and this is the main point of the TB card. (After all, we do have many USB ports on the main mobo, so we're not exactly suffering from USB shortages.)

SSDT-TBOLT3-v3.aml.zip

Just now, fabiosun said:

Sorry igpu I mean a comparative benchmark I Big Sur bare metal and proxmox

i see you did in Mojave’s for proxmox but I am on my mobile and I could be wrong 

if so sorry tomorrow I will check again

You are correct on this point: C15 VM test was in Mojave, not BS. But with tests other than C15 (which I often do not run), I've seen no difference amongst Mojave, Catalina or Big Sur.

The small variations I've seen on-line, I believe, are simply statistical variations due to uncontrolled testing situations. Example: on my computers, 've seen variations in test results with how long the computer has been turned on, what background apps were running, and if the computer was left un-touched during tests. This says nothing of BIOS settings, DDR4 speeds, mobo variations, etc. So unless a standardized approach is taken (which is not practical) most results are probably not significantly different even in a range of ±5%.

36 minutes ago, fabiosun said:

@iGPUhave you cb15 in latest Big Sur?

Yes, what I presented above is BS ß6 (public release 2), released this past week. I've seen no difference from BS ß2 thru ß6.

Here are C15 results for both bare metal and VM on AMD. Both are lower than Intel side.

Based on what I'm seeing, I don't think C15 uses both Radeon VIIs. Meanwhile, MarkLux does, as the scores below are consistent with Intel side where I have one Radeon VII on that system and it gets 54,000 on LuxMark. Also, LuxMark gives same scores for dual Radeon VII in VM and bare metal.

Big Sur ß6 bare metal, dual Radeon VII (XMP was on, 4G enabled and only 13 kernel patches--sourced from Pavo) :

C15 Test using Proxmox VM, dual Radeon VII (Mojave):

SMBIOS Comparison (LuxMark): dual Radeon VII, BS ß5 (iMacPro1,1 vs MacPro7,1):

1 hour ago, Driftwood said:

BS Beta 6 Firewire Audio Tip:

So firewire/fireface seemed broke (crackly). But you just have to reinstall drivers. Anyone using Firewire cards plus something like a Decklink capture card. Install Decklink first followed by a reinstall of fireface drivers from RME will get firewire audio working again. The Apple firewire driver works as good as old times!

I've re-installed a Firewire card and ordered an RME Fireface 800 off eBay. In reading about the RME 800, some touted how no extra RME drivers were needed for macOS, which means using the "class compliant mode". With the RME 800, when using Firewire, you either have to use this mode, or the "stand-alone" mode (and this mode is required for Total Mix).

My question is how does the "stand-alone" mode (requiring RME drivers) compare with the "class compliant mode"?

7 hours ago, Jaidy said:

@valmeida and @Pavo thanks.

I've been using an Audient EVO 4 from the start on VM and now, bare metal. Periodically, there is audio dropout which seems to be helped by disabling Wifi (BT stays enabled).

8 hours ago, meina222 said:

I could be the exception, but when I tried to update to beta 6, the macOS installer pick would progress through OC and rooting and then reboot before actually getting into the installation (right at handoff). The debug log of OC doesn't show anything off compared to previous successful boots. This is only when I select "macOS installer" - boot to beta 5 works normally. Next, I'll maybe try to create an install disk and try this way.

 

Update: Tried creating a fresh installation USB with Beta 6. On the same EFI where Beta 5 installer ran without a glitch, Beta 6 installer refuses to start and auto reboots. I use a recent OC (3 days maybe) daily build. So something changed. Will try a clean OC builder release from official OC repo.

I had same issue. Turn off csr-active-config blocking (use 00000000) and this should work with previous EFI.

57 minutes ago, Pavo said:

Some AMD systems has HPET issues, and this KP is exactly that.  The DummyPowerManagement quirk does nothing for AMD, I have proven this time and time again with previous AMD systems like X570 and now TRX40 but some of the AMD discord people don't listen and have given vit9696 suggestions that aren't needed. You can create an SSDT to change the _STA method to turn HPET on, let me look through previous SSDTs I have made and I can post it.

Pavo, agreed.

At least with the MSI mobo, there is no difference in HPET with or without DummyPowerManagement. Either setting gives this result:

On a peripheral note, if the highlighted contents of the Spoiler is added to NVRAM, SBRG is populated as shown below, otherwise nothing is attached to SBRG. This was used on the X570 build (modified NVRAM SSDT is attached).

SSDT-TRX40-NVRAM.aml.zip

19 minutes ago, fabiosun said:

@meina222i like your programmer way to explain and to try to solve problem

also @iGPU way is similar and i think you have given a bit to improve this thread

thank you

 

now a simple way to explain and sorry to all if sometimes i seems to be rude..it is only my english...

more 1 we have in our debug better is because all that area are in OSX avaibility

when an ‘area’ is on 0 in debug and OSX try to write there or use it for its tasks..system hangs

 

about @Driftwood problem

i have always said i am testing high sierra, mojave, catalina

and for this when you reach your gold situation no problem at all

gold situation means

nvram ok

sip ok

bios ok

config ok 

 

if one of this fails problem happens and to solve you have to be more drastic

 

And you have to reset sip, in recovery and in config..to achieve and optimal condition

 

this is our big and common problem.

fabiosun,

I was reading on some thread (forget which one, prob InsanelyMac) that to get proper SIP, one needs to first have native NVRAM working (which we do), then delete the csr-active-config entry in OC. Only then will the SIP set in Recovery maintain over a boot. Otherwise, the values set in csr-active-config will over-write Recovery SIP. I've not tried this.

21 minutes ago, Driftwood said:

Maybe we're getting down to what devices are being shifted into Above 4G or not 🙂 ?

Be interesting to see (as I have lots of pcie devices going on) if iGPU with his dual radeon like mine get shifted.

Mine were shifted and looks like your set up (here).

This suggests that the PCIe make up of our builds does not influence the MMio list (aside from multiple GPUs when 4G is enabled).

(Pavo and I have identical builds with same GPU, but he is using one and I two.)

6 minutes ago, Pavo said:

So.... I have tested enabled every single MMIO address and can boot and have everything functioning properly except for 3 addresses.

18:821 00:019 OCABC: MMIO devirt start
18:836 00:015 OCABC: MMIO devirt 0xE2100000 (0x81 pages, 0x8000000000000001) skip 1
18:857 00:020 OCABC: MMIO devirt 0xE3180000 (0x81 pages, 0x8000000000000001) skip 1
18:876 00:019 OCABC: MMIO devirt 0xEF100000 (0x181 pages, 0x8000000000000001) skip 1
18:896 00:019 OCABC: MMIO devirt 0xFA180000 (0x81 pages, 0x8000000000000001) skip 1
18:915 00:019 OCABC: MMIO devirt 0xFA300000 (0x100 pages, 0x8000000000000001) skip 1
18:935 00:019 OCABC: MMIO devirt 0xFEA00000 (0x100 pages, 0x8000000000000001) skip 1
18:955 00:019 OCABC: MMIO devirt 0xFEC00000 (0x1 pages, 0x8000000000000001) skip 1
18:974 00:019 OCABC: MMIO devirt 0xFEC10000 (0x1 pages, 0x8000000000000001) skip 1
18:994 00:019 OCABC: MMIO devirt 0xFED00000 (0x1 pages, 0x8000000000000001) skip 1
19:013 00:019 OCABC: MMIO devirt 0xFED40000 (0x5 pages, 0x8000000000000001) skip 1
19:033 00:019 OCABC: MMIO devirt 0xFED80000 (0x10 pages, 0x8000000000000001) skip 1
19:052 00:019 OCABC: MMIO devirt 0xFEDC2000 (0xE pages, 0x8000000000000001) skip 1
19:072 00:020 OCABC: MMIO devirt 0xFEDD4000 (0x2 pages, 0x8000000000000001) skip 1
19:092 00:019 OCABC: MMIO devirt 0xFEE00000 (0x100 pages, 0x8000000000000001) skip 1
19:111 00:019 OCABC: MMIO devirt 0xFF000000 (0x1000 pages, 0x8000000000000001) skip 1
19:131 00:019 OCABC: MMIO devirt 0x2040000000 (0x10400 pages, 0x8000000000000001) skip 1
19:151 00:019 OCABC: MMIO devirt 0x7EE0000000 (0x10400 pages, 0x8000000000000001) skip 0
19:171 00:020 OCABC: MMIO devirt 0x7F10000000 (0x10400 pages, 0x8000000000000001) skip 0
19:190 00:019 OCABC: MMIO devirt 0xDDB0000000 (0x10400 pages, 0x8000000000000001) skip 0
19:210 00:019 OCABC: MMIO devirt end, saved 798720 KB

I have tested the last 3 as individuals and the system will not boot, I have 3 more combinations to test, as first and second enabled, as first and last enabled, as second and last enabled. But it would appear that the last 3 addresses are the ones that are giving us issues.

In my original work, in the 0x10400 range, I had to enable the last one, and disable those above it,  in order to boot. When I did that, I mostly was getting shutdown in Big Sur (but not Catalina).

11 minutes ago, Pavo said:

My MMIO addresses do not change with either Above4G enabled or disabled, but I also only have 1 GPU installed.

Pavo,

Just to be clear, from my post that you reference, you are only enabling in MmioWhitelist, the values in red?

That is, you are not including the top 4 that are green (or the top 2 in your list)?

And if true, then all of the TRX40 mobos will use the same list regardless of Above 4G settings, and have proper functioning shutdown, etc.

When I enable 4G, all match Driftwood's who also has 4G enabled. They only differ in the bottom 4, which according to vit9696 are un-important. 

And we both have dual Radeon VIIs in slots 1 & 3.

0xCB100000 
0xD7180000
0xE3180000
0xE3300000
0xEF100000 
0xFEA00000
0xFEC00000 
0xFEC10000 
0xFED00000
0xFED40000 
0xFED80000
0xFEDC2000 
0xFEDD4000
0xFEE00000         
0xFF000000
0x4040000000
0x6F70000000
0x9EA0000000
0xCDD0000000

15 minutes ago, Driftwood said:

 

Yeah I get you - it certainly seems to help in my Big Sur tests. Thanks for the terrific work you've been doing @iGPU. Appreciate it man.

 

BTW @iGPU you using iMacPro1,1 profile or MacPro7,1 after the last round of tests? Be interesting to hear your thoughts?

I've stuck with iMacPro1,1. When I did a battery of tests in each system, there was no difference with the two Radeon VIIs or the CPU in either. So I kept on iMacPro1,1.  Apple may target some of their software to perform differently on newer machines, but I think for the vast majority of things, it won't matter.

It probably means nothing, and I don't know what Apple tracks, but I figure the older SMBIOS will more likely fly under the Apple radar than newer machines that may not be selling in the same volume as the older ones.

1 hour ago, fabiosun said:

 

3) for Big Sur you need old kext for that app

find an aluveie message on shanee’s forum for correct version working in BS

 

 

Thanks!

v034 is the latest one that works with Big Sur: here 

Use this kext and this app (the latest app v064 won't work with the older kext).

There were a few posts above discussing built in audio and the AppleALC kext. I took a different approach to examine the issue, not by listening, but from looking at loaded drivers (in Big Sur).

What happens to the audio drivers when AppleALC is disabled: the Audio Control drivers are not loaded. This is shown in the first image below.

Also shown is a parallel example of a driver not loading for BT/Wifi. I disabled the BT/Wifi kexts (which were included in the EFI's that I uploaded). (I'm using a swapped macOS compatible card.) If these BT/Wifi kexts are disabled, the BCM4352 drivers are not loaded and there is no BT (top image). If they're enabled, the driver is loaded and BT is working (bottom image).

Now the only reason you can even see what's happening in this PCI section is because I've entered many devices into OC/DeviceProperties section (which I did not upload in previous EFIs).  See the Spoiler below for the Audio example. A few of the PCI entries are also supplied by SSDT files.

DeviceProperties Example:

I realize that many don't like using SSDT and DeviceProperties, but if these are not used, you'll miss out on some interesting information. This information is normally seen in Macs and if not entered into OpenCore, it won't be seen in our Hackintoshes. So what really is more Vanilla?

A more significant example applies to Thunderbolt. If there is not a proper SSDT, no drivers are loaded and you'll get no Thunderbolt functionality.

The first image is SystemInfo/PCI when the AppleALC and BT kexts are disabled:

Now, AppleALC and BT kexts are enabled:

3 minutes ago, Pavo said:

I don't need Above 4G not npci=0x2000 as boot-arg and boots fine, also CSM disabled. You might need Above4G because of duel GPUs though. My MMIOWhite list is the from the ones I got from using OpenCore debug version and only disabled the last 2 entries.

Thanks for feedback. Originally, I had 4G and CSM disabled, but only tried as fabiosun was discussing. I'm don't know if I see advantage one way or the other.

And for disabling LAN wake-up, we don't seem to have this option on the MSI Creator. (I usually keep disabled on Intel Hackintoshes.)

1 hour ago, fabiosun said:

About kext order for amd cpu power gadget

you have to declare two needed kext in correct order

see in App’s github for it

in my bios 4g can be enabled or disabled

so you have to read  your manual and test by yourself 

@Jaidy

fabiosun,

1) I could not boot with Above 4G enabled unless I also enabled CSM. Even with 4G enabled, if npc=0x2000 is present as boot-arg, it still boots. I'm not certain I see the downside of leaving npc=0x2000 present; are there problems in the log that I'm missing?

2) From reading recent posts, I don't quite understand what you're recommending for MmioWhitelist.

    a) Are you saying it should be the same for all TRX40 mobos?

    b) And that you found something different with Pavo from the list I'd originally posted for the MSI Creator?

3) Were you able to get AMDRyzenCPUPowerManagement.kext to work in Big Sur?

TB Update.

I've spent hours working on the TB USB-C issue: so far no luck. So I contacted some people way smarter than me and they've kindly included me in their PM loop as they've been working on the same issue. It seems that TB USB-C is flaky on other systems too. The main difference is that they get USB-C functionality if the device is connected before boot, but not if hot-plugged after boot. While I get no USB-C either way.

Bottom line, people are working on it, but it will take some time.