Ryzen 7000 Testing

[CaseySJ]

hi @CaseySJ can you explain more deeper how do you find this patch and useful step you did for this new finding (obviously I know you evaluated debug posted but I am interested in find/replace values (how to) and also base nomenclature)
thank you

Certainly. I’ll create another Patch Theory post soon. Currently 03:49 — just woke up and drinking nice hot coffee by the fireplace.

 

[Galve2000]

Do you have -radcodec boot arg? You need it to get hardware decoding/
encoding on spoofed GPUs.

I do not have-radcodec on my boot args, no... I will add it as per yr suggestion.

But I do not have it in my X570 Creator / 6900XTX build and GFX Metal works fine, so I do not think that's it.

The issue is either something to do w\ the 6650XT vs 6900XTX or the fact that I am not using an SSDT to point to the GPU in my X670E Hero / 6650XT build.

 

[Lorys89]

tb4 WIP for hotplug and wake

for asus x670e :
for hotplug I think the method GPE - EE1B
for wake to method SB - IWAK

 

[Edhawk]

Are you using the RX 6600 XT device-id for your RX 6650 XT, with this being injected via the DeviceProperties section of your config.plist. As you aren't using an SSDT for the dGPU.

Your DeviceProperties for the RX 6650 XT should look something like this.



The Device Path would be different as this screenshot is taken from an Intel system's config.plist.

 

[CaseySJ]

** Patch Theory: PCI Bus Enumeration in Ventura with Thunderbolt and WiFi Enabled **
Click here for the patch itself​

This post explains how the problem was investigated, leading to development of the patch. Thanks to @mariettosun for showing us that on-board Thunderbolt conflicted with on-board WiFi. This told us that on-board Thunderbolt could in fact work in Ventura. Comparing PCI debug logs between Monterey and Ventura revealed that Ventura was not discovering and enumerating devices properly on the PCI bus. Based on experience gained from the earlier and much lengthier investigation of PCI Zombies, initial suspicion fell on the IOPCIConfigurator class, which is part of the IOPCIFamily kext. PCI bus discovery and enumeration is handled almost entirely by IOPCIConfigurator.

