The New Beginner's Guide to USB Port Configuration

[RDPRDP]

Thanks so much for the explanation.

I've done my best to remove references to GenericUSBXHCI.kext and FakePCIID_XHCIMux.kext at the locations you identified (EFI/EFI/CLOVER/kexts/other, Library/Extension, System/Library/Extension), but Hackintool still shows me an AppleUSBEHCIPCI device at the same location (0x1E26) as EH01. I have attached an updated IOReg dump, can you still see the offending item?

I've modified, and here are my current BIOS settings.

Intel USB2.0 EHCI Controller = Enable
Legacy USB Support = Auto
Legacy USB3.0 Support = Disabled
Intel xHCI Mode = Enabled (not Auto, or Smart Auto, not sure which is preferred)
EHCI Hand-off = Enabled

Note: It seems I do not have an xHCI Hand-off option.


Results:

1. I now have an XHC entry on Hackintool.
2. All of my devices that were previously working off of the 3.0 ports (two @ 2x, one @ 3x) are no longer active. On the previous IOReg report they were identified as

USB3 device
XHCI Root Hub SS Simulation@0
COM35EU3b6G@1f100000

USB2 device
XHCI Root Hub USB 2.0 Simulation@0
iPad@1c100000

USB2 device
XHCI Root Hub USB 2.0 Simulation@0
Fireface UC Mac (23244188)@1e200000



Question regarding Hackintool: when I click on one of the devices in the top part of the screen it still shows absolutley all of the ports in the window below. I think that for most people when you select a device at the top it restricts the port display below to only the ports associated with the device? Maybe this suggests a problem, either user error or otherwise?

thanks again,
RDP

 

[UtterDisbelief]

Thanks so much for the explanation.

I've done my best to remove references to GenericUSBXHCI.kext and FakePCIID_XHCIMux.kext at the locations you identified (EFI/EFI/CLOVER/kexts/other, Library/Extension, System/Library/Extension), but Hackintool still shows me an AppleUSBEHCIPCI device at the same location (0x1E26) as EH01. I have attached an updated IOReg dump, can you still see the offending item?

I've modified, and here are my current BIOS settings.

Intel USB2.0 EHCI Controller = Enable
Legacy USB Support = Auto
Legacy USB3.0 Support = Disabled
Intel xHCI Mode = Enabled (not Auto, or Smart Auto, not sure which is preferred)
EHCI Hand-off = Enabled

Note: It seems I do not have an xHCI Hand-off option.


Results:

1. I now have an XHC entry on Hackintool.
2. All of my devices that were previously working off of the 3.0 ports (two @ 2x, one @ 3x) are no longer active. On the previous IOReg report they were identified as

USB3 device
XHCI Root Hub SS Simulation@0
COM35EU3b6G@1f100000

USB2 device
XHCI Root Hub USB 2.0 Simulation@0
iPad@1c100000

USB2 device
XHCI Root Hub USB 2.0 Simulation@0
Fireface UC Mac (23244188)@1e200000



Question regarding Hackintool: when I click on one of the devices in the top part of the screen it still shows absolutley all of the ports in the window below. I think that for most people when you select a device at the top it restricts the port display below to only the ports associated with the device? Maybe this suggests a problem, either user error or otherwise?

thanks again,
RDP

Okay, more to work with ...

Any reason why you disabled Legacy USB3.0 Support ?

Going through your "Results" list:

1) Good.

2) Explain ... We can see USB3.0 ports active, but not in your Hackintool screengrab as they are below the bottom of the screen and need scrolling to see. SSP1 starts @14500000

Your iPad is connected to a different port in the latest IOReg - HP24 - which is on a USB hub and @1a142000

There is clearly a problem being caused by a software utility from a company called Eltima. I don't have enough information to know what you have installed, but I can tell you this is the reason for the AppleUSBEHCIPCI driver incorrectly showing as a controller in Hackintool. It is also shifting the hub ports further out on the IOReg tree.

Finally, I have noticed the behaviour of Hackintool when a controller is selected. It is logical to expect that if you highlight one, only the ports attached to it will show. This doesn't seem to happen. I don't know if this is a bug or intentional. Sadly I don't have a multi-controller motherboard built into a running PC to check. We need to ask @headkaze for guidance.

 

