Contribute
Register

USB MAPPING - ASUS X99A/USB3.1

Status
Not open for further replies.
Joined
Aug 19, 2010
Messages
46
Motherboard
I still didn't
CPU
read the
Graphics
Rules!
Mac
  1. MacBook
  2. Mac mini
  3. Mac Pro
Classic Mac
  1. Power Mac
  2. PowerBook
Mobile Phone
  1. Android
USB seems to be the biggest problem with El Capitan and I imagine subsequent OS X versions. In the past few weeks I have read a lot from various people, many of whom have done some great work.

One of the posts that I thought provided a logical approach was that by Xavi16 where he took time to map the ports on the Asus Rampage V Extreme. This inspired me to do the same with my Asus X99a/USB3.1. I also felt that I should give a little back to these great web sites that help us all.

To do this, I used a free program called USB Tree Viewer (not to be confused with USBView). This gives a lot more information that seems relevant to OS X. The only downside is that you have to do a Windows installation.

I am under the impression that USB Tree Viewer has not been updated for a long time as it really didn't like the USB 3.1 ports on my board! I'm not too worried about them, really as I will be using the on-board M.2 interface and these ports are disabled when using a 28-lane possessor, which I am (5820k).

I have learnt a lot from doing this and also from the extensive amount of work done by others. Here are some points which I hope will be helpful to others:

1. There is a difference between 'physical' posts actually on the motherboard and 'logical' ports as used by the operating system.

2. I believe that one the reason USB looks messed up in the Apple System Profiler is because OS X doesn't negotiate the built-in hubs properly. We are used to seeing everything connected under USB 3.0, for example which obviously incorrect.

Using RehabMan's FakePCIID.kext and FakePCIID_XHCIMux.kext you can go some way to getting things sorted out. Ideally however, I think that the kexts need to be edited for your specific motherboard.

I'm not sure where to go from here. Having the information is one thing but knowing what to do with it is another. I think I am going to have either edit my DSDT or some of RehabMan's kexts or both.

Once I get my X99A/USB3.1 running smoothly, I intend to perform the same remapping exercise on my old Gigabyte GA-X79-UD3.

It would fantastic if others could do the same with their motherboards. I have made my USB mappings available here for anyone else who has an Asus X99a/USB3.1 or who may find it useful.

EDIT: The screen grab of USB Tree Viewer was taken AFTER I disabled USB3.1 in BIOS as I am now switching to OS X.
 

Attachments

  • USB Tree View - Asus X99a USB3.1.jpg
    USB Tree View - Asus X99a USB3.1.jpg
    203.3 KB · Views: 516
  • USB Mapping - Asus X99A USB3.1 (2016.08.26).pdf
    150.8 KB · Views: 2,769
Last edited:
USB seems to be the biggest problem with El Capitan and I imagine subsequent OS X versions. In the past few weeks I have read a lot from various people, many of whom have done some great work.

One of the posts that I thought provided a logical approach was that by Xavi16 where he took time to map the ports on the Asus Rampage V Extreme. This inspired me to do the same with my Asus X99a/USB3.1. I also felt that I should give a little back to these great web sites that help us all.

To do this, I used a free program called USB Tree Viewer (not to be confused with USBView). This gives a lot more information that seems relevant to OS X. The only downside is that you have to do a Windows installation.

I am under the impression that USB Tree Viewer has not been updated for a long time as it really didn't like the USB 3.1 ports on my board! I'm not too worried about them, really as I will be using the on-board M.2 interface and these ports are disabled when using a 28-lane possessor, which I am (5820k).

I have learnt a lot from doing this and also from the extensive amount of work done by others. Here are some points which I hope will be helpful to others:

1. There is a difference between 'physical' posts actually on the motherboard and 'logical' ports as used by the operating system.

2. I believe that one the reason USB looks messed up in the Apple System Profiler is because OS X doesn't negotiate the built-in hubs properly. We are used to seeing everything connected under USB 3.0, for example which obviously not correct.

Using RehabMan's FakePCIID.kext and FakePCIID_XHCIMux.kext you can go some way to getting things sorted out. Ideally however, I think that the kexts need to be edited for your specific motherboard.

I'm not sure where to go from here. Having the information is one thing but knowing what to do with it is another. I think I am going to have either edit my DSDT or some of RehabMan's kexts or both.

Once I get my X99A/USB3.1 running smoothly, I intend to perform the same remapping exercise on my old Gigabyte GA-X79-UD3.

