Ryzen 7000 Testing

[ExtremeXT]

We may need to be somewhat specific.

If we just say, support AMD Ryzen 7000 series on AM5, that may be too vague. They may need to know what issues we're experiencing and where we believe the problem lies.

There are two known problems:

• Garbled audio across all recent versions of macOS
• Boot loop only in Monterey and Ventura when PCIe devices are installed or enabled in BIOS
  • For this issue, I can provide serial capture logs to them

The main problem IMO is PCIe, we should give serial logs, OC debug boot logs, a hardware report (you can do that with HWiNFO64 on Windows), maybe an IOReg dump and kernel log from both FrankenMon and VanillaMon and explanations (how FrankenMon was created etc).

 

[CaseySJ]

Just documenting one more test...

• VanillaMon with only AppleACPIPlatform taken from Big Sur
• This replacement succeeds as shown below
• About to reboot...

% sudo mount -o nobrowse -t apfs /dev/disk2s11 ./livemount
% cd livemount/System/Library/Extensions

% sudo rm -rf AppleACPIPlatform.kext
% sudo cp -r ~/Downloads/Big\ Sur\ kexts/AppleACPIPlatform.kext .
% sudo chmod -R 755 AppleACPIPlatform.kext
% sudo chown -R 0:0 AppleACPIPlatform.kext

% sudo kmutil install --volume-root ~/livemount --update-all

checking collections...
Warning: com.apple.driver.KextExcludeList was not found!
updated extension 'com.apple.driver.AppleACPIPlatform' found on disk at '/Users/casey/livemount/System/Library/Extensions/AppleACPIPlatform.kext' (mach-o UUID changed from 4A0A4F25-EC60-320D-8AC8-E7FB68454928 to 96434EAD-5B53-3136-83C9-E36B9B281F5B)
updated extension 'com.apple.driver.AppleACPIEC' found on disk at '/Users/casey/livemount/System/Library/Extensions/AppleACPIPlatform.kext/Contents/PlugIns/AppleACPIEC.kext' (mach-o UUID changed from 91278068-1E8B-3805-B2B0-33FF91B32865 to BDD6DBCF-EE20-38F7-8D8F-A09AE0F1EB8A)
updated extension 'com.apple.driver.AppleACPIButtons' found on disk at '/Users/casey/livemount/System/Library/Extensions/AppleACPIPlatform.kext/Contents/PlugIns/AppleACPIButtons.kext' (mach-o UUID changed from 6A68D568-B54F-3DB9-85F4-1737362495A2 to 81060ACC-8E8E-3D1A-97A2-149E3BF95A4E)
updated extension 'com.apple.driver.usb.AppleUSBVHCIRSM' found on disk at '/Users/casey/livemount/System/Library/Extensions/IOUSBHostFamily.kext/Contents/PlugIns/AppleUSBVHCIRSM.kext' (mach-o UUID changed from <unknown> to 222839F6-DAA2-38EC-B455-207CECEAC4EE)
updated extension 'com.apple.driver.usb.AppleUSBVHCICommonRSM' found on disk at '/Users/casey/livemount/System/Library/Extensions/AppleUSBCommon.kext/Contents/PlugIns/AppleUSBVHCICommonRSM.kext' (mach-o UUID changed from <unknown> to DFF6CA06-00F9-31FA-A782-39FFBE651362)
updated extension 'com.apple.driver.usb.AppleUSBRecoveryHost' found on disk at '/Users/casey/livemount/System/Library/Extensions/IOUSBHostFamily.kext/Contents/PlugIns/AppleUSBRecoveryHost.kext' (mach-o UUID changed from <unknown> to 915AE279-A238-3275-B380-DE9DCBDC19E7)
updated extension 'com.apple.driver.AppleMobileDevice' found on disk at '/Library/Apple/System/Library/Extensions/AppleMobileDevice.kext' (mach-o UUID changed from <unknown> to <unknown>)
rebuilding release collections: boot, system
rebuilding release collections:
    boot kernel collection
    system kext collection
rebuilding local auxiliary collection
kmutil done

% sudo bless --folder ~/livemount/System/Library/CoreServices --bootefi --create-snapshot

---

AFTER REBOOT: IOPCIFamily encounters a crash.

 

[CaseySJ]

Additional Notes:

• When a PCIe card is installed (other than GPU), vanilla Monterey and Ventura will reboot during launch
• But with IOMMU disabled in BIOS, vanilla Monterey and Ventura will boot up successfully, but drivers will not attach to PCIe devices
  • Update: Disabling IOMMU allowed Ventura to boot twice, but not a 3rd or 4th time, so this is also not the 'smoking gun'; but it may be one factor
• Enabling the DisableIOMapper quirk (with IOMMU either enabled or disabled) causes a boot loop in vanilla Monterey and Ventura

Now going to enable Thunderbolt and see if these OSs will boot.

• Update: Vanilla Monterey and Ventura will not boot when Thunderbolt is enabled.
• I just need to configure the system in such a way as to allow Vanilla Monterey to boot fully with PCIe serial card installed. This will allow me to capture a more complete boot log.

 

