The New Beginner's Guide to USB Port Configuration

[Deleted member 188658]

@UtterDisbelief :

Only a full *.IOReg export will give us more details, but I understand some people are not happy to upload this.

At this stage I'm willing to try anything. How do I do a full *.IOReg export?

EDIT:

I did a save as from IORegistryExplorer, and have attached the file. Hope this is what you were referring to.


EDIT # 2:

There is something seriously wrong with my port injection.

I put a USB-C device on the back panel. In IOregs it shows as HS02, speed 480Mb/s. There is no equivalent SS02. Any USB-C device I plug in there only show up as HS02.

Also not listed in the IORegs are SS02, SS05, or SS06. I would expect a full range of HS and SS ports to appear. Am I doing something wrong there?

I have replaced the USB-C multiplexer on the front panel and am now using a USB-C to USB-A adaptor. Whereas the BIOS sees these devices, they do not show up in the IORegs (Or Hackintool). Let me now attach by USBInjectAll EFI with config.plist to see if you can see something wrong with the injector. I'm reading your original guide on USB injection -written mostly for Clover it seems - and it doesn't seem right on IORegs. All of this work is done on the Vanilla install Mac-2 drive OS.

 

[UtterDisbelief]

@UtterDisbelief :



At this stage I'm willing to try anything. How do I do a full *.IOReg export?

EDIT:

I did a save as from IORegistryExplorer, and have attached the file. Hope this is what you were referring to.

Okay, that's great. That shows much more detail.

SS06 from your previous USBPorts.kext configuration has obviously not been included in the SSDT-UIAC.aml you've created, that's why it doesn't now show.

What do you mean by "USB-C Multiplexer" ? Your case features the new USB3.1 Gen 2 front panel connector as well as the traditional 9-pin and 20-pin ones too. Is this some other device? I don't see any Device ID to be able to identify it.

HS07 is now showing a hub with 4x USB2.0 ports on it. That's interesting. What might that be?

HS14 is your BT controller but I am unsure as to why there are more USB2.0 ports attached there. Is the BT adapter a USB dongle plugged into a port directly or a hub?

You seem to have USB drives in HS02, which looks bootable, and SS09 ...........

Unfortunately I'm having to do too much off-site research to help you here - manuals from Asus, NZXT and Device ID searches to learn what all plugged-in devices are. You can do this more usefully. The USB port discovery process should done with no external devices insterted. We then use one device to test each port and watch Hackintool (or IOReg) light-up to show where it is. That way we locate our ports. Having everything plugged-in at once will only serve to confuse and get in the way.

Although off-topic I suspect the Samsung 850 not showing at all might be down to SATA/PCI limitations. If SATA port 2 is in use then the M.2 socket is disabled etc. I can't test this, so that's something to check with the manual.

 

[Deleted member 188658]

@UtterDisbelief

There is something primarily wrong with my process/port injection. I don't know what it is. But let me clear up some of your questions first.

HS07 is now showing a hub with 4x USB2.0 ports on it. That's interesting. What might that be?

The HS07 was a USB Multiplexer -as I call them - or USB 3.0 switch as you may know them, on which I put some HDD drives which I use for TM, CarbonCopy, Media etc.

I removed it.

The USB port discovery process should done with no external devices insterted.

Yes, I have restarted the whole process with just the Optical Mouse and Apple Keyboard plugged in.

What do you mean by "USB-C Multiplexer" ?

A USB switch. It's a breakout box, that connects to USB-C and presents USB-A and USB-C ports. I have removed it. I was trying to take a short cut, by plugging a USB-C drive and a USB-A 3.0 drive into the 'switch'. Whereas the BIOS recognizes both of these drives when the switch is plugged in, the port injection sees nothing on the front panel USB-C port.

Page 2-14 of the ASUS Manual shows these USB ports:


Using the numbering in the image:
USB #2 (2 of). HS05. and HS06 (mouse and keyboard)
USB #9. (2 of). HS07/SS07 and HS08/SS08
USB #8 (1 of) HS02. - I was never able to SEE a SS02 in the IORegs or in Hackintool
USB #7. (2 of) HS03 and HS04: Never able to get SS03 or SS04 to light up - whereas the same device lit up SS07 and SS08 - something major wrong here.

Finally Front Panel of Chassis:

USB-A. seen as SS09. Never able to see HS09 in IOREgs or Hackintool
USB-C. never seen no matter what I plugged in. Same test USB drive on USB #8 at least lit up HS02.

Next: Bluetooth: I am using a BCM94360NG M.2 card. Works beautifully Wifi and Bluetooth. It replaces the Intel Wifi card on the MB. Brilliant drop in solution to Network issue.

