Ryzen 7000 Testing

[ExtremeXT]

Yes, I would be grateful if you could send the EFI. I have a 7950x with an Asus Strix X670E-F.

Why not make your own? If you encounter any problems, we will help you here.

 

[ManuelB]

Dann schaut euch doch mal meine an bitte schlagt mich nicht wie gesagt bin schon bisschen raus und muss mich erst wieder einarbeiten
Ich habe heute versucht Monterey damit zu starten ...bleibt immer hier stehen siehe Bild

@ExtremeXT Then take a look at mine, please don't hit me, as I said, I'm already a bit out and have to get used to it again
Today I tried to start Monterey with it ... always stays here see picture

 

[ExtremeXT]

Dann schaut euch doch mal meine an bitte schlagt mich nicht wie gesagt bin schon bisschen raus und muss mich erst wieder einarbeiten

Can you please speak in English?

 

[mariettosun]

Dann schaut euch doch mal meine an bitte schlagt mich nicht wie gesagt bin schon bisschen raus und muss mich erst wieder einarbeiten

Use a debug efi to see your mmio area
Use opencore debug version and put target to 67
Then post txt file you will find in your efi partition

 

[ExtremeXT]

@CaseySJ Can you try this patch?

 

[CaseySJ]

@CaseySJ Can you try this patch?

Unfortunately this did not work. I tried Identifier equal to kernel and com.apple.iokit.IOPCIFamily.

 

[ExtremeXT]

Unfortunately this did not work. I tried Identifier equal to kernel and com.apple.iokit.IOPCIFamily.
View attachment 8233

Yeah, my bad, should be com.apple.iokit.IOPCIFamily and 22.99.99. Try removing the Base value, Find: 00 08 0F 85, Replace: 00 08 0F 84, Skip: 1

 

[ManuelB]

First of all, thank you for your help, my head is spinning as I said, I'm a bit out of the topic, I'm trying to get back in, but it takes a moment. I've just created a new EFI that doesn't work at all .

I'll try again tomorrow have to get up at 5 am so I'll lie down now but thank you very much for your help..maybe we can continue with that tomorrow.

 

[CaseySJ]

Interim Update #14:

• The new patches for Monterey and Ventura finally enable PCI devices
• The patches help both X670 boards and MSI X570 boards
• With Thunderbolt enabled in BIOS, Monterey boots up without any issue and Thunderbolt devices work if connected before boot (hot plug not [yet?] working)
• With Thunderbolt enabled in BIOS, Ventura unfortunately gets stuck trying to enable power on a USB port associated with Thunderbolt
• Intel I225-V will cause system crash if a cable is connected -- could be fixable with IOPCIFamily patch, but needs investigation
• OpenIntelWireless drivers work fine
• Broadcom WiFi/BT cards such as Fenvi FV-T919 work fine (Continuity features are supported with Broadcom cards)
• NVMe SSDs work fine
• Audio static (garbled output) is infrequent, but still present (use latest Asus BIOS for best results - 0803 or 0805)

Yet to Test:

• Aquantia 10GbE (Gigabyte GC-AQC113C)

 

[CaseySJ]

** Patch Theory **
How the patch works and/or what it does

Disclaimer:
I am not a PCI spec expert so the statements below may be an oversimplification or even incorrect​

PCI devices are not required to support all of the bus-level capabilities that are listed in the official spec. Each manufacturer can choose which capabilities their products will and will not support. Because PCIe is a newer version of the original PCI spec, it defines a number of additional capabilities, one of them being ETFs or Extended Tag Fields.

Starting with Monterey, macOS enables two extended tag fields, namely 8b and 10b (8-bit and 10-bit), in the function probeBusGated that is a member of the class IOPCIBridge. Before macOS can enable these fields, it has to discover whether the device supports these fields.

This is where bridgeProbeChild comes in. It is a member of the class IOPCIConfigurator, and is involved in the process of scanning the entire PCI bus, querying all devices for a list of their capabilities, and saving all of this information in IORegistry.

In Big Sur, probeBus does not enable ETFs.

In Monterey and newer, probeBusGated (which is a slightly modified version of probeBus that runs in a single thread) checks whether ETFs are supported and, if so, it specifically enables two of them if they are present: ETF 8b and ETF 10b. Each of these ETFs is checked separately and enabled if it is supported.

Unfortunately for our AM5 motherboards (and MSI X570 motherboards), when ETF 10b is enabled on any device that supports it, that device becomes a zombie from that point onwards! This causes our I225, WIFI, NVME, and other devices to become zombies.

There are at least two ways to patch this problem, hence the two different sets of patches provided.

Method 1:

• Looking at the code below from probeBusGated, we see that both ETFs are checked and enabled inside an if { } clause. Specifically:
  • if (!(useDefaultETFSettings) && (deviceCaps & 0x20))
• If we modify this if-condition to always return false, then the inner block will never be executed
• That is what the first patch does in x86 Assembly Code

