Gigabyte B550 Aorus Pro V2 - Ryzen 7 3700X - ASUS RX570

[rohling]

I switched Mainboards from An MSI X-570 A Pro because I wouldn't upgrade to Monterey. Pitty, because under Big Sur everything was running nicely more or less out of the box. Now this one gave me some more headaches, that's mostly why I am sharing the EFI folder.

Mainboard Gigabyte B550 Aorus Pro V2 Bios F11
CPU Ryzen 7 3700 X
GPU Asus RX570 8GB
RAM 32GB Skill Ripjaws DDR4-3200
SSD 500 GB SATA
BT/WIFI Fenvi FV-HB1200 PCIe card
SMBIOS MacPro 7.1

What works:

• Ethernet
• Wifi
• Bluetooth
• iCloud
• Airplay
• SSD and NVME drives showing as internal
• ALC 1220 audio, thanks to Shaneee's hint below

What doesn't work:

• Sleep, any help would be highly appreciated

 

[Edhawk]

For sleep issues the usual culprit is USB Port Configuration errors - sleep-crashing-on-amd.

Have you followed the OC AMD USB Port Configuration guide linked below?

Why should you USB map | OpenCore Post-Install

Follow the AMD path.

 

[Shaneee]

Assuming you've got AppleALC loaded in the config this should work for your audio,

Device Properties -> PciRoot(0x0)/Pci(0x8,0x1)/Pci(0x0,0x4)
layout-id = 15000000

 

[rohling]

Audio is up and running, thanks @Shaneee !

Now I'll try and tackle the USB Mapping. I tried USBToolbox https://github.com/USBToolBox/tool but that obviously didn't work. Probably my fault somewhere along the process.

 

[vostro1720]

Audio is up and running, thanks @Shaneee !

Now I'll try and tackle the USB Mapping. I tried USBToolbox https://github.com/USBToolBox/tool but that obviously didn't work. Probably my fault somewhere along the process.

May I have your EFI?

 

[rohling]

Sure thing. I attached the updated EFI to the first post. I mapped the USB ports with Hackintool, but still no sleep.

 

[Edhawk]

Looking at the USBPorts.kext you added to your /EFI/OC/Kexts folder above in post #1 I am not sure you have configured it correctly.

These are the USB ports on your motherboard:



Connector types are shown as either Internal (255), USB2 physical (0), USB3 physical (3), USB2 virtual (3), Type-C (9) or Type-c+sw (10)

To clarify if a Type-C port is (9) or (10) you need to install the USB Type-C pen drive twice.

• Turning the pen drive 180 degrees, i.e. from the top being at 12 o'clock to being at 6 o'clock.
• If the port discovery shows the same port, this is a Type-C+SW port (10)
• If it shows two different ports it is a Type-C port (9).

Your motherboard contains the following:
USB Controller 1 (CPU)

• 3 x USB3 physical ports (3)
• 3 x USB2 virtual ports (from the USB 3 ports) (3)

USB Controller 2 (AMD Chipset) (XHC0)

• 1 x Type-C header, serving case front (presumably)
• 1 x Type-c physical port on rear.
• 1 x USB3 physical port (3)
• 1 x USB2 virtual port (3) from physical USB3 above.
• 2 x USB3 ports from internal header (3)
• 2 x USB2 virtual ports from USB Header (3), presumably serving case front port(s)
• 2 x USB 2 physical ports (0)

Controller 3?

• 4 x USB2 physical ports (0)
• 4 x USB2 internal header ports (255), possibly serving Bluetooth, front case USB2 ports, or USB2 card reader in case front.

I am not sure if that means you only have two USB controllers or if there are three. My bet would be on three.

If there are only two controllers, it means you need to drop 3 ports from the AMD Chipset controller as you can have a maximum of 15 ports under each controller. the CPU controller only have 6 ports maximum so all of them can be used and activated.

From your USBPorts.kext these are shown as AppleUSBXHCIPCI and XHC0. It is the AppleUSBXHCIPCI that makes me think this configuration is not correct.

QUESTIONS:
Does the Kernel > Quirks > XhciPortLimit entry work with AMD systems in Monterey.

1. I know it stopped working in Intel systems when Big Sur 11.3 was released.
2. Is it not the same for AMD systems?
3. If it does work, I suppose that is how you undertook the port discovery phase.
4. If it doesn't it probably means your port discovery phase was messed up and you have not identified the controllers or ports correctly.

You may have to install macOS Catalina or an early version of macOS Big Sur to undertake the USB port discovery on your system with a working XhciPortLimit quirk.

When undertaking the USB port discovery in Hackintool it is always helpful to use the Comment section to identify which physical port is used when the USB2, USB3 or USB Type-C pen drive is inserted in a particular port.

My Intel Hack's USB configuration looks like this in Hackintool.

Intel Hack USB ports in Hackintool - comments used to confirm port discovered.

I would also say you should use the image for your Motherboard and Rear I/O plate to confirm any testing. I have provided the two images below. Use them to help you identify each port or internal header. You should know which internal headers are being used and what is connected to each header, or not as the case may be.

Rear I/O plate

Motherboard layout, with USB header ports highlighted in Red.

 

[rohling]

Thanks @Edhawk for the explanation and guidance. I don't notice a different behaviour on this systems regardless if the XhciPortLimit Quirk is enabled or not. I tried mapping with USBMap and checked the results in Hackintool. It seems fairly consistent now but obviously there's still bugs and sleep does still not work. There appear to be only two controllers, AppleUSBXHCIPCI and XHC0.

