Ryzen 7000 Testing

[CaseySJ]

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

It allows Ventura to boot with Thunderbolt enabled. This is something that could not be done with either of the two kernel patches.

Update: If Thunderbolt is enabled, we must provide a SSDT that defines NHI0

 

[CaseySJ]

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.

This may be a good challenge to take up next. The experience we gained from compiling and patching IOPCIFamily could be applied here. We know that I225-V works in Monterey if we use IOPCIFamily from Big Sur. So that is the motivation for finding a patch.

If we can get I225-V to work, the assumption is that Aquantia will work too, because the symptoms you described for Aquantia are the same as for I225-V.

 

[CaseySJ]

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

Yes that is another benefit of the boot argument. It will work with any version of macOS and also any mode (release mode, debug mode, development mode).

 

[ExtremeXT]

What's interesting is that MSI boards were able to run Monterey without any of this stuff before the AGESA update that added support for Zen 3 CPUs, maybe we could somehow fix the problem directly from the firmware without modifying macOS, might be a better solution if possible.

Yes that is another benefit of the boot argument. It will work with any version of macOS and also any mode (release mode, debug mode, development mode).

But doesn't it disable both ETFs even if one doesn't break anything?

@Shaneee What do you think, should the patches or the boot arg be used?

 

[Shaneee]

Given the fact that thunderbolt works with the boot arg and not with the patches I think it would be better to use the boot arg. I’ll update the repo etc later of to update users on this.

 

[ExtremeXT]

Now that this problem is solved, I'll try making a good MmioWhitelist guide and PRing it to Dortania, to make it easily available to users.

 

[CaseySJ]

What's interesting is that MSI boards were able to run Monterey without any of this stuff before the AGESA update that added support for Zen 3 CPUs, maybe we could somehow fix the problem directly from the firmware without modifying macOS, might be a better solution if possible.

Because we have source code for macOS, it gave us a huge gigantic advantage in figuring this out…

But doesn't it disable both ETFs even if one doesn't break anything?
…

Exactly my concern as well. I don’t know what the two custom ETFs are responsible for, hence I’ll try patch 3, which is to disable the inner if-condition only, without sacrificing extendedDeviceCaps2.

 

[CaseySJ]

Now that this problem is solved, I'll try making a good MmioWhitelist guide and PRing it to Dortania, to make it easily available to users.

That would be very welcome — MMIO is still a new topic for me.

 

[mariettosun]

That would be very welcome — MMIO is still a new topic for me.

if you have some time...

Let talk about...Devirtualise MMIO quirk and MMIO Whitelist!

In this thread we will try to explain the function of this very interesting quirk and above all of the related section of MMIO Whitelist which is even more fundamental for different systems. The topic has been recently documented in a more exhaustive way in the OpenCore configuration pdf, but now...

www.macos86.it

and this one from @iGPU

[Discussion] - TRX40 Bare Metal - Vanilla Patches

www.macos86.it

and this from opencore devs done some years ago!

OpenCore General Discussion

www.insanelymac.com

 

[CaseySJ]

if you have some time...

Let talk about...Devirtualise MMIO quirk and MMIO Whitelist!

In this thread we will try to explain the function of this very interesting quirk and above all of the related section of MMIO Whitelist which is even more fundamental for different systems. The topic has been recently documented in a more exhaustive way in the OpenCore configuration pdf, but now...

www.macos86.it

and this one from @iGPU

[Discussion] - TRX40 Bare Metal - Vanilla Patches

www.macos86.it

and this from opencore devs done some years ago!

OpenCore General Discussion

www.insanelymac.com

Awesome — will take a look.

 

[CaseySJ]

** Enabling Intel I225-V in Monterey **

To enable I225-V in Monterey, we just need to add boot argument e1000=0

​

Details:

• Boot argument e1000=0 is sufficient to enable I225-V in Monterey (no device properties for I225-V should be injected)
• This causes AppleIntelI210Ethernet driver to attach instead of the newer DriverKit-AppleEthernetE1000.dext

This is being posted from vanilla Monterey on AM5 (Ryzen 7 7700X) with WiFi disabled and I225-V connected, to prove that all I/O is occurring through the wired Ethernet port

​

 

[ExtremeXT]

** Kernel Patch for Intel I225-V in Monterey **

IGNORE EVERYTHING BELOW THE LINE

To enable I225-V in Monterey, we just need to insert device-id F3158680 and no kernel patch
There are no issues (yet) with this method
​

Device Property:

• device-id F3158680
• This property causes AppleIntelI210Ethernet driver to attach instead of the newer DriverKit

This is being posted from vanilla Monterey on AM5 (Ryzen 7 7700X) with WiFi disabled and I225-V connected, to prove that all I/O is occurring through the wired Ethernet port

View attachment 8242​

---

Warning:
Just found an issue with this patch -- if any network device is turned off and then turned on,
it will cause user interface to crawl until Ethernet cable is removed​

Purpose:

• On AMD Ryzen systems running Monterey, the native Intel I225-V driver causes the system to crash when an Ethernet cable is connected
• This patch solves that problem, but it requires a Device Property to be injected
• Therefore, there are two parts to this solution
  • Apply the kernel patch below
  • Apply the device property below

Kernel Patch:

• Arch: x86_64
• Identifier: com.apple.iokit.IOPCIFamily
• Comment: CaseySJ - Fix Ethernet
• Find: 488B4060 81782C00 000200
• Replace: 488B4060 81782CCC CC0C00
• Min Kernel: 21.0.0
• Max Kernel: 21.99.99
• Count: 1
• Enabled: True