It would fantastic if others could do the same with their motherboards. I have made my USB mappings available here for anyone else who has an Asus X99a/USB3.1 or who may find it useful.

EDIT: The screen grab of USB Tree Viewer was taken AFTER I disabled USB3.1 in BIOS as I am now switching to OS X.

Ideally, you should install USBInjectAll.kext and create a custom SSDT to configure it (there are many examples/guides, and there is SSDT-UIAC-ALL.dsl to use as a template), such that only ports that are used are injected and the UsbConnector value is correct for each port. I use IORegistryExplorer to determine which ports are actually used, so no need for Windows.
 
Ideally, you should install USBInjectAll.kext and create a custom SSDT to configure it (there are many examples/guides, and there is SSDT-UIAC-ALL.dsl to use as a template), such that only ports that are used are injected and the UsbConnector value is correct for each port. I use IORegistryExplorer to determine which ports are actually used, so no need for Windows.
Wow!!!! That's got to be the quickest reply ever, LOL.

I didn't have much luck with IOREG or IOO Jones. USB Tree Viewer was pretty good although as you might see from my results, it couldn't make sense of the USB3.1 ports. That wasn't particularly important for me as they're knocked out as soon as I use the NVMe with my 5820k (28-lane) processor.

Okay. You've basically said what I thought I had to do, especially after reading some of your other stuff; USBInjectAll and another SSDT. Cool. Thank you again.
 
Wow!!!! That's got to be the quickest reply ever, LOL.

I didn't have much luck with IOREG or IOO Jones. USB Tree Viewer was pretty good although as you might see from my results, it couldn't make sense of the USB3.1 ports. That wasn't particularly important for me as they're knocked out as soon as I use the NVMe with my 5820k (28-lane) processor.

Okay. You've basically said what I thought I had to do, especially after reading some of your other stuff; USBInjectAll and another SSDT. Cool. Thank you again.

How to use IORegistryExplorer for port discovery:
- install USBInjectAll.kext
- make sure your DSDT uses the correct names for the EHCI and XCHI controllers: EH01/EH02/XHC
- use the port limit patch if your XHCI controller has more than 15 ports (X99, probably not)
- reboot
- verify in ioreg that all ports are injected at EH01/EH02/XHC
- keep IORegistryExplorer running
- plug a USB2 device into each USB2 and USB3 port available (including internal ports you plan to use)
- plug a USB3 device into each USB3 port available (including internal ports you plan to use)
- it is not necessary to have all ports populated at once (and it is impossible anyway)
- now check ioreg, EH01/EH02/XHC nodes
- the nodes/ports that are populated (either green or red or black if plugged in when IORegistryExplorer was first started) were used
- ports without any child nodes were not used and therefore can be excluded from the SSDT
- build your custom SSDT for USBInjectAll using SSDT-UIAC-ALL.dsl as a template
- set UsbConnector as appropriate (read the ACPI spec regarding _UPC)
- be sure to modify the correct configuration data based on your controller device-ids (EH01/EH02/HUB1/HUB2/XHC)
- install the SSDT to ACPI/patched
- make sure the SSDT is called out by SortedOrder if you're using it
- verify in ioreg that the expected ports are injected and that UsbConnector is correct for each
- test your ports
- if you need to boot with all ports injected again, you can do so with -uia_ignore_rmcf, which will cause USBInjectAll.kext to ignore the configuration data in your custom SSDT
 
Last edited:
How to use IORegistryExplorer for port discovery:
- install USBInjectAll.kext
- make sure your DSDT uses the correct names for the EHCI and XCHI controllers: EH01/EH02/XHC
- use the port limit patch if your XHCI controller has more than 15 ports (X99, probably not)
- reboot
- verify in ioreg that all ports are injected at EH01/EH02/XHC
- keep IORegistryExplorer running
- plug a USB2 device into each USB2 and USB3 port available (including internal ports you plan to use)
- plug a USB3 device into each USB3 port available (including internal ports you plan to use)
- it is not necessary to have all ports populated at once (and it is impossible anyway)
- now check ioreg, EH01/EH02/XHC nodes
- the nodes/ports that are populated (either green or red) were used
- ports without any child nodes were not used and therefore can be excluded from the SSDT
- build your custom SSDT for USBInjectAll using SSDT-UIAC-ALL.dsl as a template
- set UsbConnector as appropriate (read the ACPI spec regarding _UPC)
- be sure to modify the correct configuration data based on your controller device-ids (EH01/EH02/HUB1/HUB2/XHC)
- install the SSDT to ACPI/patched
- make sure the SSDT is called out by SortedOrder if you're using it
- verify in ioreg that the expected ports are injected and that UsbConnector is correct for each
- test your ports
- if you need to boot with all ports injected again, you can do so with -uia_ignore_rmcf, which will cause USBInjectAll.kext to ignore the configuration data in your custom SSDT
Oh WOW! Thanks again, Rehab. This is awesome! It's gone 1:00 in the morning here and I have a family BBQ thing tomorrow but I really can't wait to try this now.

