Contribute
Register

A Beginner's Guide to Creating a Custom USB SSDT

Thanks UtterDisbelief for your dedication mate, I really appreciate your help.
I tried to disable them all, no luck, still one controller visible..

Okay, but I am sorry, back in post #457 you had both controllers finally working. That means something you have done since has broken USB again.

You should perhaps go back and check what you have done since. I can't see that from here, sadly, and am working in the dark.
 
Hi there. I'll try to clear away the confusion ...

Those ACPI patches you are using were from a 2014 build.


Okay, but I am sorry, back in post #457 you had both controllers finally working. That means something you have done since has broken USB again.

You should perhaps go back and check what you have done since. I can't see that from here, sadly, and am working in the dark.

As said the controller appears only while using the pre-compiled 2014 SSDT I found online in the mentioned thread.
Apparently is the only way to bring up the second controller.
 
I really hope others with more expertise than me chime in soon. But perhaps something will jump out and lead you to the right file..

Only things I can think of:

see my file below

-I didn't change the definition block, yours looks a bit different, perhaps a different template.¯\_(ツ)_/¯
-This part here ""8086_a12f", Package()" I picked based on the device id for the root XHC device in my case. I guess for you it would be root EH (in IOREG)
-I left the "port-count", Buffer() { 26, 0, 0, 0 }, even though I only have <= 15 total ports
-I assume your .dsl compiled into an .aml without errors?

Only things I can think of atm...

Thank you so much again for the help! What template did you use? I used the one in this Beginners Guide. So for the "Package()" section, would the attached location be where I pull my device-id from?
And yes, no errors were found.
 

Attachments

  • Screen Shot 2019-10-20 at 7.17.41 AM.png
    Screen Shot 2019-10-20 at 7.17.41 AM.png
    284.4 KB · Views: 49
I really hope others with more expertise than me chime in soon. But perhaps something will jump out and lead you to the right file..
Dude... I think it works now! I changed my limit to 26 like yours and changed the "Package()" to a different ID and bam! Things seem to be working. Attached is my IO Registry screen grabs. Does everything look right? Not sure how to fully tell if this patch is working...
 

Attachments

  • Screen Shot 2019-10-20 at 7.33.04 AM.png
    Screen Shot 2019-10-20 at 7.33.04 AM.png
    82.7 KB · Views: 55
  • Screen Shot 2019-10-20 at 7.32.17 AM.png
    Screen Shot 2019-10-20 at 7.32.17 AM.png
    55.5 KB · Views: 62
As said the controller appears only while using the pre-compiled 2014 SSDT I found online in the mentioned thread.
Apparently is the only way to bring up the second controller.

Hi there,

No, in post #455 you said you were having problems compiling your own USB SSDT because there was only one controller. In post #457 you said you had finally succeeded. No mention of getting one online from another user that I can see. (Except those other 8 or 9 miscellaneous ssdts).

I can see from your IOReg output that both controllers are present, but there are no ports attached to EH02.

You also have GenericUSBXHCI installed which has at least attached itself to the USB3 ports.

Post #463 was the last time we saw an EFI folder and there was no USB patch in the "patched" folder.

Maybe post the USB SSDT aml file for checking?
 
Last edited:
Is anyone working on a "repo" for working USB maps? It takes away from the learning experience for sure but would be quite simple and fast. I mapped out my Asus Prime Z370 a (hopefully it works on the rev 2) and never looked back.
 
Is anyone working on a "repo" for working USB maps? It takes away from the learning experience for sure but would be quite simple and fast. I mapped out my Asus Prime Z370 a (hopefully it works on the rev 2) and never looked back.

It's a good idea, and to answer your question briefly some work has been done.

The main stumbling-block seems to be that folk choose to configure their ports, their way. For example which internal header is used for Bluetooth. Or which connectors they sacrifice to get down to the 15-port limit.

For each one there would have to be a mini-guide. Which is fair enough. But it's a lot of work. And you might end up with - again for example - 10x different Z390 Aorus Pro layouts, each tailored to that one user's needs.

I agree though, like the old DSDT database, it would be very useful if it can realistically be made to work, but there could be problems in the future with the big changes being made to kernel security in macOS.

:)
 
Attached is the file detected by IORegistryExplorer. Can someone help me identify the abbreviations to watch?

Hello there.

It depends on why you are asking?

Because this is a USB thread, it looks as though:

1) you have both the EHCI and XHCI controllers active.

2) your motherboard has just 4x USB3.0 ports and 6x USB2.0 ports controlled by your Z97 chipset. This equates to 14-ports (4x2 + 6) that need configuring and below the 15-port limit.

3) No need for FakePCIID_XHCIMux.kext.

4) Your 'piggy-back' Renesas 3rd-party USB 3.0 ports do not form a part of the 15-limit and do not always need to be configured. A few years ago a kext was produced that did this, called GenericUSBXHCI.kext. However it might not work with macOS Catalina. There were problems with Mojave and High sierra too. The kext was written in 2015.

:)
 
It's a good idea, and to answer your question briefly some work has been done.

The main stumbling-block seems to be that folk choose to configure their ports, their way. For example which internal header is used for Bluetooth. Or which connectors they sacrifice to get down to the 15-port limit.

For each one there would have to be a mini-guide. Which is fair enough. But it's a lot of work. And you might end up with - again for example - 10x different Z390 Aorus Pro layouts, each tailored to that one user's needs.

I agree though, like the old DSDT database, it would be very useful if it can realistically be made to work, but there could be problems in the future with the big changes being made to kernel security in macOS.

:)

Great point!

It would be easy to make adjustments I guess. Well, I have an Asus Prime Z370a for anyone who needs it!
 
Back
Top