[RDPRDP]

Progress in the form of two steps forward, one step back. Gain = one step. Good!

Two steps forward: Deleting the offending software from Eltima has removed AppleUSBEHCIPCI, as you advised it would. Superb!

One step backward: Still not got back the three devices that are connected to the 3.0 ports:

USB3 device
XHCI Root Hub SS Simulation@0
COM35EU3b6G@1f100000

USB2 device
XHCI Root Hub USB 2.0 Simulation@0
iPad@1c100000

USB2 device
XHCI Root Hub USB 2.0 Simulation@0
Fireface UC Mac (23244188)@1e200000


Comments:

Why I disabled USB3.0 Legacy Support in the BIOS = I was just trying multiple combinations of settings, and thats what the settings were when I wrote my message. Now I confirm I am back to what is probably the standard (please let me know if this is not good!):

Intel USB2.0 EHCI Controller = Enable
Legacy USB Support = Enable
Legacy USB3.0 Support = Enable
Intel xHCI Mode = Enabled (not Auto, or Smart Auto, not sure which is preferred)
EHCI Hand-off = Enabled

Regarding the iPad: I have two! One is on a 2.0 port and 2.0 Hub where you say it is @1a142000. The other is the "lost" one.

Whats interesting is that my 3.0 ports (1 @ 3.0, 2 @ 2.0) were working before. So something that was removed, or moved, or changed, is the culprit. When I reboot the computer, I see the 3.0 Drive showing EFI boot options in Clover, so I know it's exposed at that stage properly, and one of my other devices (RME Fireface UC) has a HOST LED on it, so I can see that it initially is happy, but when OSX starts, the error LED comes back on, so it seems that under BIOS control things are good, but when OSX comes on-line the 3.0 ports break. Another thing I notice is that the Location ID are now different for the missing three devices, so that might also have something to do with my my devices are not showing up. Previously they were @1f100000, @1c100000, and @1e200000, and now the XHC ports Location ID are listed from @141~@148.

All in all, I do feel that this is progress. Thanks!

Latest IOREG and Hackintool grab attached.

I'm wondering, do I need to be injecting anything, or setting anything in config.plst at this new juncture that I was not maybe before?


RDP

 

[UtterDisbelief]

Progress in the form of two steps forward, one step back. Gain = one step. Good!

Two steps forward: Deleting the offending software from Eltima has removed AppleUSBEHCIPCI, as you advised it would. Superb!

One step backward: Still not got back the three devices that are connected to the 3.0 ports:

USB3 device
XHCI Root Hub SS Simulation@0
COM35EU3b6G@1f100000

USB2 device
XHCI Root Hub USB 2.0 Simulation@0
iPad@1c100000

USB2 device
XHCI Root Hub USB 2.0 Simulation@0
Fireface UC Mac (23244188)@1e200000


Comments:

Why I disabled USB3.0 Legacy Support in the BIOS = I was just trying multiple combinations of settings, and thats what the settings were when I wrote my message. Now I confirm I am back to what is probably the standard (please let me know if this is not good!):

Intel USB2.0 EHCI Controller = Enable
Legacy USB Support = Enable
Legacy USB3.0 Support = Enable
Intel xHCI Mode = Enabled (not Auto, or Smart Auto, not sure which is preferred)
EHCI Hand-off = Enabled

Regarding the iPad: I have two! One is on a 2.0 port and 2.0 Hub where you say it is @1a142000. The other is the "lost" one.

Whats interesting is that my 3.0 ports (1 @ 3.0, 2 @ 2.0) were working before. So something that was removed, or moved, or changed, is the culprit. When I reboot the computer, I see the 3.0 Drive showing EFI boot options in Clover, so I know it's exposed at that stage properly, and one of my other devices (RME Fireface UC) has a HOST LED on it, so I can see that it initially is happy, but when OSX starts, the error LED comes back on, so it seems that under BIOS control things are good, but when OSX comes on-line the 3.0 ports break. Another thing I notice is that the Location ID are now different for the missing three devices, so that might also have something to do with my my devices are not showing up. Previously they were @1f100000, @1c100000, and @1e200000, and now the XHC ports Location ID are listed from @141~@148.