What exactly do you mean by "it will cause user interface to crawl until Ethernet cable is removed"?

Also, try spoofing device-id to F3150000, 8086 is the vendor-id and shouldn't be in the device-id. But AFAIK the KEXT already supports the native device-id (F215), so you should be able to just add e1000=0 to boot-args to disable the DEXT.

 

[CaseySJ]

What exactly do you mean by "it will cause user interface to crawl until Ethernet cable is removed"?

I performed these steps with the kernel patch:

• WiFi enabled by default on system boot
• Ethernet cable disconnected on system boot
• When system fully booted, I inserted Ethernet cable
• After a few seconds, Ethernet port connected and received valid IP address from DHCP
• I disabled WiFi to make sure Ethernet port was working
• WiFi was disabled with no issue
• Ethernet port worked properly
• Then I re-enabled WiFi
• At this point it seemed as if the system hanged because the mouse pointer would not appear to move -- but it moved once every 5 seconds
  • Hence, "user interface crawled"
• Without rebooting the system, I just removed the Ethernet cable
• Immediately the system came back to normal operation

But without the kernel patch (i.e. with device property only), everything works fine.

However, this device property method does not work in Ventura. So I'm trying some experiments there.

 

[ExtremeXT]

I performed these steps with the kernel patch:

• WiFi enabled by default on system boot
• Ethernet cable disconnected on system boot
• When system fully booted, I inserted Ethernet cable
• After a few seconds, Ethernet port connected and received valid IP address from DHCP
• I disabled WiFi to make sure Ethernet port was working
• WiFi was disabled with no issue
• Ethernet port worked properly
• Then I re-enabled WiFi
• At this point it seemed as if the system hanged because the mouse pointer would not appear to move -- but it moved once every 5 seconds
  • Hence, "user interface crawled"
• Without rebooting the system, I just removed the Ethernet cable
• Immediately the system came back to normal operation

But without the kernel patch (i.e. with device property only), everything works fine.

However, this device property method does not work in Ventura. So I'm trying some experiments there.

The KEXT got removed in Ventura, that's probably why it doesn't work, it has to be injected with OpenCore. Try without any DeviceProperties but e1000=0 and the KEXT should attach just fine.

If it works without the kernel patch, why not remove it?

 

[CaseySJ]

...

Also, try spoofing device-id to F3150000, 8086 is the vendor-id and shouldn't be in the device-id. But AFAIK the KEXT already supports the native device-id (F215), so you should be able to just add e1000=0 to boot-args to disable the DEXT.

Native device ID is 0x15F3

Monterey:

• device-id 53150000 causes system to hang in the final stage of boot
• e1000=0 works the same as device-id F3158680, and I agree that boot argument is preferred over Device Property
  • Device Property requires the specific PCI path of each board's i225-V controller
  • boot argument works the same for everyone

Ventura:

• e1000=0 (and no device properties) causes System Information to report:

• Let me see what the kernel patch does in Ventura...

 

[ExtremeXT]

Native device ID is 0x15F3

Monterey:

• device-id 53150000 causes system to hang in the final stage of boot
• e1000=0 works the same as device-id F3158680, and I agree that boot argument is preferred over Device Property
  • Device Property requires the specific PCI path of each board's i225-V controller
  • boot argument works the same for everyone

Ventura:

• e1000=0 (and no device properties) causes System Information to report:

View attachment 8244

• Let me see what the kernel patch does in Ventura...

Did you inject AppleIntelI210Ethernet?

 

[CaseySJ]

** One Brief Update Regarding Kernel Patches for Ventura **
​

• I mentioned previously that my kernel patches for Ventura were not compatible with Thunderbolt
• I also mentioned that boot argument pci=0x8000000 is compatible with PCI and Thunderbolt

As it turns out, neither of those statements is strictly true:

• If Thunderbolt is enabled, Ventura will not boot regardless of patch or boot argument unless there is a Thunderbolt SSDT that defines NHI0

Therefore:

• Ventura will boot and work properly with either or both of my kernel patches
• Ventura will also boot and work properly with just pci=0x8000000
• But if Thunderbolt is enabled, we must provide a SSDT that defines NHI0 (Native Host Interface)

 

[ExtremeXT]

@CaseySJ
I just updated my BIOS and was re-doing my settings when I came across this value (see attached image). Could you see if Ventura boots with this set to Enabled and without any patch/boot arg? (if you can find that option, of course, it was until AMD CBS for me)

 

[CaseySJ]

@CaseySJ
I just updated my BIOS and was re-doing my settings when I came across this value (see attached image). Could you see if Ventura boots with this set to Enabled and without any patch/boot arg? (if you can find that option, of course, it was until AMD CBS for me)

Wow, 10b ETF support directly toggle-able in BIOS!!

Can someone with a Gigabyte X670 board check for this?

I do not see this in the Asus BIOS, but now I'm tempted to ask Asus for it. I'll also install BIOS 0805 shortly and check there.

 

[ExtremeXT]

After setting the option to Enabled my AM4 machine has the same symptoms! If NVMe is enabled, it panics, and if I disable it with the nvme=-1 boot argument, there are no active PCIe devices except the GPU in IOReg! This leads me to believe that some motherboards (MSI, AM5) wrongly enable this option when the hardware doesn't support it.