It's the hubs that get me worried but I will make a start and see how it all goes. Have a lovely weekend.
 
It's the hubs that get me worried but I will make a start and see how it all goes. Have a lovely weekend.

There is special support in USBInjectAll.kext for the hubs at EH01.PR11 and EH02.PR21 (the first port on each EHCI controller).
They are configured via HUB1 and HUB2 packages.

There is no UsbConnector recognized for hub ports, but there is portType, which is currently not understood (does not seem to use _UPC values).
 
There is special support in USBInjectAll.kext for the hubs at EH01.PR11 and EH02.PR21 (the first port on each EHCI controller).
They are configured via HUB1 and HUB2 packages.

There is no UsbConnector recognized for hub ports, but there is portType, which is currently not understood (does not seem to use _UPC values).
I think I understand. Hopefully everything you've said will make a lot more sense when I'm sitting in front of my machine. Like I said, I can't wait to try this now.

One question; I'm only using XHCI-x99-injector.kext. Will I have to remove this when I install USBInjectAll.kext to map the ports as you suggest?
 
Last edited:
Hey everyone, please take note of what RehabMan has said and why I am a little skeptical when people say that everything is working.

I have been using Logitech optical mice since my G4 days. My favorite is the M510. I however, really am not a fan of Logitech drivers and also since my G4 days, I've been using a great little a program called USB Overdrive. Under El Capitan, all my USB ports seem to be working and yet, when I look under devices in the USB Overdrive control panel, I see two receivers!

I cannot afford to have messy USB as MIDI is a really important aspect of what I do. This is why I am taking a little time to suss this out properly.

Xavi16 has taken a similar approach with his Rampage V Extreme build and although I'm new to DSDT and SSDT, even I can see that he's going along the same lines as RehabMan and has followed the same approach I intend to take. In fact after RehabMan it was his detailed build explanation that inspired me down this route.

I did have time today to sneak out for a couple of hours and make a start. Hey RehabMan... loads of questions already, dude!!!

I'm not sure what I'm supposed to be looking for in IOREG. For a start, I'm assuming that I'm looking under 'USB'.

Also and as I thought, IOREG behaves differently under 10.11 as it does under 10.10, like your USB inserts don't bump up green. They do change red when you remove.

The little time I spent on this earlier today, was occupied with me trying to figure out specifically what information I'm actually after.

I've also had time to look at your SSDT template. Wow, that's cool. The first thing I've noticed is the USBConnector. Is this a number one makes up for one's own reference or is it pulled from data shown in IOREG?

This is why I used USB Tree View under Windows as the results contained references which I recognized in other related posts; HSxx, SSPx, PRTx, etc.

I'm so sorry for all the questions but I hope you understand why.
 
Also and as I thought, IOREG behaves differently under 10.11 as it does under 10.10, like your USB inserts don't bump up green. They do change red when you remove.

IORegistryExplorer is the same on 10.11 and 10.10.

Nodes that exist when you first run IORegistryExplorer are black.
New nodes are in green (eg. nodes that appeared since you started IORegistryExplorer)
Nodes that were there but were unplugged/disconnected/unloaded are shown in red.

I've also had time to look at your SSDT template. Wow, that's cool. The first thing I've noticed is the USBConnector. Is this a number one makes up for one's own reference or is it pulled from data shown in IOREG?

It is the port type. See ACPI spec for _UPC.
 
IORegistryExplorer is the same on 10.11 and 10.10.

Nodes that exist when you first run IORegistryExplorer are black.
New nodes are in green (eg. nodes that appeared since you started IORegistryExplorer)
Nodes that were there but were unplugged/disconnected/unloaded are shown in red.



It is the port type. See ACPI spec for _UPC.
Thank you again, RehabMan.

I'm running IOREG 2.1. When I stared this, you asked for an IOREG file and specified version 2.1. I will try a newer version.

Ah, right... the port type! Yeah, I've seen that. Thanks, again.
 
Status
Not open for further replies.
Back
Top