In the code below, ETFE means Extended Tag Field Enable.

                    // Enable extended tag fields, if supported
                    uint32_t deviceCaps            = nub->reserved->configEntry->expressDeviceCaps1;
                    uint32_t deviceCaps2           = nub->reserved->configEntry->expressDeviceCaps2;
                    bool     useDefaultETFSettings = gIOPCIFlags & kIOPCIConfiguratorDefaultETF;

                    if (!(useDefaultETFSettings) && (deviceCaps & 0x20))
                    {
                        // Need to set ETFE for either 8b or 10b tags
                        uint16_t deviceControl = nub->configRead16(nub->reserved->expressCapability + 0x08, "probeBusGated:ExpressCapa");
                        deviceControl |= 0x100;
                        nub->configWrite16(nub->reserved->expressCapability + 0x08, deviceControl, "probeBusGated2");

                        // Enable 10b Tag Fields if the device can request them and its root port can complete them
                        struct IOPCIConfigEntry *rootPortEntry = nub->reserved->configEntry->rootPortEntry;

                        if ((deviceCaps2 & 0x20000) && (rootPortEntry->expressDeviceCaps2 & 0x10000))
                        {
                            uint16_t deviceControl2 = nub->configRead16(nub->reserved->expressCapability + 0x28, "probeBusGated:ExpressCapa");
                            deviceControl2 |= 0x1000;
                            nub->configWrite16(nub->reserved->expressCapability + 0x28, deviceControl2, "probeBusGated3");
                        }
                    }

Method 2:

• Our trace logging shows that ETF 8b does not cause a problem. Instead, only ETF 10b zombifies our devices
• So instead of disabling both ETFs, how can we just disable ETF 10b?
• We can modify the nested if-condition located inside the main if-condition to always return false, but notice that this nested condition depends on expressDeviceCaps2, which is queried by busProbeChild (part of IOPCIConfigurator)
• If we prevent expressDeviceCap2 from being queried and set, we can cause the inner if-condition to fail
• Because expressDeviceCaps2 is queried and set in busProbeChild (code shown below), we can make a change in x86 Assembly to stop it
• The alternative patch, therefore, converts the second statement below to a series of NOPs or No-Operations, which effectively erases the second line

        child->expressDeviceCaps1 = configRead32(child, child->expressCapBlock + 0x04, NULL, "bridgeProbeChild:ExpressCapa");
        child->expressDeviceCaps2 = configRead32(child, child->expressCapBlock + 0x24, NULL, "bridgeProbeChild:ExpressCapa");
        child->expressMaxPayload  = (child->expressDeviceCaps1 & 7);
        DLOG("  expressMaxPayload 0x%x\n", child->expressMaxPayload);

I plan to create Patch 3 that will just disable the inner if-condition from probeBusGated. That will allow me to compare the behavior of each one.

• Update: Method 3 patch has been created and is preferred over the previous two. All patches are located here:
  • https://forum.amd-osx.com/threads/ryzen-7000-testing.3318/page-44#post-24160

 

[backinblackx86]

Casey, While you don’t say you’re an expert, it is fascinating that you understand all of these details.

 

[CaseySJ]

** Aha Moment **​

Right after posting that lengthy Patch Theory, it suddenly occurred to me that useDefaultETFSettings is governed by kIOPCIConfiguratorDefaultETF, which is something we can actually control via a boot argument. Like this:

boot-args = "... pci=0x8000000 ..."

That's all we need to fix the problem. In fact, I was just able to boot Ventura with Thunderbolt for the first time. NO PATCHES NECESSARY!

​

                    // Enable extended tag fields, if supported
                    uint32_t deviceCaps            = nub->reserved->configEntry->expressDeviceCaps1;
                    uint32_t deviceCaps2           = nub->reserved->configEntry->expressDeviceCaps2;
                    bool     useDefaultETFSettings = gIOPCIFlags & kIOPCIConfiguratorDefaultETF;

                    if (!(useDefaultETFSettings) && (deviceCaps & 0x20))
                    {
                        // Need to set ETFE for either 8b or 10b tags
                        uint16_t deviceControl = nub->configRead16(nub->reserved->expressCapability + 0x08, "probeBusGated:ExpressCapa");
                        deviceControl |= 0x100;
                        nub->configWrite16(nub->reserved->expressCapability + 0x08, deviceControl, "probeBusGated2");

                        // Enable 10b Tag Fields if the device can request them and its root port can complete them
                        struct IOPCIConfigEntry *rootPortEntry = nub->reserved->configEntry->rootPortEntry;

                        if ((deviceCaps2 & 0x20000) && (rootPortEntry->expressDeviceCaps2 & 0x10000))
                        {
                            uint16_t deviceControl2 = nub->configRead16(nub->reserved->expressCapability + 0x28, "probeBusGated:ExpressCapa");
                            deviceControl2 |= 0x1000;
                            nub->configWrite16(nub->reserved->expressCapability + 0x28, deviceControl2, "probeBusGated3");
                        }
                    }

 

[backinblackx86]

