Contribute
Register

ASUS 100 Series and Later Custom SSDT for XHCI USB Port Control

No success here. I have attached screenshots of 1) my "original" (RehabMan's) IORegistryExplorer result using USBInjectALL.kext, 2) a corresponding result using the current (MacMan's/Lauderdale's) process, and 3) a PlistEditPro result of adding "Automerge" to the ACPI portion of config.plist. I have noted the following weirdnesses:
1. The USB ports shown in the current IORegistryExplorer have reverted to the original DSDT assignments.
2. Whenever I generate a disassembled SSDT ".dsl" file from my compiled ".aml" file, the "Definition Block" (which was "SSDT-5" in my original ".dsl" file) has changed to "", as if I had never added it. This is repeatable forever. Consequently I believe my ".aml" file in my ACPI/patched folder in CLOVER is missing that Definition Block designator.

Please note that in your response to a poster above you mentioned that the "PLD" entries in the SSDT for the undesired ports needed to be set to "Zero," but in your illustration in your previous post to me you show only the "UPC" entries changed to "Zero." Do the "PLD" entries have to be changed also? (See also the attached .jpg file showing one example of an undesired port.)
 

Attachments

  • USB Ports Issue.zip
    302.4 KB · Views: 89
  • Undesired USB Port HS04.jpg.zip
    62.9 KB · Views: 79
Last edited:
No success here. I have attached screenshots of 1) my "original" (RehabMan's) IORegistryExplorer result using USBInjectALL.kext,

The definition block seems to not save after compilation/de-compile from .aml. Don't worry about it. My thought is that it's either a compiler issue or a compiler directive and should not affect the outcome. Just ensure the definition block is populated as discussed before you compile.

Based on your IORegistryExplorer snip, the ports you want enabled are contained in the attached modified SSDT-5.dsl which I pulled from your original post once clover extracted it for you (a few posts back). I took the liberty of modifying that file on your behalf (can't do this for everyone, but as an example only for others to learn from). Search within the file for the text "// MODIFIED" and you will see 9 edits marking ports as Zero to disable. This file should now mirror the IORegistryExplorer snip. It is impossible to edit the SSDT file without knowing exactly which ports need to be turned off; the port experimentation exercise is mandatory regardless of the method (this way or RehabMan's way).

You should ensure the SSDT from RehabMan's suggestion is not contained in the patched directory. Compile the attached with RehabMan's MaciASL version (take the latest).
ACPI 6.2a must be set in preferences/iASL. Then compile the .dsl to .aml (save as and select the file type as ACPI Machine Language Binary
Place the compiled version (.aml) file in the patched directory. Ensure the 15 port limit patch limit and USBInjectAll KEXT are disabled in config.plist (disabled in clover configuator with the check box as previously discussed).

The other post 35 are apples and oranges in terms of DSDT. That post uses a "Data Dictionary" type "Name" table making the configuration simple by changing just the values within the tables (no direct edits required except for the two Name tables). What you and I have do not use a data dictionary and require the manual edits. Please do not confuse the two.

I also got to the bottom of the black screen mystery. It appears that when you have more than one Clover EFI partition, like we both do, then the black screen problem occurs. I proved that by turning off the other two drives in my system that have Clover EFI partitions, booted, then pressed F4 and had no problems; worked as expected and wanted to pass that along.

Give the attached a go.
 

Attachments

  • SSDT-5.dsl
    59.7 KB · Views: 90
The definition block seems to not save after compilation/de-compile from .aml. Don't worry about it.
Thank you, that is comforting.

Search within the file for the text "// MODIFIED" and you will see 9 edits marking ports as Zero to disable. This file should now mirror the IORegistryExplorer snip.
Thanks for your effort. I used "MaciASL" to do an A-B comparison between your "MODIFIED" SSDT-5 and the one I made. They match exactly. Apparently I didn't miss anything.

It is impossible to edit the SSDT file without knowing exactly which ports need to be turned off; the port experimentation exercise is mandatory regardless of the method (this way or RehabMan's way).
Yes, I know that. As I wrote, your "MODIFIED" version of the SSDT-5 is an exact match with mine. And the ports I have "dropped" are the same ones I previously dropped using RehabMan's guide. So the current IORegistryExplorer readout (that I attached in my post #36 above) from after I used this new procedure should have matched what I had using RehabMan's procedure, but it doesn't. Something else is wrong.

You should ensure the SSDT from RehabMan's suggestion is not contained in the patched directory. Compile the attached with RehabMan's MaciASL version (take the latest).
I had removed my previous SSDT from ACPI/patched before adding in my SSDT-5 file. I have used Rehabman's version RM-1.31 (252.3) for all my work up until now. I just downloaded version RM-1.31 (252.4) from your link. If you think that might make a difference, I can repeat everything with that one.

Place the compiled version (.aml) file in the patched directory. Ensure the 15 port limit patch limit and USBInjectAll KEXT are disabled in config.plist (disabled in clover configuator with the check box as previously discussed).
Yes, did that. I presume you refer to the patch that removed the 15-port limit in config.pist; I had removed that after using RehabMan's procedure, and it hasn't been present for months. But the "USBInjectAll.kext" files are in separate folders in CLOVER called "kexts/10.13" and also "kexts/other" from which I removed them. As far as I know there is no such "check box" in Clover Configurator... at least I could not find one.

The other post 35 are apples and oranges in terms of DSDT. That post uses a "Data Dictionary" type "Name" table making the configuration simple by changing just the values within the tables (no direct edits required except for the two Name tables). What you and I have do not use a data dictionary and require the manual edits. Please do not confuse the two.
Understood, thank you. But since things are still not working, what is your answer to the question I posed in my uploaded (port #36) "Undesired USB Port HS04.jpg" file? Should that "One" be changed to a "Zero" for all the undesired USB ports? Or left alone?

I also got to the bottom of the black screen mystery. It appears that when you have more than one Clover EFI partition, like we both do, then the black screen problem occurs. I proved that by turning off the other two drives in my system that have Clover EFI partitions, booted, then pressed F4 and had no problems; worked as expected and wanted to pass that along.
Okay, thanks for that.

As far as I can tell I have complied with all the procedure requirements, but still IORegistryExplorer is wrong. Any further suggestions?

Edit: Sorry to bury the lead here, but I found the problem and fixed it. There was one more instance of "USBInjectAll.kext" that I missed. It was in /Library/Extensions. Once I removed that one, now the XHC section of IORegistryExplorer reports the correct USB ports. (See attached screenshot.) So all is now copacetic and there is a cloudless sky.
Thanks once again for your patience and invaluable help!]
 

Attachments

  • Final IORegExplorer Result.jpg.zip
    111.4 KB · Views: 83
Last edited:
As far as I can tell I have complied with all the procedure requirements, but still IORegistryExplorer is wrong. Any further suggestions?

But since things are still not working, what is your answer to the question I posed in my uploaded (port #36) "Undesired USB Port HS04.jpg" file? Should that "One" be changed to a "Zero" for all the undesired USB ports? Or left alone?

You have something else going on here. The file is not being applied. In theory, the file I supplied should work as is without any modification. This process is not that hard!

I'll put a cup of coffee on it that the same problem you experienced with clover dumping your files elsewhere is somehow booting your system from an unexpected drive and that configuration is not what you expect. It really sounds like you are booting the alternate drive and Clover is remembering the last booted volume and is presenting that as the boot disk when in fact it is not; it's just a volume containing macOS. The boot disk EFI partition does not need to be the same macOS boot volume, just like UniBeast demonstrates when installing.

Just like I discovered that the multiple Clover EFI partitions caused me the black screen issue, it appears this is trickling into your problem. In one of my earlier replies, I did express a concern about your boot drive/disk based on needing to search for the dumped files on your third drive or something.

For argument sake, can you try temporarily disabling all other drive(s) where Clover EFI partitions exist? Obviously not your primary expected boot disk. I know in my Gigabyte BIOS, I can go into the SATA config and disable port(s) via BIOS settings without needing to open the case and detaching any physical cables. Further validations should include the expected BIOS EFI boot drive partition being at the top of the boot order list and checking HDD disk order priority (I know you have SSD but BIOS prompts typically read HDD). With the drives disabled, you can further validate my finding and press F4 (you know when) and I would expect no black screen; just saying.....

Once complete and booted into macOS, mount your EFI partition and check the overall configuration. Once the configuration has been fully vetted, you can reboot and re-enable any drives that were previously disabled in the BIOS or by other method.


Yes, did that. I presume you refer to the patch that removed the 15-port limit in config.pist; I had removed that after using RehabMan's procedure, and it hasn't been present for months. But the "USBInjectAll.kext" files are in separate folders in CLOVER called "kexts/10.13" and also "kexts/other" from which I removed them. As far as I know there is no such "check box" in Clover Configurator... at least I could not find one.

Hum, RehabMan would have a field day with this one after reading hundreds of his posts. He would first say to remove all CLOVER/kexts/10.x.x directories and only use kexts/other. Have you also checked /System/Library/Extensions and/or /Library/Extensions for the .kext? There are also heated differences of opinions as to needing to load kexts/other with alternates. In my experience I go with the /Library/Extensions method to apply alternates. The only time i use kexts/other is if I am creating a boot stick that requires the alternate to function for booting/installation purposes; like an Ethernet driver. However after booting and configuring, I would install the alternate, if needed, in /Library/Extensions. UniBeast/MultiBeast do this too.

Yes, it should have read clover (check box) to disable the 15 port limit patch.


Please report back your findings.
 
bit confused here, this last one i sent works as i wanted actually is it still incorrect ?

I believe that I gave wrong advice in my Post #35. The modifications you made are correct.

I did more research on the subject. The "Name" table is more of a high level definition of the ports used and they do not control the port enabling/disabling.

Sorry for any confusion on my part.
 
Lauderdale,

You must have replied to my post #40 before I had edited it. Here is the content of my edit:

Sorry to bury the lead here, but I found the problem and fixed it. There was one more instance of "USBInjectAll.kext" that I missed. It was in /Library/Extensions. Once I removed that one, now the XHC section of IORegistryExplorer reports the correct USB ports. (See attached screenshot.) So all is now copacetic and there is a cloudless sky.
Thanks once again for your patience and invaluable help!
 

Attachments

  • Final IORegExplorer Result.jpg.zip
    111.4 KB · Views: 160
Lauderdale,

You must have replied to my post #40 before I had edited it. Here is the content of my edit:

Sorry to bury the lead here, but I found the problem and fixed it. There was one more instance of "USBInjectAll.kext" that I missed. It was in /Library/Extensions. Once I removed that one, now the XHC section of IORegistryExplorer reports the correct USB ports. (See attached screenshot.) So all is now copacetic and there is a cloudless sky.
Thanks once again for your patience and invaluable help!


OK, I got one more for you to keep under consideration.

I opened config.plist with Clover Configurator (version 4.34.0), then simply saved the file without edits. No big deal, right? Wrong! I then went back into the config.plist with a text editor (Atom in this case) and found that the necessary AutoMerge directive had been removed from the file. If AutoMerge is not there, then this process will not work, full stop.

I'm using Atom as my text editor because it's free; the Plist editor you use is not free but helps validate your data entry. I would typically use Xcode but I have not signed into the app store to download it on this experimental build.

I found the latest version of Clover Configurator here which got me to version 5.3.1.0.This time when opening and saving config.plist, the AutoMerge changes were not lost. Another good feature is that there is now a checkbox on the ACPI selection settings to enable the AutoMerge directive (lower left hand side above reset address).

Required AutoMerge directive

Code:
    <key>ACPI</key>
    <dict>
        <key>AutoMerge</key>
        <true/>
        <key>DSDT</key>
        <dict>

I did previously mention that I do not use the Clover Configurator application to edit my config.plist. I only use it as a blank empty file to create the SMBIOS data that I later paste into config.plist manually.

I stumbled across this issue because my ports suddenly stopped working. I opened my config.plist file with the older version to support you in this thread and it broke my solution because I simply pressed save using the 4.34.0 version. I think that Clover Configurator also has an auto save feature which is dangerous in itself.

Please ensure your version of the Clover Configurator application before saving your config.plist to avoid potential configuration losses due to the lower (older) version.

Congratulations on your now KEXT'less USB configuration that will have survivorship between combo updates and macOS versions!
 
Great post.

I have a draft version of this guide for Gigabyte that I haven't had a chance to do final a proofread of. This will get me going to finish it and publish.

Any progress on your latest guide?

I truly believe in this method and pretty much understand it fully at this point. I have put forth time to provide troubleshooting tips and examples that hopefully can be incorporated into your next version.

The coming few weeks are my busiest time of the year at work. I don't work in retail but do support the major big box retailers and will have virtually no time to participate in this thread. Example, Thanksgiving day (6PM EST) my self-authored transaction processing system will be cranking, processing Point of Sale activities at cash registers. You can understand the volume potentials here; it's like I make my annual salary in a month but work the whole year in preparation.

Once again thanks for this great initial post. If you need any proof reading or suggestions, I am willing to help you out especially with troubleshooting/example tips. And I have learned that it's not brand specific but chipset specific for sure.
 
Another good feature is that there is now a checkbox on the ACPI selection settings to enable the AutoMerge directive (lower left hand side above reset address).
Wow, great feature, I need to look for that. I've been using Clover Configurator 5.3.1.0 for this procedure, so haven't had the trouble with loss of AutoMerge (yet). Thanks for the tip!
 
Additional findings for a Gigabyte GA-Z170x-Gaming 5 rev 1.0.

I was forced into dealing with this machine when i was attempting to download the full Mojave installation package where it went through the actual upgrade verses just doing the download from the short 25MB installer. It was not my intention to do this High Sierra upgrade because the machine had a Nvidia 1060 video card installed and there are currently no Mojave drivers. Replaced the Nvidia card with a RX-580. Oh well, live and learn....

This motherboard is similar to my previous post covering the UD5 version. It too is a Series 100 chipset. However the implementation of the USB ports are different. Instead of having everything enabled like the UD5 version, the extracted SSDT-3-xh_rvp10.aml (.dsl attached) had a number of ports listed but were not implemented. The specific port needed was HS11 to activated the second onboard chassis header. This port/header is necessary in this installation to activate the header for an expansion card combo WiFi and Bluetooth device. I'm using the Fenvi FV-T919 (ordered from China) as it is supported natively for both WiFi and Bluetooth without the need for any KEXT's (how refreshing, no added work).

Original extracted settings:

Code:
    External (_SB_.PCI0.XHC_.RHUB.HS10, DeviceObj)    // (from opcode)
    External (_SB_.PCI0.XHC_.RHUB.HS10.DP01, DeviceObj)    // (from opcode)
    External (_SB_.PCI0.XHC_.RHUB.HS10.DP02, DeviceObj)    // (from opcode)
    External (_SB_.PCI0.XHC_.RHUB.HS10.DP03, DeviceObj)    // (from opcode)
    External (_SB_.PCI0.XHC_.RHUB.HS10.DP04, DeviceObj)    // (from opcode)
    External (_SB_.PCI0.XHC_.RHUB.HS11, DeviceObj)    // (from opcode)
    External (_SB_.PCI0.XHC_.RHUB.HS12, DeviceObj)    // (from opcode)
    External (_SB_.PCI0.XHC_.RHUB.HS13, DeviceObj)    // (from opcode)
    External (_SB_.PCI0.XHC_.RHUB.HS14, DeviceObj)    // (from opcode)

Modified SSDT settings:

Code:
    External (_SB_.PCI0.XHC_.RHUB.HS10, DeviceObj)    // (from opcode)
    External (_SB_.PCI0.XHC_.RHUB.HS10.DP01, DeviceObj)    // (from opcode)
    External (_SB_.PCI0.XHC_.RHUB.HS10.DP02, DeviceObj)    // (from opcode)
    External (_SB_.PCI0.XHC_.RHUB.HS10.DP03, DeviceObj)    // (from opcode)
    External (_SB_.PCI0.XHC_.RHUB.HS10.DP04, DeviceObj)    // (from opcode)
    External (_SB_.PCI0.XHC_.RHUB.HS11, DeviceObj)    // (from opcode)
    External (_SB_.PCI0.XHC_.RHUB.HS11.DP01, DeviceObj)    // (from opcode)
    External (_SB_.PCI0.XHC_.RHUB.HS11.DP02, DeviceObj)    // (from opcode)
    External (_SB_.PCI0.XHC_.RHUB.HS11.DP03, DeviceObj)    // (from opcode)
    External (_SB_.PCI0.XHC_.RHUB.HS11.DP04, DeviceObj)    // (from opcode)
    External (_SB_.PCI0.XHC_.RHUB.HS12, DeviceObj)    // (from opcode)
    External (_SB_.PCI0.XHC_.RHUB.HS13, DeviceObj)    // (from opcode)
    External (_SB_.PCI0.XHC_.RHUB.HS14, DeviceObj)    // (from opcode)

Noting the differences from the above code snips, I added four lines below the original "_SB_.PCI0.XHC_.RHUB.HS11" to activate the chassis header. This experiment proved successful for this implementation.

MacMan, hopefully these little tidbits are helpful for your next guide covering the Gigabyte branded motherboard.

Thanks.

GA-Z170x-Gaming5-USBPorts.png
 

Attachments

  • SSDT-3-xh_rvp10.dsl
    59.6 KB · Views: 115
  • SSDT-3.dsl
    59.9 KB · Views: 136
Back
Top