All in all, I do feel that this is progress. Thanks!

Latest IOREG and Hackintool grab attached.

I'm wondering, do I need to be injecting anything, or setting anything in config.plst at this new juncture that I was not maybe before?


RDP

Glad to hear things are, at least, moving along ...

You have so many devices attached, it's quite interesting working through them.

Starting with the two EHCI controllers:

EH01 -

Edirol UA-1D
Softube AB device/plug-in


EH02 -

Toshiba USB flash drive
iPad
Griffin Powermate controller
Soundforce MIDI controller
Edirol UM-880

The ASMedia add-on USB2.0 ports are 'hung' as a hub on EH02 and start at @1a140000 -

Tascam US-2400 audio device
A USB to Serial Port UART
Logitech wireless receiver
Dell Mouse

... this struck me as a little odd as there are 2x external ports and 2x internal on the ASM controller. I guess the Serial port could be an internal device but ...


The XHCI (USB3.0) controller is empty. The four ports there are are the Intel ones. Why is there nothing attached that is USB3.0?

The ASMedia USB3.0 ports would not be here but elsewhere as they are not Intel, but I can't find them. Their USB2.0 equivalents are fine, as you can see in my list, but just no USB3.0 ports on RP or PX nodes.

I am baffled by this. There must be some other configuration, or kext, I am not seeing causing this.

 

[RDPRDP]

Placeholder: I'm sorry you had to write all of that, because I have been tearing my hair out here looking for solutions, and just made very much by chance, but still a total geek discovery which confuses me, and I will write that up now.

 

[RDPRDP]

Very, very interesting.

First of all, just as it's complicated, I wanted to define my device tree a bit more for you when you made reference to the add-on ASMedia 2.0 ports. BTW, I see that device currently at 0x1a130000, maybe a change since my last upload to you (I will include a new upload today)? So, if you look at the vendor ID for that device, it lists as LG Electronics. Those devices hanging off the ASM107x are all connected to a hub thats integrated into my LG monitor, then that connects upstream with a single USB cable. Hanging off the monitor hub are:

