trx40 [Discussion] - TRX40 Bare Metal - Vanilla Patches

Pavo · August 31, 2020

26 minutes ago, Driftwood said:

Keyboard and mouse go off (USB) when using Pavo's last three only in Catalina. Last four =NO for me, and keyboard and mouse stay on 🙂

Last 4 NO seems to agree with insanelyMac vit9696 guy then?!

I didn't mean for you to use my addresses, I meant for you to disable only the last 3 addresses of your MMIO list.

Driftwood · August 31, 2020

1 hour ago, Pavo said:

I didn't mean for you to use my addresses, I meant for you to disable only the last 3 addresses of your MMIO list.

Not using your addresses. I am using my MMIO, just switching off last 3

So after testing out Big Sur (with Pavo's EFI + MY Addresses, last 4 is better than last 3.

Last three set to NO turns off keyboard and mouse and can't bring it back to life. Shutdown clicks and reboots.

So this is my HAPPY MMIO w'list so far:

Edited September 1, 2020 by Driftwood

Pavo · August 31, 2020

Just now, Driftwood said:

Not using your addresses. I am using my MMIO, just switching off last 3

Ok.... just wanted to make sure you understood what I wanted to be tested.

Pavo · September 1, 2020

Ok... so after doing a little more testing it would seem the first 0x10400 address enabled cause some side effect issues with USB controllers. Started having random disconnects from varies devices.

19:131 00:019 OCABC: MMIO devirt 0x2040000000 (0x10400 pages, 0x8000000000000001) skip 0

So.. I changed mine to disable that first address from the 0x10400 section. Will report anymore findings.

fabiosun · September 1, 2020

I think now you have understood what I am saying from a bit

also for the sake of testing

all of this should be apply also on different OSX to be proved solid rock combinations 😊

Driftwood · September 1, 2020

25 minutes ago, fabiosun said:

I think now you have understood what I am saying from a bit

also for the sake of testing

I'm just trying out Big Sur with our Catalina MMIO. Things don't work so good and I even tried without SSDTs (ie DISABLED) on this BS test drive.

There seems to be a lot more to do to find the ideal combination.

Just gonna try out the complete Catalina EFI on BS to just put something to bed...RESULT: Ok, my working well Catalina EFI wont boot Big SurBM. Testing goes on...

Edited September 1, 2020 by Driftwood

meina222 · September 1, 2020

The last 4 turned off, everything else checked works for my MMIO (shutdown + NVRAM). So I think I will stick to that scheme given everybody's findings.

Something I noticed in @Pavo's config.plist (and I believe @fabiosun mentioned that he has it too) is that DummyPowerManagement is OFF. If I leave it OFF my system starts to exhibit instability and reboots 1-2 min into a session with the following dump. Since @Driftwood has it ON, it doesn't seem it affects sleep (my last problematic area, monitor sleeps but not PC and fans), I wonder what is the guidance on that, and how do those who have it OFF not experience issues similar to the dump below.

panic(cpu 0 caller 0xffffff800b6cea11): CPU 63 has no HPET assigned to it

Backtrace (CPU 0), Frame : Return Address

0xffffffa3c7d6bc60 : 0xffffff800a2be6ad mach_kernel : _handle_debugger_trap + 0x3dd

0xffffffa3c7d6bcb0 : 0xffffff800a3fef13 mach_kernel : _kdp_i386_trap + 0x143

0xffffffa3c7d6bcf0 : 0xffffff800a3ef96a mach_kernel : _kernel_trap + 0x55a

0xffffffa3c7d6bd40 : 0xffffff800a263a2f mach_kernel : _return_from_trap + 0xff

0xffffffa3c7d6bd60 : 0xffffff800a2bdf4d mach_kernel : _DebuggerTrapWithState + 0xad

0xffffffa3c7d6be80 : 0xffffff800a2be238 mach_kernel : _panic_trap_to_debugger + 0x268

0xffffffa3c7d6bef0 : 0xffffff800aab9f1a mach_kernel : _panic + 0x54

0xffffffa3c7d6bf60 : 0xffffff800b6cea11 com.apple.driver.AppleIntelCPUPowerManagement : _pmInitThread + 0x2c0

0xffffffa3c7d6bfa0 : 0xffffff800a26313e mach_kernel : _call_continuation + 0x2e

Kernel Extensions in backtrace:

com.apple.driver.AppleIntelCPUPowerManagement(222.0)[A5C47275-91D0-3F66-8C16-DE6FE6DA5701]@0xffffff800b6c8000->0xffffff800b6e5fff

Process name corresponding to current thread: kernel_task

Boot args: -v -wegbeta agdpmod=pikera npci=0x2000 alcid=1 keepsyms=1

Mac OS version:

20A5354i

Kernel version:

Darwin Kernel Version 20.0.0: Fri Aug 14 00:25:13 PDT 2020; root:xnu-7195.40.44.151.1~4/RELEASE_X86_64

Kernel UUID: F29B97A1-72E4-3D36-863F-8ADCCB731F78

KernelCache slide: 0x000000000a000000

KernelCache base: 0xffffff800a200000

Kernel slide: 0x000000000a010000

Kernel text base: 0xffffff800a210000

__HIB text base: 0xffffff800a100000

System model name: MacPro7,1 (Mac-27AD2F918AE68F61)

System shutdown begun: NO

Panic diags file available: YES (0x0)

Hibernation exit count: 0

System uptime in nanoseconds: 91199401734

Last Sleep: absolute base_tsc base_nano

Uptime : 0x000000153be871eb

Sleep : 0x0000000000000000 0x0000000000000000 0x0000000000000000

Wake : 0x0000000000000000 0x000000279ec5219c 0x0000000000000000

meina222 · September 1, 2020

7 hours ago, fabiosun said:

Test:

1)

