Ryzen 7000 Testing

[fabiosun]

Thanks a lot for trying!
If you doesn’t hate clover as extreme does
You can try to use the same patches you are using in this opencore patches a choose an old clover release (maybe 5143)
A version before the release (the clone) of that quirk we said
This version had a bug on tsc which produced weird results on audio and in fast animation
Then I will quit my asking till a smarter idea to propose you

 

[CaseySJ]

@CaseySJ Can you try this on a Monterey installation?

ROG-Zephyrus-G14-GA402-Hackintosh/IOPCIFamily.md at main · b00t0x/ROG-Zephyrus-G14-GA402-Hackintosh

Hackintosh for ASUS ROG Zephyrus G14 (GA402) 2022. - b00t0x/ROG-Zephyrus-G14-GA402-Hackintosh

github.com

I wasn’t aware of any simple means of modifying a cryptographically sealed file system. Has anyone actually tried these commands?

My first attempt led to an error on the first step (the mount step).

 

[CaseySJ]

Thanks a lot for trying!
If you doesn’t hate clover as extreme does
You can try to use the same patches you are using in this opencore patches a choose an old clover release (maybe 5143)
A version before the release (the clone) of that quirk we said
This version had a bug on tsc which produced weird results on audio and in fast animation
Then I will quit my asking till a smarter idea to propose you

Oh, you’re forcing me to reopen old wounds with Clover! But it’s all good… Will try soon, but no guarantees I can make it boot!

 

[ExtremeXT]

I wasn’t aware of any simple means of modifying a cryptographically sealed file system. Has anyone actually tried these commands?

My first attempt led to an error on the first step (the mount step).

Which command did you run to mount? The one in the code block? Use that and not the one from Dortania, but make sure SIP and SecureBootModel are disabled. The commands should work as there are a few users with that laptop.

 

[CaseySJ]

Which command did you run to mount? The one in the code block? Use that and not the one from Dortania, but make sure SIP and SecureBootModel are disabled. The commands should work as there are a few users with that laptop.

Disabling SecureBootModel was the key (in addition to disabling SIP). All changes have been made...about to reboot system...fingers crossed.

% sudo mount -o nobrowse -t apfs /dev/disk3s7 ~/livemount

% sudo cp -r AppleACPIPlatform.kext ~/livemount/System/Library/Extensions
% sudo cp -r IOPCIFamily.kext ~/livemount/System/Library/Extensions
% sudo chmod -R 755 ~/livemount/System/Library/Extensions/AppleACPIPlatform.kext
% sudo chmod -R 755 ~/livemount/System/Library/Extensions/IOPCIFamily.kext     
% sudo chown -R 0:0 ~/livemount/System/Library/Extensions/AppleACPIPlatform.kext
% sudo chown -R 0:0 ~/livemount/System/Library/Extensions/IOPCIFamily.kext     

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

checking collections...
Warning: com.apple.driver.KextExcludeList was not found!
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>)
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.iokit.IOPCIFamily' found on disk at '/Users/casey/livemount/System/Library/Extensions/IOPCIFamily.kext' (mach-o UUID changed from 31170FF9-33B7-341F-865B-4E0D7872EF82 to 443464B5-0BF2-330A-B522-1311882EC0A6)
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.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.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.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)
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
%

 

[CaseySJ]

** Are You Ready for Some Good News? **​

Thanks to @ExtremeXT's suggestion to inject AppleACPIPlatform.kext and IOPCIFamily.kext from Big Sur into Monterey, we now have the following outcome -- all in Monterey 12.6. However, we need to run this Frankenstein system with SecureBootModel disabled.

What is Working:

• On-board Thunderbolt is working when devices are connected before boot. This did not work with standard versions of the two kexts.
• After installing a Fenvi FV-T919 into the second PCIe slot (x1), it is also working. Yes, PCIe devices appear to be working in Monterey!
• NVMe SSD is also working!
• Bluetooth is suddenly working.
• Intel i225-V also works; just need to set device-id to F3158680 in DeviceProperties.

Other Things Working in Monterey:

• Sleep, Wake
• Reboot, Shutdown
• App Store, Messages, TV App (DRM), Music App (DRM)

What is Partially Working:

• Intel i225-V is being recognized and driver is attached, but port does not connect. Maybe we need to inject Big Sur version of AppleIntel210Ethernet kext?
  • However, this may require AppleVTD so perhaps it's best to use a USB-to-2.5GbE adapter (which I have successfully tested just now).

What is Not Working:

• Bluetooth, however, is not working -- neither on-board Intel Bluetooth, nor Broadcom Bluetooth. Maybe we need to use Big Sur version of the Bluetooth family kext?
• Audio stuttering is the same as before. No change (as expected), but SpeedKeeper makes a huge improvement.