USB mouse on an extender cable
Logitech BT dongle (which creates two usb entries, I don't know why: 0x1a134300 / 12, 0x1a134200 / 11)
Tascam US-2400
TUSB3410 Boot Device (I think this has to do with the Thunderbolt/USB functionality of my LG monitor)

The LG monitor then connects upstream to an adapter back slot adapter, which connects to the internal USB1314 header connector. BTW the remaining EH02 items (Toshiba USB flash drive, iPad, Griffin Powermate controller, Soundforce MIDI controller) connect from a USB2.0 HUB into the same back slot adapter into USB1314. The only device that connects to that same controller is the Edirol UM-880, and it plugs into the one of USB56 connector of the backplane. That covers EH02.

EH01 is simply two devices connected at the front of my tower connecting internally into header USB910.


Now, how about my lost devices. How was I able to make progress? As my USB3 backup drive was no longer working (one of my three lost devices) I decided to move it to another physical port on the backplane. And it worked there, as expected, but shockingly to me, it showed up as a USB3 device! That really floored me, and let me to my current discovery:

Until we started to make changes my three (currently lost) devices were connected to

two device to backplane: 2.2 (page 26) of the manual, very top left, USB3_E12
one device to front of tower to internal header: 2.2 (page 26) of the manual, bottom left, USB3_E34

When I moved my devices today (and I have now moved them all) I moved them to USB3_12 (backplane) and USB_34 (internal header).

I'm confused, but I guess that means I have two 3.0 controllers, for a total of sixteen ports, and until I made changes I was using the "E" ports, but now they are dead, and I have moved over to the "non-E" ports where they work.

Question: Can I get back my USB3_E12 and USB3_E34 ports (they charge my ipad, where the currently used ports don't......) or is that not permitted when trying to be compatible via this process?

Progress!


thanks,
RDP

 

[UtterDisbelief]

Very, very interesting.

First of all, just as it's complicated, I wanted to define my device tree a bit more for you when you made reference to the add-on ASMedia 2.0 ports. BTW, I see that device currently at 0x1a130000, maybe a change since my last upload to you (I will include a new upload today)? So, if you look at the vendor ID for that device, it lists as LG Electronics. Those devices hanging off the ASM107x are all connected to a hub thats integrated into my LG monitor, then that connects upstream with a single USB cable. Hanging off the monitor hub are:

USB mouse on an extender cable
Logitech BT dongle (which creates two usb entries, I don't know why: 0x1a134300 / 12, 0x1a134200 / 11)
Tascam US-2400
TUSB3410 Boot Device (I think this has to do with the Thunderbolt/USB functionality of my LG monitor)

The LG monitor then connects upstream to an adapter back slot adapter, which connects to the internal USB1314 header connector. BTW the remaining EH02 items (Toshiba USB flash drive, iPad, Griffin Powermate controller, Soundforce MIDI controller) connect from a USB2.0 HUB into the same back slot adapter into USB1314. The only device that connects to that same controller is the Edirol UM-880, and it plugs into the one of USB56 connector of the backplane. That covers EH02.

EH01 is simply two devices connected at the front of my tower connecting internally into header USB910.


Now, how about my lost devices. How was I able to make progress? As my USB3 backup drive was no longer working (one of my three lost devices) I decided to move it to another physical port on the backplane. And it worked there, as expected, but shockingly to me, it showed up as a USB3 device! That really floored me, and let me to my current discovery:

Until we started to make changes my three (currently lost) devices were connected to

two device to backplane: 2.2 (page 26) of the manual, very top left, USB3_E12
one device to front of tower to internal header: 2.2 (page 26) of the manual, bottom left, USB3_E34

When I moved my devices today (and I have now moved them all) I moved them to USB3_12 (backplane) and USB_34 (internal header).

I'm confused, but I guess that means I have two 3.0 controllers, for a total of sixteen ports, and until I made changes I was using the "E" ports, but now they are dead, and I have moved over to the "non-E" ports where they work.

Question: Can I get back my USB3_E12 and USB3_E34 ports (they charge my ipad, where the currently used ports don't......) or is that not permitted when trying to be compatible via this process?

Progress!


thanks,
RDP

Okay. My own placeholder =

I'm away from my desk right now so I'll take a new look later

 

[UtterDisbelief]

...

Okay, I've taken another look, run through the whole system, to try and understand your problems. I think though, that they are simpler than they seem, all because you are trying to configure everything with so many devices attached. They are clouding the issue, so to speak.

There are two key points to make:

1) The monitor hub you mention would take just one host port on your motherboard and be attached to it. Going with that thought, the way you describe it implies that the LG monitor has, by coincidence, its own ASMedia controlled hub inside it. This hub then, is attached to USB port HP23 on your motherboard.

2) This means the actual ASUS fitted ASMedia USB3.0 controller is not showing in either Hackintool or IOReg.

The result of that is that you have 2x USB3 ports on the back-panel and 2x USB3 ports on an internal header that may be working but that will not be configurable, nor show the devices attached to them. Perhaps that second iPad you mention.

Incidentally, that TUSB3410 is a Texas Instruments USB to UART (Serial port) converter. If it is a part of your monitor's TB port I would have no idea how that could even work. More likely it is some audio device. Happy to be proved wrong though. We live and learn every day.

 

[RDPRDP]

Ok, I'm back for more.

Latest discovery: I can obtain the HS&SS ASMedia Controllers by installing the GenericUSB.kext, and (I need to double check to be sure) selecting "Fix Ownership" in Devices in Clover Configurator. The four additional Hub Simulations (2 HS, 2 SS) show in IO Explorer as expected, but thats getting ahead of the current step, isn't it? So, for now I have removed the Kext and the Fix Ownership flag, and focused on the current steps, and the results are attached.

Note 1: The ASMedia devices enabled by the GenericUSB kext showed up in IO Explorer, but not in Hackintool, but I think in another message you mentioned that was expected behavior. My question would be if those ports need to be accounted for in the total port count I am looking to achieve? If the answer happens to be yes, then it suggests a different approach to removing these ports as they do not show up in Hackintool.

Note 2: You will see the XHC controller is missing HS/SS2, this is on purpose as the physical port connector is broken.

Question 1: In Hackintool I only see down as far as the Hubs (ASM107x@1a130000, USB2.0 Hub@1a140000), not to the devices downstream from the hubs. I guess I don't have to worry about accounting for those devices when removing the unused ports in Hackintool?

Question 2: You will see a lot of unused ports in white, this is because these ports all seemed to be paired with a used port. For instance HP11 & PR11, HP18 & PR18. Should I leave these as they are (keep the pair)?. I'm not sure the implication of what might happen in the future if a different class/speed device is plugged in. Your advice would be appreciated.

Question 3: I tried the removal process twice, with the same result, but for some reason HP13 is still showing. Is there any way I can confirm the contents of the kext? I attached it just in case you have some magic solution.

thanks!
RDP

 

[UtterDisbelief]

Ok, I'm back for more.

Latest discovery: I can obtain the HS&SS ASMedia Controllers by installing the GenericUSB.kext, and (I need to double check to be sure) selecting "Fix Ownership" in Devices in Clover Configurator. The four additional Hub Simulations (2 HS, 2 SS) show in IO Explorer as expected, but thats getting ahead of the current step, isn't it? So, for now I have removed the Kext and the Fix Ownership flag, and focused on the current steps, and the results are attached.

Note 1: The ASMedia devices enabled by the GenericUSB kext showed up in IO Explorer, but not in Hackintool, but I think in another message you mentioned that was expected behavior. My question would be if those ports need to be accounted for in the total port count I am looking to achieve? If the answer happens to be yes, then it suggests a different approach to removing these ports as they do not show up in Hackintool.

Note 2: You will see the XHC controller is missing HS/SS2, this is on purpose as the physical port connector is broken.

Question 1: In Hackintool I only see down as far as the Hubs (ASM107x@1a130000, USB2.0 Hub@1a140000), not to the devices downstream from the hubs. I guess I don't have to worry about accounting for those devices when removing the unused ports in Hackintool?

Question 2: You will see a lot of unused ports in white, this is because these ports all seemed to be paired with a used port. For instance HP11 & PR11, HP18 & PR18. Should I leave these as they are (keep the pair)?. I'm not sure the implication of what might happen in the future if a different class/speed device is plugged in. Your advice would be appreciated.

Question 3: I tried the removal process twice, with the same result, but for some reason HP13 is still showing. Is there any way I can confirm the contents of the kext? I attached it just in case you have some magic solution.

thanks!
RDP

PR11 and PR21 are the root hubs of the EHCI controllers, EH01 and EH02 and should not be touched.

I don't see GenericUSBXHCI.kext loaded in the latest IOReg uploaded. Bear in mind what I said previously, it is not working properly, if at all, for later versions of macOS. However, if it helps, great. That's a mystery.

Your examples of port pairs, for e.g. HP18 and PR18 are both valid but the PR** port is only a "placeholder" in this configuration. You can remove them from Hackintool. This doesn't do any harm as it is easily reversible if you discover a problem. Your active USB2.0 ports are all HP** and PRT*.

The motherboard ASMedia ASM1143 controller is attached to node RP03, PXSX@0, however there are no active ports.


So status review -

Too many devices and software drivers installed to see clearly the base system but by digging we can find them.

The ASMedia piggy-back controller is not visible in Hackintool because it is not active. You say GenericUSBXHCI.kext actvates it successfully, but there's no evidence of that in the uploads.

Messy USB2 configuration, caused, I suspect, by device kexts or drivers. If not then that Asus motherboard is very unsual.

HP13 is not showing in IOReg at all so it should not magically appear in Hackintool. They both read the same data source. Barring unknown bugs, that it does, shows two different time-slices are being viewed here.

Intel XHC controller -

You now have a Sharkoon HDD caddy with a Samsung drive attached to a USB3.0 port, so I guess this Intel controller is working fine. As with your iPad and Fireface UC on USB2.0.

...>