what does devirtualizemmio quirk does?

2) which means to on or to off it?

3) skip 0 what does it mean in the debug?

4) skip1 what does it mean in the debug?

5) a system that does not need of that quirks use or not those mmio area/pages?

starting from here imho should be a common task😊

@fabiosun, these are excellent questions. I feel that we need to post more of those with hopefully insightful answers that deepen our understanding and reduce trial and error.

I will take a very crude stab at what "I think" this MMIO devirtualise (definitely not spelled by an American) refers to, but this is a very superficial attempt as I don't know well the memory mapping of hardware.

1st one needs to understand MMIO (I actually never read that article myself until now but pasting it anyways)

https://en.wikipedia.org/wiki/Memory-mapped_I/O

Notice how there's a table in there that has memory address ranges. Computer memory can be pictures as a tape with a list of contiguous addresses that are just hexadecimal numbers separated by a fixed distance dependent on the architecture (e.g. 8 bytes). Some of this memory is allocated to hardware devices and this is where MMIO (memory mapped IO) comes in.

Now, it gets a bit more complicated. "Virtual memory" refers to the fact that a system can see "fake" logical addresses that have some sort of translation to real physical addresses that can be read from or written to. Why do that - because it's convenient for software to think of memory as 1 tape, but in reality memory has many levels such as CPU registers, caches, main memory, disks etc (you can even insert magnetic tapes here). The "fake" logical addresses are called "virtual" and the real one "physical". Physical addresses are complicated to deal with as they can be spread among different types of hardware, so logic exists to translate between the 2. This concept is "central" to OS-es (every modern OS really) - this allows your software to fancy it has this large tape of memory where in reality there's a complex bookkeeping system to manage many devices behind that fake tape. You can read about this here:

https://en.wikipedia.org/wiki/Page_table

So far we haven't really said how the concept of "virtual memory" applies to MMIO and what does this have to do with the MacOS kernel. It seems that the memory ranges given as examples in https://en.wikipedia.org/wiki/Memory-mapped_I/O are also virtual. This is an educated guess on my part - I can only makes sense of it this way. What this means is that besides the address ranges in these tables, you have to store bookkeeping information on how to translate these "virtual" addresses to "physical" ones. Such info in the form of lookup tables itself takes memory. Seems that as the MacOS kernel grew, and also KASLR (randomized loading) was introduced (itself a complicated topic I know little of), it became harder for it to fit into certain restricted memory areas where a kernel is supposed to load as it couldn't find space among these MMIO bookkeeping ranges. By "de-virtualizing" OC is able to prevent / bypass such bookkeeping info for certain address ranges, thus saving memory and allowing the kernel to fit. I'd love for someone to give more detail on that or let me know if I'm being inaccurate. What I don't know is how this "bypassing" translates to corruption such as Shutdown not working or other issues not observed. If you "devirtualize" too much, you free more memory but you mess the OS interacting with these ranges when it loads. If you don't devirtualize you can't fit the kernel.

So to answer your questions (as an educated guess, I must admit):

1) Means that virtual addresses are not used for certain MMIO ranges saving memory on lookup/bookkeeping to translate virtual addresses to physical ones

2) When I use the term "on" I refer to the config.plist MMIO whitelist ENABLED boolean checkbox - "on" is same as ENABLED=YES.