Port SS04 is not working for USB2.0 and I have no idea what the ITE device is and if I should or should not disable it.



I'll install Catalina these days to see if I get a different bevhavior then.

 

[Edhawk]

From the information you provided in the screenshots and PDF for your USBPorts configuration I would say you have made a couple of mistakes.

1. Ports SS01 & HS01 should be set as Type-c.
2. Ports HS06, HS07, HS08 & HS09 should be set as USB2
3. You have the Top 4 x USB2 ports on the rear marked as HS04 on the PDF but as HS06 in Hackintool, which is correct?
4. You have the 2nd row of USB2 ports marked as HS06 & HS07 on the PDF but as HS08 & HS09 in Hackintool, which is correct?
5. You have front right USB3 ports marked as HS02 & SS02 on the PDF but as HS03 & SS03 in Hackintool, which is correct?
6. You have the front left USB3 ports marked as HS03 & SS03 on the PDF but as HS04 & SS04 in Hackintool, which is correct?
7. You are missing HS02 and SS02, front USB3 port in Hackintool, why?
8. You don't need to remove the HS02 and SS02 ports, as you can have 15 ports on EACH USB Controller. This means you could have a maximum of 30 ports active in your system.
9. You currently have 11 ports active on the AppleUSBXHCIPCI controller, so adding these two ports in to the mix won't exceed the 15 port limit for this controller.
10. I'm not sure what you meant by SS04 not working for USB2 on the PDF of the Rear I/O plate. Did you mean the USB2 side of this port is not working?
11. The XHCO controller ports are fine.
12. I assume when you say the motherboard Type-c header is 'Disabled' you are saying you don't have an external Type-c port on the case front that can use this header.

You need to do some more USB port discovery and checking before you call this done.

Hope this helps.

 

[rohling]

Thanks for pointing all that out. A truly humbling experience.

I redid everything from scratch, creating a UTBMap.kext with USBToolbox under Windows and then checking and commenting with Hackintool.

• This fixed the one port not working with the USB 2.0 stick.
• SS01 and HS01 do not change anything when I flip the stick over, so type 9, USB C + sw is correct?
• SS02 and HS02 obviously belong to the USB C front header which my case does not have. I had them disabled in the previous config as they were unpopulated.
• Coming from the UTBMap there was a HS05 port which I deleted from the kext because I cloud not identify it.

Regardless what I try, the system goes to sleep but when I try to wake it up, the screen stays black.

 

[Edhawk]

Black screen issues are commonly caused by USB configurations being wrong, But not only because of USB issues.

Your USB config looks a lot better, it should help eliminate the USB ports as being the cause of the Black Screen issues when your system wakes.

You now need to look at other possible causes of black screen after sleep.

This is the information for AMD sleep issues in OC Troubleshooting guide, still mostly relating to USB but a bit more specific about the AMD Chipset and USB power issues - # sleep-crashing-on-amd

Can you post a copy of your DSDT.aml so I can see which EC fake device your system requires. You are using the Dortania generic/catch-all SSDT which I hate, as it contains so many variations. You might also be better served using a separate SSDT-USBX.aml for the USB power settings.

In your config.plist you need to change the following:

• Booter > Quirks > SetupVirtualMap = True, this should be False for your B550 Motherboard.
• Misc > Debug > AppleDebug= False, this should be set as True.
• UEFI > APFS > MinDate= 0, this should be set to -1
• UEFI > APFS > MinVersion=0, this should be set to -1

Hope this helps.

 

[rohling]

Here's the DSDT.aml...

I replaced the SSDT-EC-USBX-DESKTOP.aml with the SSDT-EC-USBX.aml that Hackintool generates but I don*t notice any different behaviour.

 

[Edhawk]

It will provide be a quicker boot than using the generic Dortania SSDT.

I will have a look at your DSDT and see what I can find that might help.

Did you make the other config.plist changes listed above?

The SSDT's and OC patches.plist attached below in the Results folder have been generated from your DSDT.aml using Corpnewt's SSDTTime python script.

• The SSDT-HPET.aml and ACPI patches should definitely be added to your /OC/ACPI folder and config.plist. They will deal with any IRQ issues/conflicts in your system.
• The SSDT-EC.aml is a custom Fake EC for your system, probably identical to the one generated by Hackintool, you would hope so. Obviously this doesn't include the USB power settings.
• The SSDT-USB-reset.aml can be used to reset your system's USB XHC controller(s) to allow hardware mapping.

This is a screenshot of the Patches_OC.plist generated and the entries for the three SSDT's.

 

[rohling]

I applied all the patches and changes.

Using the SSDT-EC-USBX.aml created by Hackintool, the behaviour is unchanged. System goes to sleep, powers back up when hitting the power button, but screen stays black.

When I use the the SSDT-EC-USBX.aml from your results.zip, the system powers back up right away, screen stays black.

log show --last 1d | grep -i "Wake reason" gives

2022-01-11 16:38:18.514886+0100 0x969 Default 0x0 251 0 airportd: systemWokenByWiFi: System Wake Reason not found
or
2022-01-11 16:38:23.320418+0100 0x38f Error 0x0 114 0 powerd: [powerd:sleepWake] PID 166 is not entitled to set wake reason

PID 166 is bluetoothd, so I pulled the Fenvi card from the rig, but that didn't change anything either.