The BT card appears to be on HS14.

When I just rebooted, with all the USB ports empty (except mouse + keyboard) I removed SSDT-UIAC.aml and SSDT-EC-USBX.aml from EFI/ACPI, cause I inherited these from @ModMike. I have only SSDT-AWAC.aml, SSDT-PLUG.aml and SSDT-PMC.aml in that folder now. I think I need SSDT-PMC.aml to boot? or is it SSDT-PLUG.aml .

This made NO difference to what I see with IORegs on the XHC controller.

What is gone since removing the Clover port Limit patches, on advice, is the recognition of the NZXT LED controller. Another clue? I made sure to boot to Windows, load the NZXT LED firmware before booting to this vanilla OS X. It's sitting there under the table flashing a rainbow of colors as I type this.

Also what happened to SS06 that we saw yesterday. I can't see that port.

I bought a USB splitter on Amazon that plugs into the SINGLE USB port of the MB and presents two USB internal ports. One port goes to the NZXT led controller, the other goes to the Water Cooler that also oscillates colors according to the temp of the CPU core. All works in Windows. I don't care if they don't work in OS X just as long as I can sleep / wake.

So my bottom line question for you is: When I inject on the USB ports should the IORegs not show HS02-HS14, and then the matching SS02-SS10?

Why does SS02 and SS03 not wake up when I plug a 3.1 drive into USB #7 ?

Where is the USB port for the NZXT controller ? It's wired and working in Windows 10 so it's not as if there is a HW problem.

I suspect the Samsung 850 not showing at all might be down to SATA/PCI limitations.

I always see the Samsung 850 drive as the Windows named GPT-Win drive in OS X. There is no conflict on SATA with the 2 Samsung drives I have there: Mac-2 and GPT-Win. Not sure that's a worry.

Let's try and get the initial conditions of the port discover working? Could it be the remaining SSDT*.aml in ACPI? Where can I get vanilla versions of these - as they all came from @ModMike.

Thanks again.

 

[UtterDisbelief]

@UtterDisbelief

There is something primarily wrong with my process/port injection. I don't know what it is. But let me clear up some of your questions first.




The HS07 was a USB Multiplexer -as I call them - or USB 3.0 switch as you may know them, on which I put some HDD drives which I use for TM, CarbonCopy, Media etc.

I removed it.



Yes, I have restarted the whole process with just the Optical Mouse and Apple Keyboard plugged in.



A USB switch. It's a breakout box, that connects to USB-C and presents USB-A and USB-C ports. I have removed it. I was trying to take a short cut, by plugging a USB-C drive and a USB-A 3.0 drive into the 'switch'. Whereas the BIOS recognizes both of these drives when the switch is plugged in, the port injection sees nothing on the front panel USB-C port.

Page 2-14 of the ASUS Manual shows these USB ports:
View attachment 480031

Using the numbering in the image:
USB #2 (2 of). HS05. and HS06 (mouse and keyboard)
USB #9. (2 of). HS07/SS07 and HS08/SS08
USB #8 (1 of) HS02. - I was never able to SEE a SS02 in the IORegs or in Hackintool
USB #7. (2 of) HS03 and HS04: Never able to get SS03 or SS04 to light up - whereas the same device lit up SS07 and SS08 - something major wrong here.

Finally Front Panel of Chassis:

USB-A. seen as SS09. Never able to see HS09 in IOREgs or Hackintool
USB-C. never seen no matter what I plugged in. Same test USB drive on USB #8 at least lit up HS02.

Next: Bluetooth: I am using a BCM94360NG M.2 card. Works beautifully Wifi and Bluetooth. It replaces the Intel Wifi card on the MB. Brilliant drop in solution to Network issue.

The BT card appears to be on HS14.

When I just rebooted, with all the USB ports empty (except mouse + keyboard) I removed SSDT-UIAC.aml and SSDT-EC-USBX.aml from EFI/ACPI, cause I inherited these from @ModMike. I have only SSDT-AWAC.aml, SSDT-PLUG.aml and SSDT-PMC.aml in that folder now. I think I need SSDT-PMC.aml to boot? or is it SSDT-PLUG.aml .

This made NO difference to what I see with IORegs on the XHC controller.

What is gone since removing the Clover port Limit patches, on advice, is the recognition of the NZXT LED controller. Another clue? I made sure to boot to Windows, load the NZXT LED firmware before booting to this vanilla OS X. It's sitting there under the table flashing a rainbow of colors as I type this.