I would think that if you select "DevirtualiseMmio" and don't provide any addresses, then the entire range is implicitly "skip=0" (ENABLED=NO). This means we do not skip devirtualizing, which is a very twisted way of saying that we devirtualize and free up the max amount of memory. But then we mess with hardware / OS interaction later on.

3) skip 0 is just OC logging that you instructed ENABLED=NO. skip 1 is opposite. If you skip=1 everywhere you skip devirtualization, leaving everything virtual. If you set ENABLED=NO everywhere you devirtualize everywhere.

5) As this is my 1st Hackintosh project, the answer is "I don't know" - seems to depends on the firmware and memory map. Clearly the VM didn't need it. TRX40 seems to need it. My guess that all boards followed a reference AMD template, which would need it.

meina222 · September 1, 2020

Off-topic. Now that this is out, I need to buy it 🙂

https://www.sabrent.com/rocket-4-plus/

fabiosun · September 1, 2020

@meina222 idk if they are excellent questions or not but it should be the questions all users should do to theirself before starting to play with those areas

about your point 5)

no all AMD platform need of devirtualizemmio stuff

and often if you use in a system that does not neet it, system hangs

meina222 · September 1, 2020

5) no all AMD platform need of devirtualizemmio stuff

I think I meant AMD TRX40. I wouldn't know about others as I never did Hackintosh on other AMD.

fabiosun · September 1, 2020

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

meina222 · September 1, 2020