[etorix]

Additional Notes:

• When a PCIe card is installed (other than GPU), vanilla Monterey and Ventura will reboot during launch
• But with IOMMU disabled in BIOS, vanilla Monterey and Ventura will boot up successfully, but drivers will not attach to PCIe devices
• Enabling the DisableIOMapper quirk (with IOMMU either enabled or disabled) causes a boot loop in vanilla Monterey and Ventura

This suggest that recent versions of macOS are increasingly reliant on IOMMU (VT-d on Intel platforms), and that solving the issue may require to attach AppleVTD to AMD-V (AMD's implementation of IOMMU).
Which is easier said than done…

 

[Middleman]

Could it be that there’s something in the Thunderbolt implementation is the main cause of the issue? Don’t forget Thunderbolt activation is closely tied to USB-C now. I’m also thinking maybe IOMMU needs a physical patch for AMD systems in order for the PCIe slots to work properly.

 

[CaseySJ]

What We Know So Far:

• AM4 Platform
  • Monterey and Ventura:
    • Monterey and Ventura boot up properly with PCIe cards and NVMe SSDs installed
    • There is no audio stuttering
    • Some PCIe devices such as built-in Intel Ethernet may not work (likely due to lack of AppleVTD)
  • Big Sur
    • There is less need for AppleVTD in Big Sur
    • Built-in Intel Ethernet ports should work
• AM5 Platform
  • All versions of macOS exhibit audio stuttering, but this is improved -- not solved -- by running SpeedKeeper
    • Is this really related to Ryzen 7000 CPUs having on-board iGPUs?
  • Monterey and Ventura:
    
    • Presence of PCIe devices causes boot failure
    • In Monterey we can replace AppleACPIPlatform and IOPCIFamily with those from Big Sur
      
      • This allows Monterey to work just as well as Big Sur
    • In Ventura we weren't successful in replacing AppleACPIPlatform and IOPCIFamily with those from Big Sur
  • Big Sur
    
    • Works very well -- all PCIe devices work, including Intel i225-V Ethernet
      
      • Again, audio stuttering exists in all versions of macOS
    • On-board Thunderbolt also works when devices are connected and powered before boot
      
      • Hot plug not (yet) working

Although we can look for differences between Big Sur (where PCIe devices work) and Monterey (where PCIe devices don't work) in an effort to patch Monterey so that it "regresses" to the level of Big Sur, that may not be a wise option. In my opinion it is better to ask, Why does Monterey work on AM4 but not on AM5? How can we make AM5 appear more like AM4? This could mean:

• Determining if there is a magical BIOS setting that we've overlooked
• Modifying DSDT or SSDT
• Modifying one or more Acidanthera kexts
• Modifying or creating a UEFI driver to suppress the problem
• Creating a kernel patch to suppress the problem

All of this, of course, relies on narrowing the root cause to a few items and tackling them one by one. We tried to narrow the root cause through serial port debugging, but the logs get garbled right when we need them most.

It seems this problem should be solvable by someone with the right experience -- someone who can look at the symptoms we've described and immediately render a diagnosis.

 

[CaseySJ]

** BIOS Settings for Reducing Temperature and Power Draw **
Based on OptimumTech's Video

These settings reduce CPU voltage by 20 units and cap power consumption to 85W
​

 

[Middleman]

@CaseySJ,

Some excellents points you've made there. I'm sure there's a ton of stuff we'll have to peruse for the answer.

As for the audio stuttering, I just had a thought - I do think maybe it is IGPU related. Is there any way we could somehow disable the IGPU audio output or to separate it from being mixed with the main system audio codec output?

 

[CaseySJ]

@CaseySJ,

Some excellents points you've made there. I'm sure there's a ton of stuff we'll have to peruse for the answer.

As for the audio stuttering, I just had a thought - I do think maybe it is IGPU related. Is there any way we could somehow disable the IGPU audio output or to separate it from being mixed with the main system audio codec output?

From the SpeedKeeper page on Github:

Well, the issue seems to be a relation of clock speed of the CPU and the clock of the OS. When the processor is not busy enough, the clock speed drops, and that makes the OS de-sync with the CPU, sound is very much dependent on timing, and even the clock in the status bar knows to lag behind.

Because his app actually makes a huge improvement, I’m inclined to believe that the root cause lies somewhere along these lines.

 

[ExtremeXT]

What We Know So Far:

• AM4 Platform
  • Monterey and Ventura:
    • Monterey and Ventura boot up properly with PCIe cards and NVMe SSDs installed
    • There is no audio stuttering
    • Some PCIe devices such as built-in Intel Ethernet may not work (likely due to lack of AppleVTD)
  • Big Sur
    • There is less need for AppleVTD in Big Sur
    • Built-in Intel Ethernet ports should work
• AM5 Platform
  • All versions of macOS exhibit audio stuttering, but this is improved -- not solved -- by running SpeedKeeper
    • Is this really related to Ryzen 7000 CPUs having on-board iGPUs?
  • Monterey and Ventura:
    
    • Presence of PCIe devices causes boot failure
    • In Monterey we can replace AppleACPIPlatform and IOPCIFamily with those from Big Sur
      
      • This allows Monterey to work just as well as Big Sur
    • In Ventura we weren't successful in replacing AppleACPIPlatform and IOPCIFamily with those from Big Sur
  • Big Sur
    
    • Works very well -- all PCIe devices work, including Intel i225-V Ethernet
      
      • Again, audio stuttering exists in all versions of macOS
    • On-board Thunderbolt also works when devices are connected and powered before boot
      
      • Hot plug not (yet) working

Although we can look for differences between Big Sur (where PCIe devices work) and Monterey (where PCIe devices don't work) in an effort to patch Monterey so that it "regresses" back to the level of Big Sur, that may not be a wise course of action. In my opinion it is better to ask, Why does Monterey work on AM4 but not on AM5? How can we make AM5 appear more like AM4? This could mean:

• Determining if there is a magical BIOS setting that we've overlooked
• Modifying DSDT or SSDT
• Modifying one or more Acidanthera kexts
• Modifying or creating a UEFI driver to suppress the problem
• Creating a kernel patch to suppress the problem

All of this, of course, relies on narrowing the root cause to a few items and tackling them one by one. We tried to narrow the root cause through serial port debugging, but the logs get garbled right when we need them most.

It seems that this problem is quite solvable by someone with the right experience -- someone who can look at the symptoms we've described here and immediately render a diagnosis.

The audio problem is 100% somehow related to the iGPU, as AMD AM4 APUs also have this problem.

To me, the PCIe problem looks like a firmware bug in AMD's AGESA which first appeared in 500 series AMD MSI boards (A520, B550, X570) AFTER the BIOS update that added support for Zen 4 CPUs. I have ACPI dumps of the old BIOS and the new one, but I haven't been able to find something that would cause the issue. I can upload them here when I get home (ETA 5 days).

 

[CaseySJ]

A problem with SSDT-IGPU-DISABLE has been fixed. Latest version attached. However, this alone does not fix the audio stutter!

Original Version (left) and New Version (right).

 

[ExtremeXT]

A problem with SSDT-IGPU-DISABLE has been fixed. Latest version attached. However, this alone does not fix the audio stutter!

Original Version (left) and New Version (right).
View attachment 7979View attachment 7980

Shouldn't the values be 0xff, 0xff, 0xff, 0xff instead of 0xff, 0xff, 0x00, 0x00

 

[CaseySJ]

Shouldn't the values be 0xff, 0xff, 0xff, 0xff instead of 0xff, 0xff, 0x00, 0x00

For device-id, vendor-id, subsystem-id, and subsystem-vendor-id only the first 2 bytes are used. Because there are now no child devices under VGA, it means we succeeded in fully disabling the device.

 

[CaseySJ]

Incidentally, the five Visual patches are not necessary for Monterey to boot on this system:

 

[Middleman]

@CaseySJ,

It's great that you've managed to correct SSDT-IGPU-Disable. That for sure would help a lot of users out there with these boards.

I think the next part is, we should be looking with Hackintool and see which of the AMD PCI audio devices are still active and try to disable those.

From my understanding there should be at least two devices that make up the AMD audio codec, and they are enabled when we use SSDT-SBUS-MCHC.

 

[fabiosun]

rom my understanding there should be at least two devices that make up the AMD audio codec, and they are enabled when we use SSDT-SBUS-MCHC.

This is not true ie for trx40 systems which have similar audio on board (4080 and 1220 chip bridged to rule Audio), no need ssdt, no need of any kext for it

 

[fabiosun]

about contacting OpenCore devs:

As you all know, OpenCore developers do not like questions in general that are poorly justified by serious debugging
particularly if they come from users of AMD systems

My humble suggestion is to contact not the lead developers of the project, but perhaps some of those known to use AMD systems

Again, it is critical to provide logs without uncertainty
Otherwise they will say it's the usual AMD garbage and won't consider it

The debugging done here (by CaseSJ and ExtremeXT) seems very significant to me, it should just be collected in a more' compact and incisive way (imho)

 

[PoMpIs]

Guys, shamino from Asus has released a bios for these boards where you can disable the iGPU in the bios, so you won't need the SSDT-iGPU-Disable

X670 resource

ill use this thread to collect some new test bioses for the boards, maybe also to explain some less understood options to disable cores ccd go here and choose ccd xx bit map down core. each ones stand for an enabled core best to disable from the back, ie: 110000 instead of 0011000 after...

rog.asus.com

maybe this new bios helps hackintosh a lot

 

[craighazan]

Yay!!!, we’re back on the air!, thought I got banned!.

 

[CaseySJ]

Guys, shamino from Asus has released a bios for these boards where you can disable the iGPU in the bios, so you won't need the SSDT-iGPU-Disable

X670 resource

ill use this thread to collect some new test bioses for the boards, maybe also to explain some less understood options to disable cores ccd go here and choose ccd xx bit map down core. each ones stand for an enabled core best to disable from the back, ie: 110000 instead of 0011000 after...

rog.asus.com

maybe this new bios helps hackintosh a lot

Awesome! Will give it a try shortly.