Also what happened to SS06 that we saw yesterday. I can't see that port.

I bought a USB splitter on Amazon that plugs into the SINGLE USB port of the MB and presents two USB internal ports. One port goes to the NZXT led controller, the other goes to the Water Cooler that also oscillates colors according to the temp of the CPU core. All works in Windows. I don't care if they don't work in OS X just as long as I can sleep / wake.

So my bottom line question for you is: When I inject on the USB ports should the IORegs not show HS02-HS14, and then the matching SS02-SS10?

Why does SS02 and SS03 not wake up when I plug a 3.1 drive into USB #7 ?

Where is the USB port for the NZXT controller ? It's wired and working in Windows 10 so it's not as if there is a HW problem.



I always see the Samsung 850 drive as the Windows named GPT-Win drive in OS X. There is no conflict on SATA with the 2 Samsung drives I have there: Mac-2 and GPT-Win. Not sure that's a worry.

Let's try and get the initial conditions of the port discover working? Could it be the remaining SSDT*.aml in ACPI? Where can I get vanilla versions of these - as they all came from @ModMike.

Thanks again.

Hi there.

You ask me:

"So my bottom line question for you is: When I inject on the USB ports should the IORegs not show HS02-HS14, and then the matching SS02-SS10?"

Yes, if you install USBInjectAll.kext in EFI/CLOVER/kexts/Other without an SSDT and have the XhciPortLimit quirk enabled in your config.plist then all your ports will show in IORegistryExplorer. I recommend using USBInjectAll.kext version 0.7.1 or 0.7.3 and NOT 0.7.5.

You shouldn't need any SSDTs in place just to boot your system. OpenCore does all the heavy lifting. Patching ACPI, unless you know how and why, is something that should be kept to a minimum. It can be useful later-on as some systems require an embedded-controller and help with USB power delivery.

I disagree with ModMike's USB methodology for configuring USB ports.

 

[Deleted member 188658]

@UtterDisbelief :

Yes, if you install USBInjectAll.kext in EFI/CLOVER/kexts/Other without an SSDT and have the XhciPortLimit quirk enabled in your config.plist then all your ports will show in IORegistryExplorer. I recommend using USBInjectAll.kext version 0.7.1 or 0.7.3 and NOT 0.7.5.

I'm on OC. I hope you mean USBInjectAll.kext in OC/Kexts not the Clover reference?

I have found old copies of 0.7.1 and 0.7.3, so I will run my experiments with them. Just curious, you seem adamant about not 0.7.5 - wonder why? Thanks for the advice.

Yes,

That is the key isn't it? When I do port injection I DON"T see all the ports on the XHC controller. If I can fix that I can make progress, I hope.

You shouldn't need any SSDTs in place just to boot your system.

I do need one at least. I think it is SSDT_EC.aml which fixes a 1689 Panic code on attempting to boot Catalina. Do you know of such? I found out about it in April 2020 when attempting to get this Hack working.

I disagree with ModMike's USB methodology for configuring USB ports.

Well it certainly didn't work for me !!

I will return later with results of more experiments.

 

[UtterDisbelief]

@UtterDisbelief :

I'm on OC. I hope you mean USBInjectAll.kext in OC/Kexts not the Clover reference?
.

Yes, my mistake. A typo more than my intent.

@UtterDisbelief :

That is the key isn't it? When I do port injection I DON"T see all the ports on the XHC controller. If I can fix that I can make progress, I hope.

No idea why your Z390 is different to all the others. Sorry, that sounded blunt, but why it won't work for your machine is a mystery. A fix is not needed, just correct method.

@UtterDisbelief :

I do need one at least. I think it is SSDT_EC.aml which fixes a 1689 Panic code on attempting to boot Catalina. Do you know of such? I found out about it in April 2020 when attempting to get this Hack working.

Yes, fully conversant with the problem and cure. Not needed for most Z390 motherboards but if yours does, then I stand corrected. As you were.

In conclusion please bear in mind the process outlined here is correct. Some motherboards are e ceptions to the rule.

 

[Deleted member 188658]

@UtterDisbelief :

Yes, if you install USBInjectAll.kext in EFI/CLOVER/kexts/Other without an SSDT and have the XhciPortLimit quirk enabled in your config.plist then all your ports will show in IORegistryExplorer. I recommend using USBInjectAll.kext version 0.7.1 or 0.7.3 and NOT 0.7.5.

I'm on OC. I hope you mean USBInjectAll.kext in OC/Kexts not the Clover reference?

I have found old copies of 0.7.1 and 0.7.3, so I will run my experiments with them. Just curious, you seem adamant about not 0.7.5 - wonder why? Thanks for the advice.

