Z490 & Z590 - Will Z590 ever have macOS Support ?

[ori69]

@ori69
Thanks for testing this patch !

I can see that PID patching is properly done, on your PCI files, new PID from Ice Lake is included :

View attachment 530766

In order to see if NHI driver match with device, Could you send me your IOReg file from IORegistryExplorer ?

 

[dehjomz]

@CaseySJ @ori69 @JoanSilva17

Opencore Kernel/Drivers patching seem to not properly work because when I patch other part related to Alpine/Titan Ridge like this :
0x15008086&0xff00ffff to 0x11008086&0xff00ffff

NHI drivers still load and matching value doesn't change !

Well, I still have another method ! This one has been done on my laptop with Alpine Ridge (0x15d2) NHI.

As matching is done with PID, I have changed it by Opencore device properties like this :
View attachment 530756
This is for my thunderbolt device on RP21 @1B,4 (for RP05 change it to 0x1C,0x04).

And after reboot, I have NHI0 subtree changed to AppleThunderboltHALType4 :
View attachment 530757

and few moment later ...

View attachment 530758

View attachment 530759

Well, now we can try this PID device patching :

Config.plist > DevicesProperties > New device (+):
Devices : PciRoot(0x0)/Pci(0x1C,0x4)/Pci(0x0,0x0)/Pci(0x0,0x0)/Pci(0x0,0x0)
Key: device-id
Value: 178A0000
Type: DATA

Unfortunately, for full thunderbolt tree, I think we still need thunderbolt firmware patching/flashing like on my laptop.

Hello there!

Your device-id trick works for device PCI8086,15D2 (Titan Ridge?) but not for device PCI8086,1137 (Maple Ridge).

With device-id 8A17, no dice: I wonder if there's code in the kext itself that probes the thunderbolt chip itself to decide whether or not to load and attach.

I remember when Big Sur beta first came out, I was trying to do this device-id trick to force AppleEthernetAquantiaAqtion107 to load in Big Sur (it used to load with no problems in Catalina for my internal Aquantia device). But this trick didn't work. We had to patch the kext itself to bypass certain checks (in Big Sur and now Monterey) to allow it to load.

 

[Elias64Fr]

@ori69,

Very strange, despite of patching properly done and can be seen on your PCI files, "device-id" stay on native value (0x1137) on your IOReg file :

Is that an updated file ? ... date/hour show me 18/07/2024 @ 20:18

 

[Elias64Fr]

Hello there!

Your device-id trick works for device PCI8086,15D2 (Titan Ridge?) but not for device PCI8086,1137 (Maple Ridge).

With device-id 8A17, no dice: I wonder if there's code in the kext itself that probes the thunderbolt chip itself to decide whether or not to load and attach.

I remember when Big Sur beta first came out, I was trying to do this device-id trick to force AppleEthernetAquantiaAqtion107 to load in Big Sur (it used to load with no problems in Catalina for my internal Aquantia device). But this trick didn't work. We had to patch the kext itself to bypass certain checks (in Big Sur and now Monterey) to allow it to load.

View attachment 530770

Hi @dehjomz

My laptop has an onboard Alpine Ridge, and it seem that NHI driver drive both Alpine/Titan and other ARM M1 variant. With Maple Ridge, we hope that configuration registers are same as previous thunderbolt device like Titan ridge.
For exemple, on MacBookPro16,2, with onboard Ice Lake, NHI tree is very similar (properties like ThunderboltDROM, number of ThunderboltPort,...):

To make sure, we just have to experiment and test features !

You can also try with device-id EB150000 instead of 178A0000

 

[Elias64Fr]

Hello there!

Your device-id trick works for device PCI8086,15D2 (Titan Ridge?) but not for device PCI8086,1137 (Maple Ridge).

With device-id 8A17, no dice: I wonder if there's code in the kext itself that probes the thunderbolt chip itself to decide whether or not to load and attach.

I remember when Big Sur beta first came out, I was trying to do this device-id trick to force AppleEthernetAquantiaAqtion107 to load in Big Sur (it used to load with no problems in Catalina for my internal Aquantia device). But this trick didn't work. We had to patch the kext itself to bypass certain checks (in Big Sur and now Monterey) to allow it to load.

View attachment 530770

I note that matching is done with PID (already patched) and ... PCIClass

On Maple ridge, we have PCIClass code to 40030C00 (0x000C0340).
Matching data for Titan/Alpine/ is 0x08800000&0xffff0000 we should change it to 00800800 (0x00088000).

We should add another property on NHI0 device:

Config.plist > DevicesProperties:
Devices : PciRoot(0x0)/Pci(0x1C,0x4)/Pci(0x0,0x0)/Pci(0x0,0x0)/Pci(0x0,0x0)
Key: class-code
Value: 00800800
Type: DATA

 

[ori69]

@ori69,

Very strange, despite of patching properly done and can be seen on your PCI files, "device-id" stay on native value (0x1137) on your IOReg file :

View attachment 530777

Is that an updated file ? ... date/hour show me 18/07/2024 @ 20:18
View attachment 530778