Ding ding ding! We have a Winner! Thank you again Casey. Question, is the “Thunderbolt” actual Thunderbolt or is it USB4 ?

 

[CaseySJ]

Ding ding ding! We have a Winner! Thank you again Casey. Question, is the “Thunderbolt” actual Thunderbolt or is it USB4 ?

It's USB4 with Thunderbolt 4 (Intel Maple Ridge controller, device 0x1137). Just when you thought USB naming couldn't get any worse...

PCI Lookup

PCI Lookup is desinged to help you find the Vendor and Device descriptions you need to get drivers for you PC. If you are not sure where to start, there is some helpful information below that can get you started. If you are still lost, feel free to contact us, we would be happy to help!

www.pcilookup.com

 

[PoMpIs]

@CaseySJ Does the audio work now? or is it still bad?

Anyway, thank you very much for your immense perseverance to get Ryzen 7000 working.

 

[CaseySJ]

@CaseySJ Does the audio work now? or is it still bad?

Anyway, thank you very much for your immense perseverance to get Ryzen 7000 working.

Here's the state of audio with unofficial BIOS 0803:

• Audio playback through Safari is extremely stable. There are dropouts, but they are few and far between
• Audio playback through Firefox is better than before, but still choppy
• Audio playback through rear and front headphone jack is much less choppy than before
• Audio playback through external USB DAC is slightly choppy

If we run SpeedKeeper, then audio playback from all sources becomes nearly perfect. I am listening now to Disturbed's Sound of Silence from rear headphone jack connected to Sennheiser HD600. Wow...just wow!

 

[backinblackx86]

I am about to prepare Ventura installation media and see if I can build an EFI that boots with the recommended flags. What SSDT I need to block the NVIDIA card?

 

[DarkSilentSC]

I currently have Monterey 12.5 with AQC107 built-in ethernet not working right now. Any instruction you provide, I can assist in testing and ultimately get it working. (When your priority comes to that)

My findings and trials so far:
1. The longest lasting config was:
- No Aquantia patch via kernel/patches
- ForceAquantiaEthernet = true
- DisableIOMapper = false
- BIOS - SVM Mode OFF, IOMMU Mode Auto (BIOS Default)
However this leads to the Ethernet interface to go into Self Assigned IP mode, and sometimes lead to KP and reboot.
2. Any combination of kernel patches immediately leads to kernel panic along with ForceAquantiaEthernet = true, followed by reboot
3. Leaving ForceAquantiaEthernet = false renders any kernel patches useless (V1, V2, V3)
4. While leaving ForceAquantiaEthernet = false, Tried DisableIOMapper = false and enabled every possible BIOS option that can help enable CPU Virtualization didn’t make AppleVTD to appear.

 

[ExtremeXT]

** Aha Moment **​

Right after posting that lengthy Patch Theory, it suddenly occurred to me that useDefaultETFSettings is governed by kIOPCIConfiguratorDefaultETF, which is something we can actually control via a boot argument. Like this:

boot-args = "... pci=0x8000000 ..."

That's all we need to fix the problem. In fact, I was just able to boot Ventura with Thunderbolt for the first time. NO PATCHES NECESSARY!

View attachment 8236View attachment 8238​

                    // Enable extended tag fields, if supported
                    uint32_t deviceCaps            = nub->reserved->configEntry->expressDeviceCaps1;
                    uint32_t deviceCaps2           = nub->reserved->configEntry->expressDeviceCaps2;
                    bool     useDefaultETFSettings = gIOPCIFlags & kIOPCIConfiguratorDefaultETF;

                    if (!(useDefaultETFSettings) && (deviceCaps & 0x20))
                    {
                        // Need to set ETFE for either 8b or 10b tags
                        uint16_t deviceControl = nub->configRead16(nub->reserved->expressCapability + 0x08, "probeBusGated:ExpressCapa");
                        deviceControl |= 0x100;
                        nub->configWrite16(nub->reserved->expressCapability + 0x08, deviceControl, "probeBusGated2");

                        // Enable 10b Tag Fields if the device can request them and its root port can complete them
                        struct IOPCIConfigEntry *rootPortEntry = nub->reserved->configEntry->rootPortEntry;

                        if ((deviceCaps2 & 0x20000) && (rootPortEntry->expressDeviceCaps2 & 0x10000))
                        {
                            uint16_t deviceControl2 = nub->configRead16(nub->reserved->expressCapability + 0x28, "probeBusGated:ExpressCapa");
                            deviceControl2 |= 0x1000;
                            nub->configWrite16(nub->reserved->expressCapability + 0x28, deviceControl2, "probeBusGated3");
                        }
                    }

Hmm, does the boot arg provide any advantages over the kernel patch except that it won't break after OS updates?

 

[mariettosun]

boot-args = "... pci=0x8000000 ..."

Hi @CaseySJ
this boot arg seems it could be used also without negative side effects also in systems which does not need of it
if it works also on x570 (MSI) and on some TRX40 board could be very interesting for those users

Thanks again for all your investigation and great results in this field