Yes,

That is the key isn't it? When I do port injection I DON"T see all the ports on the XHC controller. If I can fix that I can make progress, I hope.

You shouldn't need any SSDTs in place just to boot your system.

I do need one at least. I think it is SSDT_EC.aml which fixes a 1689 Panic code on attempting to boot Catalina. Do you know of such? I found out about it in April 2020 when attempting to get this Hack working.

I disagree with ModMike's USB methodology for configuring USB ports.

Well it certainly didn't work for me !!

I will return later with results of more experiments.

 

[Deleted member 188658]

@UtterDisbelief :

I will return later with results of more experiments.

Think I got it!. It was SSDT-UIAC.aml in the OC/ACPI folder.

I have always run into APFS Panic 1689 when I messed with the ACPI folder contents. After opening all the files with MaciASL I found that SSDT-UIAC.aml contained USB port definitions - limiting what I could see with USBInjectAll.kext!
Since iterating through all the SSDT definitions was tedious, and almost always caused a the Panic 1689, I stopped changing it. But spending the time (wasting the time?) today eventually I identified SSDT-UIAC.aml as the culprit.

Here's my IOReg now. Any advice from here? Look at all those ports!! Took weeks to get here.


Need to add this:

The Hackintool sees DUPLICATE ports, whereas IOReg does not. How should we interpret this? A Hackintool bug?

 

[UtterDisbelief]

@UtterDisbelief :



Think I got it!. It was SSDT-UIAC.aml in the OC/ACPI folder.

I have always run into APFS Panic 1689 when I messed with the ACPI folder contents. After opening all the files with MaciASL I found that SSDT-UIAC.aml contained USB port definitions - limiting what I could see with USBInjectAll.kext!
Since iterating through all the SSDT definitions was tedious, and almost always caused a the Panic 1689, I stopped changing it. But spending the time (wasting the time?) today eventually I identified SSDT-UIAC.aml as the culprit.

Here's my IOReg now. Any advice from here? Look at all those ports!! Took weeks to get here.
View attachment 480148

Need to add this:

The Hackintool sees DUPLICATE ports, whereas IOReg does not. How should we interpret this? A Hackintool bug?

View attachment 480149

Well done on getting to the bottom of your problem

There's a fair bit of ACPI theory goes along with this, but you asked me earlier about USBInjectAll v0.7.5 ...

SSDT-UIAC.aml is more a configuration file for USBInjectAll.kext than a direct ACPI patch. The "UIAC" at the end gives this away - UsbInjectAll Configuration. Normally if you de-activate USBInjectAll.kext in your OpenCore config.plist when using USBPorts.kext, which, if memory serves me you had done, then the SSDT-UIAC.aml gets ignored. Maybe you are highlighting an OpenCore issue here in that despite this the *.aml still gets "merged" with ACPI regardless. It didn't happen with Clover. More research around that definitiely needed.

Also I discovered bugs in USBInjectAll.kext 0.7.5 and until we can get those ironed-out don't recommend using it right now. This is a result of us forking development from @RehabMan 's otherwise stalled project to add new machine system-definitions.

Yes, the same data is in both the USBPorts.kext and SSDT-UIAC.aml. The first is a codeless kext which is ideal for Catalina as it sneaks past security when USBInjectAll.kext can't because it has program-code in it.

Incidentally if you had been able to boot without SSDT-EC.aml then Hackintool would have created one for you along with the SSDT and Kext it normally outputs. I only ever needed this on my Z370 builds, never a Z390. But now we know Asus may be an exception!

Anyway, from here, IORegistryExplorer and Hackintool both look to be reporting properly now.

 

[Gigamaxx]

@UtterDisbelief :



Think I got it!. It was SSDT-UIAC.aml in the OC/ACPI folder.

I have always run into APFS Panic 1689 when I messed with the ACPI folder contents. After opening all the files with MaciASL I found that SSDT-UIAC.aml contained USB port definitions - limiting what I could see with USBInjectAll.kext!
Since iterating through all the SSDT definitions was tedious, and almost always caused a the Panic 1689, I stopped changing it. But spending the time (wasting the time?) today eventually I identified SSDT-UIAC.aml as the culprit.

Here's my IOReg now. Any advice from here? Look at all those ports!! Took weeks to get here.
View attachment 480148

Need to add this:

The Hackintool sees DUPLICATE ports, whereas IOReg does not. How should we interpret this? A Hackintool bug?

View attachment 480149

Did you try the broom on Hackintool to sweep all the entries away and then the refresh tab?