I took the battery out of the motherboard and I don't have internet connected, that's why this is the date. File generate an hour ago.

 

[dehjomz]

I note that matching is done with PID (already patched) and ... PCIClass

View attachment 530783

On Maple ridge, we have PCIClass code to 40030C00 (0x000C0340).
Matching data for Titan/Alpine/ is 0x08800000&0xffff0000 we should change it to 00800800 (0x00088000).

We should add another property on NHI0 device:

Config.plist > DevicesProperties:
Devices : PciRoot(0x0)/Pci(0x1C,0x4)/Pci(0x0,0x0)/Pci(0x0,0x0)/Pci(0x0,0x0)
Key: class-code
Value: 00800800
Type: DATA

Hello there, again! You are a master.

With the class-code property added, AppleThunderboltHALType4 attaches.

Unfortunately, with AppleThunderboltHALType4, the Thunderbolt bus goes down upon S3 sleep, and it doesn't come back. And since I am booting from a NVME disk in a Thunderbolt enclosure, a dead bus not coming back means the system hangs. So this is a no go for me. Perhaps the Thunderbolt-hotplug SSDT needs updated properties to work with AppleThunderboltHALType4? Speaking of hot plug, it's still not working on the Z590 Vision D in macOS. The same devices hot plug properly however in Windows/Linux. Regular USB-C devices hot plug however, not a problem at all.

I wonder if anything is missing from the TB hot plug SSDT or my system DSDT regarding Thunderbolt hot plug. Perhaps the way Linux/Windows handle Thunderbolt 4 hotplug events is different than how macOS handles it? Or maybe the Z590 Vision D is missing ACPI code (that exists in Asus/MSI z590) for hot plug events...? Hot plug code seems to be called when macOS resumes from S3 sleep on the Z590 Vision D however.

Anyways, we are making progress.

 

[Elias64Fr]

Hello there, again! You are a master.

With the class-code property added, AppleThunderboltHALType4 attaches.

Unfortunately, with AppleThunderboltHALType4, the thunderbolt bus goes down upon S3 sleep, and it doesn't come back. And since I am booting from a NVME disk in a thunderbolt enclosure, a dead bus not coming back means the system hangs. So this is a no go for me. Perhaps the thunderbolt-hotplug SSDT needs updated properties to work with AppleThunderboltHALType4? Speaking of hotplug, it's still not working on the Z590 Vision D in macOS. The same devices hotplug properly however in Windows/Linux. Regular USB-C devices hotplug however, not a problem at all.

I wonder if anything is missing from the TB hotplug SSDT or my system DSDT regarding thunderbolt hotplug. Perhaps the way Linux/Windows handle Thunderbolt4 hotplug events is different than how macOS handles it? Or maybe the Z590 Vision D is missing ACPI code (that exists in Asus/MSI z590) for hotplug events...? Hotplug code seems to be called when macOS resumes from S3 sleep on the Z590 Vision D however.

Anyways, we are making progress.

View attachment 530803

Great !

About hot plug, I think configuration is included on Thunderbolt firmware. I remember that on previous device like Titan Ridge, when I tried to change Power Delivery firmware part, I lose hot plug... Maybe configuration is common to Thunderbolt device part matching with PD part ?! This is purely speculation.
We can verify, by pictures, if PD components (like TPS65983 on Titan Ridge card) are the same on GB/ASUS/MSI, then we can try flashing Thunderbolt firmware with a ASUS or MSI TB firmware...

Now, with Z590 Vision D, we have a loaded NHI driver, we can try a modified firmware (after extracting this one) to unlock Apple framework configuration byte and some other. I think @CaseySJ submitted one !

 

[buddyjack2]

I frankly only have a vague idea what you guys are attempting but since @CaseySJ helped me out in getting my Thunderbolt external drive recognized awhile back, I'm willing to try (with some trepidation, LOL) if you think I could contribute something here. BTW, my external drive is only an old TB2 using an adapter (TB2 to Type-C connector) plugged into one of my mobo's two TB4 ports. I haven't yet done any of the config.plist/SSDT changes you've been discussing; attached is a screenshot from IORegExplorer of what (I think) is the relevant section you're investigating.

 

[CaseySJ]

Great !

About Hotplug, I think configuration is included on thunderbolt firmware. I remember that on previous device like Titan ridge, when I tried to change Power Delivery firmware part, I lose hotplug... Maybe configuration is common to thunderbolt device part matching with PD part ?! This is purely speculation.
We can verify, by pictures, if PD components (like TPS65983 on Titan ridge card) are the same on GB/ASUS/MSI, then we can try flashing Thunderbolt firmware with a ASUS or MSI TB firmware...

Now, with Z590 Vision D, we have a loaded NHI driver, we can try a modified firmware (after extracting this one) to unlock Apple framework configuration byte and some other. I think @CaseySJ submitted one !

Ah, unfortunately Maple Ridge does not have its own Flash ROM firmware chip! We can use Linux to extract the firmware, but we won't be able to modify it with an SPI Flash ROM reader/writer.