What to Test Next:

• I will test NVMe SSD shortly. It works!

 

[CaseySJ]

PCIe NVMe is working in Monterey...WD SN850.

 

[rhys]

@ExtremeXT
Good call!

 

[CaseySJ]

** Bluetooth is Suddenly Working in Monterey **

It may have happened after wake-from-sleep. Will test shortly.

Update: Bluetooth is working from a reboot.

 

[rhys]

** Bluetooth is Suddenly Working in Monterey **

It may have happened after wake-from-sleep. Will test shortly.

Update: Bluetooth is working from a reboot.

View attachment 7856

Oh wow!

Now just the dang audio!

 

[ovenlite1]

@CaseySJ, first off congratulations! I’ve been following this thread and so happy to see these developments.

Forgive me if this is ends up being a silly question, but stable audio seems to be evading us, both though onboard and usb dacs. I wonder though, since thunderbolt seems to be working, if a thunderbolt audio solution might work, such as the interfaces from the likes of Universal Audio? Since that’d be through pcie if I’m not mistaken.

Ultimately, that would still just a bandaid on the problem and definitely not an ideal or final solution- just curious if you or anyone think that might work! Also asking somewhat selfishly, since that would be my use case haha. Again, could be totally wrong on this, apologies if so!

 

[CaseySJ]

@CaseySJ, first off congratulations! I’ve been following this thread and so happy to see these developments.

Forgive me if this is ends up being a silly question, but stable audio seems to be evading us, both though onboard and usb dacs. I wonder though, since thunderbolt seems to be working, if a thunderbolt audio solution might work, such as the interfaces from the likes of Universal Audio? Since that’d be through pcie if I’m not mistaken.

Ultimately, that would still just a bandaid on the problem and definitely not an ideal or final solution- just curious if you or anyone think that might work! Also asking somewhat selfishly, since that would be my use case haha. Again, could be totally wrong on this, apologies if so!

Although I don't own a Thunderbolt Audio Interface, let me see what happens if I plug a USB DAC into a Thunderbolt dock. I don't think it will make a difference, but it needs to be empirically verified.

Update: No good. Stutter exists even through Thunderbolt dock. SpeedKeeper still makes a huge improvement.

Oh wow!

Now just the dang audio!

Yes, audio remains the principal thorn... If this is a TSC Sync issue, can it really be that difficult to resolve?#!

 

[twf36]

@CaseySJ Congratulations on getting the PCIE working!
Can you share your EFI? I'm trying to reproduce the fix for x670 StrixE, thanks!

 

[CaseySJ]

@CaseySJ Congratulations on getting the PCIE working!
Can you share your EFI? I'm trying to reproduce the fix for x670 StrixE, thanks!

The PCIe fix consists of these two parts:

• In OpenCore EFI we set:
  • SecureBootModel = Disabled
  • csr-active-config = FF0F0000 (SIP disabled)
• After installing Monterey, we hack it as follows:
  • Replace Monterey's copy of AppleACPIPlatform.kext and IOPCIFamily.kext with Big Sur's copy. Procedure is explained here.
  • From this point onwards we must continue to boot system with SecureBootModel disabled. This may prevent system upgrades...

Of course, this means we cannot use PCIe devices when installing Monterey. I am also concerned that after a macOS update (such as Monterey 12.6 to 12.6.1 or 12.7) we'll have to hack Monterey again.

My latest EFI -- for Asus Crosshair X670E Gene -- is attached. There are a number of experimental versions of ACPI and Kext files in this EFI. I hope nobody freaks out about them. The EFI is provided as-is. Also attached is a ZIP containing the two kexts from Big Sur.

Note About USB Port Map files:

• This EFI contains two sets of USB port map files:
  1. Two SSDTs used in combination with a Kext
  2. One single kext generated by USBToolBox in Windows
• Both options work, but:
  • Option 1 (two SSTDs and a Kext) works properly whether or not Thunderbolt is enabled in BIOS
  • Option 2 (from USBToolBox) only works when Thunderbolt is enabled; this may (or may not) be problematic when installing Monterey and Ventura because we need to disable Thunderbolt, in which case this USB map has no effect, and some devices such as Bluetooth will vanish

 

[ExtremeXT]

** Are You Ready for Some Good News? **​

Thanks to @ExtremeXT's suggestion to inject AppleACPIPlatform.kext and IOPCIFamily.kext from Big Sur into Monterey, we now have the following outcome -- all in Monterey 12.6. However, we need to run this Frankenstein system with SecureBootModel disabled.

What is Working:

• On-board Thunderbolt is working when devices are connected before boot. This did not work with standard versions of the two kexts.
• After installing a Fenvi FV-T919 into the second PCIe slot (x1), it is also working. Yes, PCIe devices appear to be working in Monterey!
• NVMe SSD is also working!
• Bluetooth is suddenly working.

Other Things Working in Monterey:

• Sleep, Wake
• Reboot, Shutdown
• App Store, Messages, TV App (DRM), Music App (DRM)

What is Partially Working:

• Intel i225-V is being recognized and driver is attached, but port does not connect. Maybe we need to inject Big Sur version of AppleIntel210Ethernet kext?
  • However, this may require AppleVTD so perhaps it's best to use a USB-to-2.5GbE adapter (which I have successfully tested just now).

What is Not Working:

• Bluetooth, however, is not working -- neither on-board Intel Bluetooth, nor Broadcom Bluetooth. Maybe we need to use Big Sur version of the Bluetooth family kext?
• Audio stuttering is the same as before. No change (as expected), but SpeedKeeper much a huge improvement.

What to Test Next:

• I will test NVMe SSD shortly. It works!

View attachment 7851 View attachment 7852

Finally PCIe is working! Can you install Monterey again and try to only replace IOPCIFamilly, and if it's not working try only replacing AppleACPIPlatform? The goal of this is to try making a kernel patch which would allow for full SIP and SecureBootModel support.

For the I225-V, AppleIntelEthernet210 might actually need VT-d on Monterey 12.3+, so roll-backing the Big Sur kext should work. This is an easy fix and I can most likely make a standalone kext that automatically replaces the old one if you send me both Big Sur's and Monterey's AppleIntelEthernet210 kext.

Could you also send an IOReg dump from the Frankenstein Monterey, a kernel log and a dmesg log?

 

[etorix]

Yes, audio remains the principal thorn... If this is a TSC Sync issue, can it really be that difficult to resolve?#!

If it is a TSC Sync issue it may require that the developers of TSC Sync or AMD Sync have a look at it—which would require they have the hardware.
But other observations suggest this is an issue with power states, explaining why SpeedKeeper helps.

Ultimately, that would still just a bandaid on the problem and definitely not an ideal or final solution- just curious if you or anyone think that might work! Also asking somewhat selfishly, since that would be my use case haha. Again, could be totally wrong on this, apologies if so!

We all hope it might work, but the issues are serious. Maybe they can be fixed, but this can take some time. And any solution involving new patches to the kernel and/or IOPCIFamily would come with risks with every OS update.
As attractive that Ryzen 7000 may look on paper, if you are in a hurry for a new build, the safe solution right now is to go with Intel—or a real AppleSillicon Mac.

 

[CaseySJ]

Finally PCIe is working! Can you install Monterey again and try to only replace IOPCIFamilly, and if it's not working try only replacing AppleACPIPlatform? The goal of this is to try making a kernel patch which would allow for full SIP and SecureBootModel support.

Certainly — will do this soon. Fortunately I made a full backup of Monterey before hacking it, so running these two experiments will be straightforward. A kernel patch is by far the better approach.

For the I225-V, AppleIntelEthernet210 might actually need VT-d on Monterey 12.3+, so roll-backing the Big Sur kext should work. This is an easy fix and I can most likely make a standalone kext that automatically replaces the old one if you send me both Big Sur's and Monterey's AppleIntelEthernet210 kext.

Could you also send an IOReg dump from the Frankenstein Monterey, a kernel log and a dmesg log?

Will do so shortly. It’s a bit past 2am (close to my usual wake-up time) so coffee is taking precedence over all else.

 

[CaseySJ]

@ExtremeXT,

Attached are:

• Zip file containing the full IONetworkingFamily kext from Big Sur and Monterey
  • The PlugIns folder inside each kext contains not only AppleIntelEthernet210, but AppleEthernetAquantiaAqtion as well
• IOReg from Frankenstein Monterey (IORegistryExplorer 3.0.2)
• dmesg dump from Frankenstein Monterey
• First 2000 lines of kernel log (if more lines are needed please let me know)

 

[ExtremeXT]

The IOReg and logs look fine. Hopefully IOPCIFamilly is the culprit, since both the Big Sur and Monterey versions are fully open source on Apple's website, which would make it a million times easier to debug.

 

[CaseySJ]

The IOReg and logs look fine. Hopefully IOPCIFamilly is the culprit, since both the Big Sur and Monterey versions are fully open source on Apple's website, which would make it a million times easier to debug.

The GitHub article states:

Replacing IOPCIFamily.kext and AppleACPIPlatform.kext with Big Sur's one. AppleACPIPlatform.kext requires the same version IOPCIFamily.kext, so both are needed to replace.

Does it still make sense to replace just IOPCIFamily?