Gigabyte Z690 Aero G + i5-12600K + AMD RX 6800 XT

[fvklies]

@CaseySJ 's SSDT does activate all USB ports but in its present form needs USBInjectAll.kext.

With those two points in mind enabling the XhciPortLimit quirk needs explaining...

I've read it isn't necessary since MacOS 11.3. My rear usb 2.0 ports are not working, and I wonder if having XhciPortLimit set to true is the issue. I suppose I could test it without it being enabled but don't want to brick anything.

 

[UtterDisbelief]

I've read it isn't necessary since MacOS 11.3. My rear usb 2.0 ports are not working, and I wonder if having XhciPortLimit set to true is the issue. I suppose I could test it without it being enabled but don't want to brick anything.

Understood. Always wise to be cautious.

If you are just running the SSDT-UIAC-Z690-AERO-G-ALL-PORTS-HS14.aml it will enable both USB2 and USB3 ports (HS** and SS**). It is actually working as a configuration file for USBInjectAll.kext, and clearing the XhciPortLimit quirk should not "brick" anything, no matter which version macOS is being used.

To be really careful you should partition and format a new USB stick to GUID and copy the OpenCore setup into the EFI partition - with your changes - and test that as a boot medium. That way you are not touching the main disk if anything doesn't work out.

 

[fvklies]

To be really careful you should partition and format a new USB stick to GUID and copy the OpenCore setup into the EFI partition - with your changes - and test that as a boot medium. That way you are not touching the main disk if anything doesn't work out.

I read the OpenCore upgrade guide, and it's not specifically stated on what to do with the test USB. In this case, would I boot to the test USB by select F12 upon the BIOS screen?

 

[CaseySJ]

I read the OpenCore upgrade guide, and it's not specifically stated on what to do with the test USB. In this case, would I boot to the test USB by select F12 upon the BIOS screen?

I'll test this in 5 minutes.

Update:

• Even with USBInjectAll.kext and a companion SSDT that defines more than 15 ports, it is in fact necessary to enable Kernel quirk XhciPortLimit.
• To verify this, disabling the quirk stopped the list at 15 ports:

 

[fvklies]

I'll test this in 5 minutes.

Update:

• Even with USBInjectAll.kext and a companion SSDT that defines more than 15 ports, it is in fact necessary to enable Kernel quirk XhciPortLimit.
• To verify this, disabling the quirk stopped the list at 15 ports:

Thanks for testing.

 

[UtterDisbelief]

I'll test this in 5 minutes.

Update:

• Even with USBInjectAll.kext and a companion SSDT that defines more than 15 ports, it is in fact necessary to enable Kernel quirk XhciPortLimit.
• To verify this, disabling the quirk stopped the list at 15 ports:

View attachment 539462

Forgive me for commenting on this ... I do not doubt your test is valid, nor that your work is exemplary ...

But, that's just plain crazy. A code injection (quirk) designed to open up the ports, along with an SSDT that defines 22x ports, limits the number to 15. Whereas, when working properly, the quirk needs to be disabled for that to happen.

I can only conclude that this is a "bug".

If it had a logic to it, I'd understand and say so. But when things work counter-intuitively to the way they are meant to, I wouldn't go that route for fear of other, unseen, effects.

 

[etorix]

But, that's just plain crazy. A code injection (quirk) designed to open up the ports, along with an SSDT that defines 22x ports, limits the number to 15. Whereas, when working properly, the quirk needs to be disabled for that to happen.

No: Not enabling the quirk limits the ports to 15; enabling the quirk allows all ports in the SSDT.
The surprising part is that the SSDT should suffice in itself, but the quirk, somehow, still works as expected and removes the limit.

If it had a logic to it, I'd understand and say so. But when things work counter-intuitively to the way they are meant to, I wouldn't go that route for fear of other, unseen, effects.

The purpose is to end up with a USB map within the limit of 15 ports per controller, no quirk and no further USBInjectAll.kext or SSDT, so there should be no unexpected effect in the final configuration.

 

[UtterDisbelief]

No: Not enabling the quirk limits the ports to 15; enabling the quirk allows all ports in the SSDT.

This is where the bug lies. You should not need a port limit removal patch to enable more than 15-ports with an SSDT in place.

In fact it would be much safer to patch the DSDT directly and do without any kexts or quirks, but no-one wants to put in the effort needed.

Also I totally disagree with all this 15-ports per controller malarky. Always have. Please show me a genuine Apple Intel Mac that ever used more than one controller? Don't say EHCI is two (6+8). I do not mean add-on cards, I do not mean Thunderbolt. I mean built-in straight from the factory for USB. There simply is no array set aside that is big enough, though many argue this doesn't matter.

The purpose is to end up with a USB map within the limit of 15 ports per controller, no quirk and no further USBInjectAll.kext or SSDT, so there should be no unexpected effect in the final configuration.

Yes, I agree this is a desired goal. But this EFI does not do that. It uses a kext, an SSDT and a quirk.

Thanks.

 

[MatiCohen]

It would be insightful to post a screenshot of IORegistryExplorer showing the device ID of the card/module.

I use a Fenvi BCM94360NG in my AMD Ryzen B550 build. That one works like a champ with and without BRCM kexts.

This Screenshot is with BlueToolFixup enabled. Thanks!

 

[ReferButtermilk]

The Gigabyte BIOS currently has issues with USB 2.0 device connection on 2 or 3 ports (HS01, HS03, and HS05). I say "2 or 3" because some users have issues with 2 ports while I have issues with all 3.

The Asus Z690 ProArt Creator WiFi is more expensive and requires (expensive) DDR5 memory, but I've already created a fully-functional Hackintosh with it. It does limit us to 15 USB ports, however. Enabling more than 15 ports can lead to USB 2.0 device issues. Perhaps a future version of "XhciPortLimit" quirk can fix this??

I can still recommend both of these boards:

• DDR4 memory --> Gigabyte Z690 Aero G
• DDR5 memory --> Asus Z690 ProArt Creator WiFi

I appreciate that info. I'm not bothered about DDR5 at all, and I'm kind of doing this build for fun rather than having an actual reason to do so. Seems like the Aero G would be perfect - thank you.