Can someone explain to me "DummyPowerManagement" and how do you guys leave it OFF. My system becomes very unstable. Can this "CPU xx has not HPET assigned to it" error be fixed with SSDT? I thought HPET is on by default in BIOS (I couldn't find any option to set it or turn it on/off).

fabiosun · September 1, 2020

That quirk is a sort of nullcpupowermanagement.kext used in the past for cpu not supported by osx

today i will verify our kernel patches because i think some differences is there

iGPU · September 1, 2020

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.

fabiosun · September 1, 2020

@iGPU yes it works

i use 00000000 then enter in recovery and clear sip and nvram from there

this could be need of additional quirk like avoidruntime defrag if you do not use it

but all this is the weaker part in our effort to have a perfect or almost perfect system

and all of you are more lucky than me because you do not use a Nvidia gpu

Pavo · September 1, 2020

9 hours ago, meina222 said:

The last 4 turned off, everything else checked works for my MMIO (shutdown + NVRAM). So I think I will stick to that scheme given everybody's findings.

Something I noticed in @Pavo's config.plist (and I believe @fabiosun mentioned that he has it too) is that DummyPowerManagement is OFF. If I leave it OFF my system starts to exhibit instability and reboots 1-2 min into a session with the following dump. Since @Driftwood has it ON, it doesn't seem it affects sleep (my last problematic area, monitor sleeps but not PC and fans), I wonder what is the guidance on that, and how do those who have it OFF not experience issues similar to the dump below.

panic(cpu 0 caller 0xffffff800b6cea11): CPU 63 has no HPET assigned to it

Backtrace (CPU 0), Frame : Return Address

0xffffffa3c7d6bc60 : 0xffffff800a2be6ad mach_kernel : _handle_debugger_trap + 0x3dd

0xffffffa3c7d6bcb0 : 0xffffff800a3fef13 mach_kernel : _kdp_i386_trap + 0x143

0xffffffa3c7d6bcf0 : 0xffffff800a3ef96a mach_kernel : _kernel_trap + 0x55a

0xffffffa3c7d6bd40 : 0xffffff800a263a2f mach_kernel : _return_from_trap + 0xff

0xffffffa3c7d6bd60 : 0xffffff800a2bdf4d mach_kernel : _DebuggerTrapWithState + 0xad

0xffffffa3c7d6be80 : 0xffffff800a2be238 mach_kernel : _panic_trap_to_debugger + 0x268

0xffffffa3c7d6bef0 : 0xffffff800aab9f1a mach_kernel : _panic + 0x54

0xffffffa3c7d6bf60 : 0xffffff800b6cea11 com.apple.driver.AppleIntelCPUPowerManagement : _pmInitThread + 0x2c0

0xffffffa3c7d6bfa0 : 0xffffff800a26313e mach_kernel : _call_continuation + 0x2e

Kernel Extensions in backtrace:

com.apple.driver.AppleIntelCPUPowerManagement(222.0)[A5C47275-91D0-3F66-8C16-DE6FE6DA5701]@0xffffff800b6c8000->0xffffff800b6e5fff

Process name corresponding to current thread: kernel_task

Boot args: -v -wegbeta agdpmod=pikera npci=0x2000 alcid=1 keepsyms=1

Mac OS version:

20A5354i

Kernel version:

Darwin Kernel Version 20.0.0: Fri Aug 14 00:25:13 PDT 2020; root:xnu-7195.40.44.151.1~4/RELEASE_X86_64

Kernel UUID: F29B97A1-72E4-3D36-863F-8ADCCB731F78

KernelCache slide: 0x000000000a000000

KernelCache base: 0xffffff800a200000

Kernel slide: 0x000000000a010000

Kernel text base: 0xffffff800a210000

__HIB text base: 0xffffff800a100000

System model name: MacPro7,1 (Mac-27AD2F918AE68F61)

System shutdown begun: NO

Panic diags file available: YES (0x0)

Hibernation exit count: 0

System uptime in nanoseconds: 91199401734

Last Sleep: absolute base_tsc base_nano

Uptime : 0x000000153be871eb

Sleep : 0x0000000000000000 0x0000000000000000 0x0000000000000000

Wake : 0x0000000000000000 0x000000279ec5219c 0x0000000000000000

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.

iGPU · September 1, 2020

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

Spoiler

SSDT-TRX40-NVRAM.aml.zip

Pavo · September 1, 2020

Below is an example of changing a ACPI method of a device.

DefinitionBlock ("", "SSDT", 2, "APPLE ", "HPET", 0x00001000)
{
    External (HPET._STA, UnknownObj)

    Scope (_SB)
    {
        Method (_INI, 0, NotSerialized)
        {
            \HPET._STA = 0x0F
        }
    }
}

now... the \HPET._STA depends on the location of HPET in your original DSDT. This is what I used on my MSI MPG X570 Gaming Edge WiFi when I was using a 3950X. It is not needed on my MSI Creator TRX40 system. @meina222 If you upload your DSDT I can modify this to meet your system needs.

Edited September 1, 2020 by Pavo

Driftwood · September 1, 2020

Ill switch mine off to see if any difference.

meina222 · September 1, 2020

@Pavo - Here it is. Thank you!

System DSDT.zip

Pavo · September 1, 2020

1 hour ago, meina222 said:

@Pavo - Here it is. Thank you!

System DSDT.zip 14.71 kB · 0 downloads

So... your HPET is exactly like mine and @iGPU system. Here is yours....

Device (HPET)
    {
        Name (_HID, EisaId ("PNP0103"))  // _HID: Hardware ID
        Method (_STA, 0, NotSerialized)  // _STA: Status
        {
            If (LEqual (HPEN, One))
            {
                If (LGreaterEqual (OSVR, 0x0C))
                {
                    Return (0x0F)
                }

                Store (Zero, HPEN)
                Return (One)
            }

            Return (One)
        }

        Method (_CRS, 0, NotSerialized)  // _CRS: Current Resource Settings
        {
            Name (BUF0, ResourceTemplate ()
            {
                IRQNoFlags ()
                    {0}
                IRQNoFlags ()
                    {8}
                Memory32Fixed (ReadOnly,
                    0xFED00000,         // Address Base
                    0x00000400,         // Address Length
                    )
            })
            Return (BUF0)
        }
    }

Here is mine....

Device (HPET)
    {
        Name (_HID, EisaId ("PNP0103"))  // _HID: Hardware ID
        Method (_STA, 0, NotSerialized)  // _STA: Status
        {
            If (LEqual (HPEN, One))
            {
                If (LGreaterEqual (OSVR, 0x0C))
                {
                    Return (0x0F)
                }

                Store (Zero, HPEN)
                Return (One)
            }

            Return (One)
        }

        Method (_CRS, 0, NotSerialized)  // _CRS: Current Resource Settings
        {
            Name (BUF0, ResourceTemplate ()
            {
                IRQNoFlags ()
                    {0}
                IRQNoFlags ()
                    {8}
                Memory32Fixed (ReadOnly,
                    0xFED00000,         // Address Base
                    0x00000400,         // Address Length
                    )
            })
            Return (BUF0)
        }
    }

So... I am not sure why you are having HPET issues, please upload your entire EFI Folder.

meina222 · September 1, 2020

MyMacPro.zip EFI.zipAttaching both EFI and IOReg file.

I made some attempts to streamline my SSDT's using your config.plist as reference as you have a stable setup. But some of them are different (AIC disables my zfs raid NVMEs, ETH is iGPU's ETH rename, I also added SBUS - not sure if it's helping).

Definitely my system requires DummyPowerManagement in its current form. Any attempt to disable causes a panic 1 min into a session (after a successful login). It's almost deterministic in the way it fails and always with 1 min or so delay causing reboot: