MacPro7,1 = ASRock X570 ITX/TB3, 5900X, RX-570: chasing sleep/wake stability

atanvarno

Donator
Donator
AMD OS X Member
Joined
May 2, 2020
Messages
228
UPDATE, Oct 23: finalized build, sleep / wake works with custom SSDT.


I spent today moving away from iMacPro1,1 to MacPro7,1.

Screenshot 2021-10-09 at 23.35.28.png

I wanted two things:
  1. Simplify EFI
  2. Try to fix sleep
I did hit the first goal but sleep/wake is still a damn issue.

I re-did my USB map, using USBToolbox at first but then custom-updated to use just one kext and also to do matching based on IOPath instead of IONameMatch or whatever. This means I did not have to use any SSDT to rename whatever XHC controllers. Pretty happy about that.

Here's the ready to go EFI + all the hardware.

I love how IOReg XHC looks now :)

Screenshot 2021-10-09 at 23.48.22.png


Per XLNC's tip from the Discord, I removed SSDT-USBX and added power info to the USB map:

Screenshot 2021-10-09 at 23.34.38.png
 
Last edited:

atanvarno

Donator
Donator
AMD OS X Member
Joined
May 2, 2020
Messages
228
Now, I wish I could figure out the sleep / wake issues, one of these days.
 

atanvarno

Donator
Donator
AMD OS X Member
Joined
May 2, 2020
Messages
228
Apparently, having EC device added through SSDT is not needed anymore. I removed it and everything works just fine (with MacPro7,1 on Big Sur).

I kept SSDT for HPET i PMC that were created by SSDTTime but will see is that really needed too. At least HPET patch may be needed, I think.

SSDT-USBX is not needed, at all. Just add properties to USB map.
Something to consider is what exact values should really be used for USB port power; currently using 2100 and 5100.

So with current state of things, I have the same state as I had with older build targeting iMacPro1,1: the entire machine goes to sleep when I choose Apple menu / Sleep. But waking up from sleep fails to activate GPU, since monitor shows no input. More importantly, entire machine becomes locked-up and holding power button to turn it off does nothing. Only cable out and then in works, which unfortunately hard resets ASRock's BIOS to defaults - yuck. Still, fairly easy to get needed settings back.
 

atanvarno

Donator
Donator
AMD OS X Member
Joined
May 2, 2020
Messages
228
Did try the CFG,CFG_USE_AGDC=00 from Dortania's Sleep troubleshooting – that caused black screen on entering macOS graphical mode. So, nope; who knows what that thing does.

It's really annoying to try such random hacks, since there's usually no explanation what it actually attempts. "Some displays may fail to wake randomly, mainly caused by AGDC preferences" is not very useful. :s
 

atanvarno

Donator
Donator
AMD OS X Member
Joined
May 2, 2020
Messages
228
OK, can now confirm that SSDT-PMC is not needed even though SSDTTime generates it.

Also removed VoodooTSCSyncAMD, did not notice any issues after that, so probably outdated now.

Love that EFI becomes so much simpler.
 

atanvarno

Donator
Donator
AMD OS X Member
Joined
May 2, 2020
Messages
228
I went through @AudioGod's entire config.plist, comparing with stuff in mine and can't see anything to make a difference where wake from sleep works for his build and not for me.

So it must be hw related. :unsure:
Either something in ASRock's X570 BIOS or the fact I am using RX-570 card (since 6800 is damn elusive, for normal money).
I'm leaning towards the GPU, since wake starts to happen (MB lights up, CPU fans start up) but monitor never gets the signal.

I did not specifically checked is it maybe AIO (as in: place my ear next to the pump) but I seriously doubt since it's DC controlled - no PWM or USB connection or anything. If it has power, it spins up.

Head scratcher this one is, for sure. :)
 

Aluveitie

Donator
Donator
AMD OS X Member
Joined
May 2, 2020
Messages
895
As far as I remember I needed the HibernationFixup kext to fix wake up issues on the ASRock.
 

atanvarno

Donator
Donator
AMD OS X Member
Joined
May 2, 2020
Messages
228
Thanks for the tip, I just tried it briefly and it worked. I was convinced that's only for laptops but – try and learn. :)

Subsequent issue: I was testing sleep with minimal influencing factors, thus all the USB externals were disconnected except the Glorious mouse receiver. And with that sleep worked, with HIbernationFixup wake does too.

However, when I plug either the USB microphone (Blue Yeti) or my monitor USB hub cable, going to sleep fails. Next challenge is here, it appears. Will need to search a bit around, any ideas always welcome.
 
Last edited:

atanvarno

Donator
Donator
AMD OS X Member
Joined
May 2, 2020
Messages
228
Ran this command:

log show --style syslog --start "2021-10-08" | fgrep "Wake reason"

and got 2 of these lines for each sleep attempt:

Code:
(AppleACPIPlatform) AppleACPIPlatformPower Wake reason: 
GPP0 GPP2 GPP3 GPP4 GPP5 GPP6 GPP7 GPP9 GPPA GPPB GPPC GPPD GPPE GPPF GP10 GP11
 

atanvarno

Donator
Donator
AMD OS X Member
Joined
May 2, 2020
Messages
228
As promised, I did some digging and reading.
I found this confidently sounding page which recommends to edit your DSDT and whenever you find this:

Code:
Method (_PRW, 0, NotSerialized)  // _PRW: Power Resources for Wake
{
    Return (GPRW (...whatever...))
}
to turn it into this:
Code:
Method (_PRW, 0, NotSerialized)  // _PRW: Power Resources for Wake
{
    Return (GPRW (0x09, 0x04))
}

Basically, values inside must be 0x09 and 0x04. Sure, great, but why? No explanation, as usual. I am really not happy to just blindly do these edits without having at least vague idea what they aim to accomplish. So I will read-on and try to understand those values first.

But that aside, I did search in my build's DSDT and it was interesting what I found.
  • There are exactly 25 _PRW methods, one per Device.
  • The 17 devices use 0x08, 0x04 values.
  • 5 devices – GP12, GP13, GP13.XHC0, GP30, GP31 – have 0x19, 0x04 values
  • SBRG.PS2K, SBRG.PS2M, BXBR has 0x1D, 0x04
So none have the exact recommended values. :)

The kicker: from first 17 devices, 16 of them are all inside this exact list of devices that's in the "wake reason" log:
Code:
(AppleACPIPlatform) AppleACPIPlatformPower Wake reason: 
GPP0 GPP2 GPP3 GPP4 GPP5 GPP6 GPP7 GPP9 GPPA GPPB GPPC GPPD GPPE GPPF GP10 GP11
Only GPP8 is missing here. (I have a hunch all of theses somehow correspond to USB ports and maybe GPP8 is missing because my USBmap.kext removes all logical ports associated with it.)


Here's an example:

Code:
Device (GPP0)
            {
                Name (_ADR, 0x00010001)  // _ADR: Address
                Method (_PRW, 0, NotSerialized)  // _PRW: Power Resources for Wake
                {
                    Return (GPRW (0x08, 0x04))
                }

                Method (_PRT, 0, NotSerialized)  // _PRT: PCI Routing Table
                {
                    If (PICM)
                    {
                        Return (AR01) /* \_SB_.AR01 */
                    }

                    Return (PD01) /* \_SB_.PD01 */
                }

                Device (D004)
                {
                    Name (_ADR, 0xFF)  // _ADR: Address
                }
            }
 

atanvarno

Donator
Donator
AMD OS X Member
Joined
May 2, 2020
Messages
228
A look in ioReg, revealed that GPP8 is related to GPU :)
 

atanvarno

Donator
Donator
AMD OS X Member
Joined
May 2, 2020
Messages
228
UPDATE: see later post, this was not working to wake, all the time.




For the lack of further stuff to try, I attempted to replace GPRW(0x08, 0x04) with 0x09, 0x04 and daaaamn - it works.

Thanks to XLNC at the AMD OSX Discord who provided SSDT to replace just those GPRW calls where first argument is 0x08:

Code:
DefinitionBlock ("", "SSDT", 2, "XLNC", "GPRW", 0x00000000)
{
    External (XPRW, MethodObj)    // 2 Arguments

    Method (GPRW, 2, NotSerialized)
    {
        If (_OSI ("Darwin"))
        {
            If ((0x08 == Arg0))
            {
                Return (Package (0x02)
                {
                    0x09,
                    0x04
                })
            }

        }

        Return (XPRW (Arg0, Arg1))
    }
}

for this to work, also add ACPI patch for XPRW:

Code:
<dict>
    <key>Base</key>
    <string></string>
    <key>BaseSkip</key>
    <integer>0</integer>
    <key>Comment</key>
    <string>GPRW to XPRW Rename</string>
    <key>Count</key>
    <integer>0</integer>
    <key>Enabled</key>
    <true/>
    <key>Find</key>
    <data>
    R1BSVwI=
    </data>
    <key>Limit</key>
    <integer>0</integer>
    <key>Mask</key>
    <data>
    </data>
    <key>OemTableId</key>
    <data>
    AAAAAA==
    </data>
    <key>Replace</key>
    <data>
    WFBSVwI=
    </data>
    <key>ReplaceMask</key>
    <data>
    </data>
    <key>Skip</key>
    <integer>0</integer>
    <key>TableLength</key>
    <integer>0</integer>
    <key>TableSignature</key>
    <data>
    AAAAAA==
    </data>
</dict>

I let my build idle and it went to sleep properly and also woke at the mouse / keyboard nudge.
 
Last edited:

atanvarno

Donator
Donator
AMD OS X Member
Joined
May 2, 2020
Messages
228
Another great thread related to pmset and sleep / wake functionality in general
 

atanvarno

Donator
Donator
AMD OS X Member
Joined
May 2, 2020
Messages
228
Damn, now that everything reliably goes to sleep (tried at least 10x), the waking up problem appeared again. Probably the devices that were problematic to sleep, are now problematic to wake up.

The fun continues...
 

Aluveitie

Donator
Donator
AMD OS X Member
Joined
May 2, 2020
Messages
895
If I remember correctly, the Thunderbolt controller was causing me issues with sleep. Since I didn’t use it at that time I left it deactivated in the BIOS.

The Strix was much smoother to get to sleep and wake up properly.
 

Shaneee

The AMD Guy
Staff member
Administrator
Joined
Mar 13, 2020
Messages
2,142
For the lack of further stuff to try, I attempted to replace GPRW(0x08, 0x04) with 0x09, 0x04 and daaaamn - it works.

Thanks to XLNC at the AMD OSX Discord who provided SSDT to replace just those GPRW calls where first argument is 0x08:

Code:
DefinitionBlock ("", "SSDT", 2, "XLNC", "GPRW", 0x00000000)
{
    External (XPRW, MethodObj)    // 2 Arguments

    Method (GPRW, 2, NotSerialized)
    {
        If (_OSI ("Darwin"))
        {
            If ((0x08 == Arg0))
            {
                Return (Package (0x02)
                {
                    0x09,
                    0x04
                })
            }

        }

        Return (XPRW (Arg0, Arg1))
    }
}

for this to work, also add ACPI patch for XPRW:

Code:
<dict>
    <key>Base</key>
    <string></string>
    <key>BaseSkip</key>
    <integer>0</integer>
    <key>Comment</key>
    <string>GPRW to XPRW Rename</string>
    <key>Count</key>
    <integer>0</integer>
    <key>Enabled</key>
    <true/>
    <key>Find</key>
    <data>
    R1BSVwI=
    </data>
    <key>Limit</key>
    <integer>0</integer>
    <key>Mask</key>
    <data>
    </data>
    <key>OemTableId</key>
    <data>
    AAAAAA==
    </data>
    <key>Replace</key>
    <data>
    WFBSVwI=
    </data>
    <key>ReplaceMask</key>
    <data>
    </data>
    <key>Skip</key>
    <integer>0</integer>
    <key>TableLength</key>
    <integer>0</integer>
    <key>TableSignature</key>
    <data>
    AAAAAA==
    </data>
</dict>

I let my build idle and it went to sleep properly and also woke at the mouse / keyboard nudge.

Glad you managed to get it working. Unfortunately this doesn't work for me lol
 

atanvarno

Donator
Donator
AMD OS X Member
Joined
May 2, 2020
Messages
228
Glad you managed to get it working. Unfortunately this doesn't work for me lol
Huh...so this trick is not X570 specific, more like ASRock specific (you have Asus, right?)
 

atanvarno

Donator
Donator
AMD OS X Member
Joined
May 2, 2020
Messages
228
If I remember correctly, the Thunderbolt controller was causing me issues with sleep. Since I didn’t use it at that time I left it deactivated in the BIOS.

The Strix was much smoother to get to sleep and wake up properly.
We are thinking the same 😉 – because TB3 is not working, I changed the settings to disabled.

That turns off the USB-C port entirely, it was at least working as such. Will need to test over the weekend how it behaves (regarding sleep) when that controller is off (need to adjust my USB map too) and then decide what's more important to me. If there is a reliable difference.
 

baronerosso

Donator
Donator
AMD OS X Member
Joined
Sep 29, 2020
Messages
103
Top Bottom
  AdBlock Detected
Sure, ad-blocking software does a great job at blocking ads, but it also blocks some useful and important features of our website. For the best possible site experience please take a moment to disable your AdBlocker.