Fortunately, Apple has open-sourced the entire code for IOPCIFamily, and Apple continues to post regular updates as new versions of macOS are released. It was then a relatively straightforward task to compare IOPCIConfigurator.cpp between Monterey and Ventura. This was done using the free Meld application, which can be installed via Home-brew (https://brew.sh). A screenshot of the comparison is shown here:

On the far right side of the window we get a glimpse of all of the differences between the two files. These are marked in Blue and Red boxes on the right side. Fortunately there aren't too many changes. Most of the changes involve functions that extend the discovery of PCIExpressCapabilities. But there is one small change shown in the big green/red box that involves a second method of discovering whether a PCI bridge supports native hot plug capability. This second method does not exist in earlier versions of macOS, so it's not a necessary addition.

Because Thunderbolt supports hot plug, I suspected that this change might be the source of the problem. It was just a hunch, but it seemed plausible given that all other differences between the source files seemed unrelated to the problem at hand. The next step was to extract the IOPCIFamily executable, which is not present in /System/Library/Extensions. In Ventura, Apple has removed nearly all kext executable files that would normally appear in the kext's MacOS folder. Fortunately there's still a way to access those files. We do this by installing the Kernel Debug Kit (KDK) for Ventura 13.2 (release version) so that kexts inside the KDK are release-mode builds (reference). Next we create a temporary snapshot of the system (livemount) and ditto the KDK System folder into the livemount System folder. This is much easier done than said!

And now we have full access to all MacOS folders inside each kext. This allows us to open IOPCIFamily in a disassembler, which in my case is the Hopper app. It is now straightforward to locate the assembly code for the green/red section. I modified the assembly code to jump over the if (type == KPCIStatic) block and return from the function early.

So the patch makes this change:



And this is sufficient to bypass the problem.

 

[CaseySJ]

tb4 WIP for hotplug and wake

for asus x670e :
for hotplug I think the method GPE - EE1B
for wake to method SB - IWAK

Interesting -- you've changed:

• Device ID to 0x8A17, which is Ice Lake Thunderbolt 3
  • This is the Thunderbolt 3 controller in last generation Intel MacBook Pro
• Class-Code to 0x088000
  • Base class 0x08 = Base System Peripheral
  • Sub class 0x80 = Other System Peripheral
  • Programming Interface = 0x00

Thunderbolt is normally:

• Class-Code 0x060400
  • Base class 0x06 = Bridge device
  • Sub class 0x04 and Programming Interface 0x00 = PCI to PCI bridge
• But the Native Host Interface (NHI) or TBDC is always class-code 0x088000
  • Hence no issue there

 

[Lorys89]

Interesting -- you've changed:

• Device ID to 0x8A17, which is Ice Lake Thunderbolt 3
  • This is the Thunderbolt 3 controller in last generation Intel MacBook Pro
• Class-Code to 0x088000
  • Base class 0x08 = Base System Peripheral
  • Sub class 0x80 = Other System Peripheral
  • Programming interface 0x00

Yes exactly

 

[Vorshim92]

Asus ProArt x570 Creator, VENTURA 13.2 PCIdebug-bug xD
@CaseySJ hi!
Introduction: I don't have any problems of device that dissapears when I enable my MapleRidge thunderbolt on x570 like the problem on x670 but I encounter a strange problem yesterday using my usbmap.kext that contain this "pcidebug" as location paths of the XHC controllers:

Spoiler: pcidebug image

I noticed that with Reset NVRAM or when I made some change in bios (like disable wifi and bluetooth device) this "location path" change.
sometimes only the 2 XHC controllers under GPP1(where there are wifi, thunderbolt and other devices), sometimes also the XHC controller under GP13
see the image below

Spoiler: ioreg pcidebug

I saw your patch theory yesterday, do you think I can try to use it too on my x570 build?

p.s. I also have internal SATA drives appear as external drives (orange icons) but I tried to disable thunderbolt device from bios and nothing changes, i fix it adding "built-in 01" in dev prop in config. Maybe this patch can fix that problem too without this.

 

[Lorys89]

Asus ProArt x570 Creator, VENTURA 13.2 PCIdebug-bug xD
@CaseySJ hi!
Introduction: I don't have any problems of device that dissapears when I enable my MapleRidge thunderbolt on x570 like the problem on x670 but I encounter a strange problem yesterday using my usbmap.kext that contain this "pcidebug" as location paths of the XHC controllers:

Spoiler: pcidebug image

View attachment 9675

I noticed that with Reset NVRAM or when I made some change in bios (like disable wifi and bluetooth device) this "location path" change.
sometimes only the 2 XHC controllers under GPP1(where there are wifi, thunderbolt and other devices), sometimes also the XHC controller under GP13
see the image below

Spoiler: ioreg pcidebug

View attachment 9674

I saw your patch theory yesterday, do you think I can try to use it too on my x570 build?

p.s. I also have internal SATA drives appear as external drives (orange icons) but I tried to disable thunderbolt device from bios and nothing changes, i fix it adding "built-in 01" in dev prop in config. Maybe this patch can fix that problem too without this.

When enabling or disabling devices in bios or adding pcie devices, debug pci values vary normally. You have to see the new values and change it in the kext usbmap, for the orange icons just fix me built in the sata controller.

 

[Vorshim92]

When enabling or disabling devices in bios or adding pcie devices, debug pci values vary normally. You have to see the new values and change it in the kext usbmap, for the orange icons just fix me built in the sata controller.

ye! exactly what I did. Meantime I tried the patch and nothing changes... so it's not the same problem. Thanks anyway. I will find another method than usbmap kext for usbmapping because i can't always do this everytime xD

 

[ExtremeXT]

ye! exactly what I did. Meantime I tried the patch and nothing changes... so it's not the same problem. Thanks anyway. I will find another method than usbmap kext for usbmapping because i can't always do this everytime xD

You can make a custom USB map (or transfer your current one) which doesn't use USBToolBox and finds XHCI devices by IOReg path.

 

[CaseySJ]

Asus ProArt x570 Creator, VENTURA 13.2 PCIdebug-bug xD
@CaseySJ hi!
Introduction: I don't have any problems of device that dissapears when I enable my MapleRidge thunderbolt on x570 like the problem on x670 but I encounter a strange problem yesterday using my usbmap.kext that contain this "pcidebug" as location paths of the XHC controllers:

I noticed that with Reset NVRAM or when I made some change in bios (like disable wifi and bluetooth device) this "location path" change.
sometimes only the 2 XHC controllers under GPP1(where there are wifi, thunderbolt and other devices), sometimes also the XHC controller under GP13
see the image below

I saw your patch theory yesterday, do you think I can try to use it too on my x570 build?

Glad you also discovered this problem! I described it here a couple of days ago:

Asus X670E Gene EFI -- Adaptable to Other X670, X670E, B650 and B650E Boards

** Preliminary Build Guide for Asus X670E Gene and Other AM5 Boards ** Also refer to this Outline of the Steps Supports Big Sur, Monterey and Ventura 14 April 2023: Added OpenCore 0.9.1 EFI Folder See post #5 below for details and EFI folder NOTE: If you choose to use the files and...

forum.amd-osx.com

This is another reason I don’t use USBToolBox myself, preferring instead to create a USB port map SSDT and accompanying simple kext that is not bound to “pcidebug” but bound instead to ACPI device name and device-ID of each XHC controller.

If you see the EFI folder posted in the thread linked above, you’ll see how this is done. This method is immune to changes in BIOS.

It may be possible to use the kext by itself, but this may break one-key wake from sleep. With both kext and SSDT the system wakes with a single key press (USBWakeFixup and SSDT-USBW should be enabled; SSDT-USBW need to be modified for actual USB controller device paths on your board).

p.s. I also have internal SATA drives appear as external drives (orange icons) but I tried to disable thunderbolt device from bios and nothing changes, i fix it adding "built-in 01" in dev prop in config. Maybe this patch can fix that problem too without this.

This requires setting “built-in” to either 00 or 01.

 

[ExtremeXT]

Glad you also discovered this problem! I described it here a couple of days ago:

Asus X670E Gene EFI -- Adaptable to Other X670, X670E, B650 and B650E Boards

** Preliminary Build Guide for Asus X670E Gene and Other AM5 Boards ** Also refer to this Outline of the Steps Supports Big Sur, Monterey and Ventura 14 April 2023: Added OpenCore 0.9.1 EFI Folder See post #5 below for details and EFI folder NOTE: If you choose to use the files and...

forum.amd-osx.com

This is another reason I don’t use USBToolBox myself, preferring instead to create a USB port map SSDT and accompanying simple kext that is not bound to “pcidebug” but bound instead to ACPI device name and device-ID of each XHC controller.

If you see the EFI folder posted in the thread linked above, you’ll see how this is done. This method is immune to changes in BIOS.

It may be possible to use the kext by itself, but this may break one-key wake from sleep. With both kext and SSDT the system wakes with a single key press (USBWakeFixup and SSDT-USBW should be enabled; SSDT-USBW need to be modified for actual USB controller device paths on your board).


This requires setting “built-in” to either 00 or 01.

For the SATA drive, you can enable ExternalDiskIcons in OC. Why do you need a kext along with the SSDT map? The map you helped me with works perfectly without any other kext.

 

[Vorshim92]

Glad you also discovered this problem! I described it here a couple of days ago:

Asus X670E Gene EFI -- Adaptable to Other X670, X670E, B650 and B650E Boards

** Preliminary Build Guide for Asus X670E Gene and Other AM5 Boards ** Also refer to this Outline of the Steps Supports Big Sur, Monterey and Ventura 14 April 2023: Added OpenCore 0.9.1 EFI Folder See post #5 below for details and EFI folder NOTE: If you choose to use the files and...

forum.amd-osx.com

This is another reason I don’t use USBToolBox myself, preferring instead to create a USB port map SSDT and accompanying simple kext that is not bound to “pcidebug” but bound instead to ACPI device name and device-ID of each XHC controller.

If you see the EFI folder posted in the thread linked above, you’ll see how this is done. This method is immune to changes in BIOS.

It may be possible to use the kext by itself, but this may break one-key wake from sleep. With both kext and SSDT the system wakes with a single key press (USBWakeFixup and SSDT-USBW should be enabled; SSDT-USBW need to be modified for actual USB controller device paths on your board).


This requires setting “built-in” to either 00 or 01.

thanks for the reply master! In the end I chose to build directly an ssdt based on the old one from my B550 Vision D (that you made) and to turn off the controller and recreate everything with new name because I have two XHC0 controller, one from GP13 and one from GPP1. I think it's not good to have multiple XHC with the same name.

something like this:

Spoiler: ssdt

p.s. I was asking my self the same question of ExtremeXT about the kext alongside the ssdt, why?

 

[mariettosun]

For the SATA drive, you can enable ExternalDiskIcons in OC.

with the previous conflict we have with TB and internal wifi, was not possible to use Externalicons quirk or also Device properties built in property
in my case, in that "error" condition only a kext was working (AHCIUnsupported)
with CaseySJ patch now work all method to bring correct icons in x670 Sata controller (and also on NVME controller)

 

[CaseySJ]

For the SATA drive, you can enable ExternalDiskIcons in OC. Why do you need a kext along with the SSDT map? The map you helped me with works perfectly without any other kext.

Yes we can enable ExternalDiskIcons to achieve similar effect. However, the OpenCore documentation (page 35) warns against using this quirk:



On some motherboards one-key wake may not work with just the kext. One can try without the SSDT to see if the kext alone is sufficient.

 

[CaseySJ]

thanks for the reply master! In the end I chose to build directly an ssdt based on the old one from my B550 Vision D (that you made) and to turn off the controller and recreate everything with new name because I have two XHC0 controller, one from GP13 and one from GPP1. I think it's not good to have multiple XHC with the same name.

something like this:
…

p.s. I was asking my self the same question of ExtremeXT about the kext alongside the ssdt, why?

It would be good to try without the SSDT and describe the result. If everything is fine (including one-key wake from sleep) then kext alone is sufficient.

In the Hackintosh world there are so many differences between motherboard manufacturers, chipsets, BIOS settings, memory DIMMs, processors, NVMe SSDs (such as broken trim) and attached devices that the idea of “one size fits all” does not apply.

We just need to experiment and find what works for our specific system configuration.

 

[Vorshim92]

It would be good to try without the SSDT and describe the result. If everything is fine (including one-key wake from sleep) then kext alone is sufficient.

In the Hackintosh world there are so many differences between motherboard manufacturers, chipsets, BIOS settings, memory DIMMs, processors, NVMe SSDs (such as broken trim) and attached devices that the idea of “one size fits all” does not apply.

We just need to experiment and find what works for our specific system configuration.

Fully agree!
By the way, I can't use just the kext because I need to rename in ACPI one of the controller XHC0, they have the same IOName so the kext can't recognize which one is under GPP1 or GP13 I think.

Spoiler: xhc0 x2

In fact when I extract usbports from hackintool (Hackintool don't use pcidebug but IONameMatch and IOPCIPrimaryMatch) I only saw one XHC0 controller and I can't add the other one because it would make a mess

Spoiler: hackintool plist

so I will made just one ssdt to change GP13 XHC0 to XHC_ and then use the USBPorts.kext. Don't know if is a good plan but I will try.
I will made a thread for this motherboard as soon as possible.

 

[ExtremeXT]

Fully agree!
By the way, I can't use just the kext because I need to rename in ACPI one of the controller XHC0, they have the same IOName so the kext can't recognize which one is under GPP1 or GP13 I think.

The manual USB map sample by Dortania uses the full IOReg path, so that's not an issue.

On some motherboards one-key wake may not work with just the kext. One can try without the SSDT to see if the kext alone is sufficient.

Yes, I get that one key wake might not work with ONLY the kext, but what about ONLY the SSDT?

 

[CaseySJ]

Fully agree!
By the way, I can't use just the kext because I need to rename in ACPI one of the controller XHC0, they have the same IOName so the kext can't recognize which one is under GPP1 or GP13 I think.

In fact when I extract usbports from hackintool (Hackintool don't use pcidebug but IONameMatch and IOPCIPrimaryMatch) I only saw one XHC0 controller and I can't add the other one because it would make a mess
so I will made just one ssdt to change GP13 XHC0 to XHC_ and then use the USBPorts.kext. Don't know if is a good plan but I will try.
I will made a thread for this motherboard as soon as possible.

This is a good plan. Getting some experience with SSDTs is an added bonus.