The New Beginner's Guide to USB Port Configuration

[lms]

No. You are not able to replicate this using an SSDT. I can give you technical reasons if you'd like but it might be boring.

I can see why you might think so, because we do create an embedded controller with SSDT-EC.aml etc. The difference is with EHCI and XHCI we are rerouting already existing controllers.

Basically there are very specific use cases for FakePCIID_XHCIMux.kext.

Remember you also need FakePCIID.kext to create and attach the new device you are going to spoof.

What is the "quirk" with 7/8/9 chipsets you are referring to?

Just use Hackintool as per the guide and maybe read the older one which does cover mixed controller setups etc.

From RehabMan's GitHub:


FakePCIID_XHCIMux.kext This kext will attach to 8086:1e31, 8086:9c31, 8086:9cb1, 8086:9c31, and 8086:8cb1 This injector is a bit of an extension to normal FakePCIID duties. It doesn't actually fake any PCI IDs. Rather, it forces certain values to XUSB2PR (PCI config offset 0xD0) on the Intel XHCI USB3 controller. The effect is to route any USB2 devices attached to the USB2 pins on the XHC ports to EHC1. In other words, handle USB2 devices with the USB2 drivers instead of the USB3 drivers (AppleUSBEHCI vs. AppleUSBXHCI).


So normally what is a complex "multiplex" DSDT patch (that is not well understood), is a simple kext install.


Configuration properties and their defaults: RM,pr2-force <00 00 00 00>. By default forces all XHCI ports to route USB2 devices to EHC1. RM,pr2-init <01>. Will write RM,pr2-force value at startup if non-zero. RM,pr2-block <01>. Will block writes to XUSB2PR if non-zero. RM,pr2m-block <01>. No evidence that OS X drivers attempt to write XUSB2PRM (offset 0xD4), but since this kext relies on a valid value here (as provided by the BIOS), writes to it are blocked if non-zero. RM,pr2-honor-pr2m <01>: Changes to XUSB2PR will be masked by XUSB2PRM if this is non-zero. RM,pr2-chipset-mask: Writes to XUSB2PR are masked by this value. This is defined by the chipset documentation. Default value depends on chipset.


Refer to Intel 7/8/9-series chipset data sheet for more info



-----------


Using this on my Z97, I have 17 (16 external, 1 internal wifi/BT) USB ports working. 6 USB 3.0 which is a total of 12 ports and 4 USB 2 ports.

Since he mentioned the 7/8/9 chipset in particular I presume this is something unique to those.

 

[UtterDisbelief]

From RehabMan's GitHub:


FakePCIID_XHCIMux.kext This kext will attach to 8086:1e31, 8086:9c31, 8086:9cb1, 8086:9c31, and 8086:8cb1 This injector is a bit of an extension to normal FakePCIID duties. It doesn't actually fake any PCI IDs. Rather, it forces certain values to XUSB2PR (PCI config offset 0xD0) on the Intel XHCI USB3 controller. The effect is to route any USB2 devices attached to the USB2 pins on the XHC ports to EHC1. In other words, handle USB2 devices with the USB2 drivers instead of the USB3 drivers (AppleUSBEHCI vs. AppleUSBXHCI).


So normally what is a complex "multiplex" DSDT patch (that is not well understood), is a simple kext install.


Configuration properties and their defaults: RM,pr2-force <00 00 00 00>. By default forces all XHCI ports to route USB2 devices to EHC1. RM,pr2-init <01>. Will write RM,pr2-force value at startup if non-zero. RM,pr2-block <01>. Will block writes to XUSB2PR if non-zero. RM,pr2m-block <01>. No evidence that OS X drivers attempt to write XUSB2PRM (offset 0xD4), but since this kext relies on a valid value here (as provided by the BIOS), writes to it are blocked if non-zero. RM,pr2-honor-pr2m <01>: Changes to XUSB2PR will be masked by XUSB2PRM if this is non-zero. RM,pr2-chipset-mask: Writes to XUSB2PR are masked by this value. This is defined by the chipset documentation. Default value depends on chipset.


Refer to Intel 7/8/9-series chipset data sheet for more info



-----------


Using this on my Z97, I have 17 (16 external, 1 internal wifi/BT) USB ports working. 6 USB 3.0 which is a total of 12 ports and 4 USB 2 ports.

Since he mentioned the 7/8/9 chipset in particular I presume this is something unique to those.

Okay, then. Sorry I couldn't help.

All my work is based on the foundations @RehabMan laid. I just try to explain and update where I can.

This guide is a newer one, using more modern techniques. Perhaps you might post in the thread you quote from instead.

 

[MadDan]

Not lame at all.

There is a new problem with the listed Mojave port-limit removal patches in that they only work up until the initial release of 10.4.6. Since then Apple has brought out further versions as Security Updates and there are no new patches that work with them installed as everyone seems to have moved on.

What most did was move to OpenCore and it's XhciPortLimit quirk instead. This actually has been added to the latest Clover releases I believe, as an alternative to patching.

There are now new problems with even this, but only for Big Sur 11.3+.

After a needed vacation break, got back to my USB Ports config. Went thru this process a couple times using different PLRP's. I was able to configure my missing SS ports (SS07 & SS08), so I'm further along than where I was with previous attempts. I now have all my USB 2.0 and 3.0 ports mapped, and working. But as I encountered last year, still unable to configure my lone USB Type-C port. Plugging in a USB-C device did not activate any of the unused SS ports as shown in Hackintool. I tried both connector TypeC and TypeC+Sw (exporting USBPorts.kext, then booting with the updated kext in Other) but the device never activated. I did try several USB cables to eliminate a cable issue. To conclude, I have several questions please:

1) Is there anything else I can do to attempt to discover the missing USB-C port? Not a "big" issue since I can use the other ports for device connection.

2) Since all my 2.0 and 3.0 ports are working and defined in USBPorts.kext, can I proceed to apply future security updates? As you mentioned above, future PLRP's wont work due to recent security updates. I'm on 10.14.6, with plans to upgrade to Catalina at some point. If so, I trust my current USBPorts.kext will still work with future security updates, and OSX upgrades. No PLRP's are active in my Config.plist.

Screen shots below of my current USBPorts mapping.
Cheers!

 

[Edhawk]

First off the four ports you have designated as USB2 are in fact served from USB3 physical ports so they should have the USB3 designation not USB2. The four ports are highlighted in the screenshot below.

Change the four ports highlighted from USB2 to USB3 connector type.

Your Motherboard contains the following USB ports/headers:



So based on this you should have the following ports in your USB setup:

• The Type-C port on your motherboard is on the rear I/O plate. So should use the Type-C (0x09 (9)) connector type. There will be a USB2 virtual port as well as the USB3.1 Gen 1 port, so 2 ports in total. The USB2 side of the Type-C port is not always used, but can come in handy if you connect an external Hub to the Type-C port.
• The four USB3.1 Gen 1 ports on there rear panel will give a total of 4 physical USB3 ports and 4 virtual USB2 ports. So a total of 8 ports.
• The USB3.1 Gen 1 header will provide 2 x USB3 and 2 x USB2 ports, so a total of 4 ports.
• the USB2 Header can provide 2 USB 2 ports, but as you have your Fenvi Bluetooth module attached to this port only one will be available.

Based on this your setup should have a maximum of 15 USB ports, which are made up of 7 Physical ports and 7 virtual ports and the single Internal Header port you have already identified as HS09.

I believe the four USB3 ports on the rear panel (I/O plate) are covered by HS01, HS02, HS07, HS08, SS01, SS02, SS07 and SS08.

You should have another 4 ports serving two USB3 front case ports, assuming your case has any USB3 ports on the front for easy access. Which case are you using for this system?

Based on the above you are currently only activating 9 ports from a possible 15. So you need to undertake the USB port discovery process again, to find and identify the other ports.

 

[MadDan]

First off the four ports you have designated as USB2 are in fact served from USB3 physical ports so they should have the USB3 designation not USB2. The four ports are highlighted in the screenshot below.

View attachment 522120 Change the four ports highlighted from USB2 to USB3 connector type.

Your Motherboard contains the following USB ports/headers:

View attachment 522121

So based on this you should have the following ports in your USB setup:

• The Type-C port on your motherboard is on the rear I/O plate. So should use the Type-C (0x09 (9)) connector type. There will be a USB2 virtual port as well as the USB3.1 Gen 1 port, so 2 ports in total. The USB2 side of the Type-C port is not always used, but can come in handy if you connect an external Hub to the Type-C port.
• The four USB3.1 Gen 1 ports on there rear panel will give a total of 4 physical USB3 ports and 4 virtual USB2 ports. So a total of 8 ports.
• The USB3.1 Gen 1 header will provide 2 x USB3 and 2 x USB2 ports, so a total of 4 ports.
• the USB2 Header can provide 2 USB 2 ports, but as you have your Fenvi Bluetooth module attached to this port only one will be available.

Based on this your setup should have a maximum of 15 USB ports, which are made up of 7 Physical ports and 7 virtual ports and the single Internal Header port you have already identified as HS09.

I believe the four USB3 ports on the rear panel (I/O plate) are covered by HS01, HS02, HS07, HS08, SS01, SS02, SS07 and SS08.

You should have another 4 ports serving two USB3 front case ports, assuming your case has any USB3 ports on the front for easy access. Which case are you using for this system?

Based on the above you are currently only activating 9 ports from a possible 15. So you need to undertake the USB port discovery process again, to find and identify the other ports.

Ed,

Thank you kindly for the reply! First off, as you recommend, I will change the four USB2 ports to connector type USB3 (physical ports). The four USB 3.1 ports located on the rear panel are mapped correctly as HS01, HS02, HS07, HS08, SS01, SS02, SS07 & SS08. The USB2 header (HS09) is being used to connect my Fenvi BT card, therefore my front USB 2 ports are not connected. I assume HS10 would be the other port, and not needed? The USB 3.1 header is not being used, and have no plans to use it. Therefore, how would I discover these ports? The lone Type-C port on the rear panel has yet to respond to any device plugged into it. Trusting it's not a hardware issue, but rather a discovery issue?

Below is a screenshot showing the result of USBInjectAll.kext (v0.7.3) and PLRP's. I've seen a post on another site where PLRP's have been maintained for the appropriate installed OSX. I used those Mojave PLRP's as well as ones identified on this site. Both attempts yielded the same ports for discovery. Do you suspect my process is impeded due to applied OSX security updates as @UtterDisbelief suggests?

Any additional advice greatly appreciated!

 

[Westsurf]

Would anyone be able to advise why when I set a newly installed Fenvi T919 card the USB port I’ve plugged it in to use the Bluetooth when set to internal it disappears with the newly generated kext?

My understanding is that to avoid issues it must be set to internal.

EDIT - New USB mapping kext, with USB port as juts USB2, has the BROADCOM bluetooth appear in Hackintool and system report. However it seems that I can't connect to bluetooth devices such as my Airpods. [SOLVED] Bluetooth working. If in doubt NVRAM reset.

 

[Edhawk]

@MadDan the port discovery image from Hackintool looks correct, showing the ports for the controller before they are identified.

Regarding the Type-C port, I would suggest you open IORegistry Explorer, plug in the Type-C USB drive and see which port activates under the XHC controller. It might be easier to identify when it is ejected, as the port information will be struck through and the text colour will change. You can then manually identify the port in Hackintool if it doesn’t show do it automatically.

 

[MadDan]

@MadDan the port discovery image from Hackintool looks correct, showing the ports for the controller before they are identified.

Regarding the Type-C port, I would suggest you open IORegistry Explorer, plug in the Type-C USB drive and see which port activates under the XHC controller. It might be easier to identify when it is ejected, as the port information will be struck through and the text colour will change. You can then manually identify the port in Hackintool if it doesn’t show do it automatically.

Ed,
Thanks for the reply. Per your suggestion, I redid the port discovery process. As before, no USB Type-C port was discovered. I first used an external SSD (USB-C to USB-C cable). The drive does not light up, no power indicator. If I use a USB-C to USB 3.1 cable, the drive works. I then used my iPad with its USB-C to USB-C cable; again no connection. In both cases, nothing appears in IOReg, Hackintool, or in Finder. Assuming all ports were visible for discovery, I must conclude my hardware is at fault?
Since my build is a mini, I can live w/o the USB Type C port. Regarding the unused USB 3.1 Header, since I can't map its respective ports, I opted to remove all the undiscovered ports. So I'm left with 9 out of 15 available ports. That is what I've exported in Hackintool to create a working USBPorts.kext. At this point, I feel Ive exhausted all attempts to configure additional ports, and should now move on. Are there any issues with doing so? I want to be able to apply future security updates, as well as move on from Mojave 10.14.6. Just want some insurance from the tech desk that my build is as good as it will be from a USB perspective. Screen shots below showing the PLRP's, all ports discovered in IOReg & Hackintool, and my finished product. As before, thank you for any sage technical advice!

 

[Edhawk]

I would go with a defective USB Type-C port on the motherboard, as I doubt both cables are defective.

There are no issues moving forward with the 9 working ports. Final screenshot looks good based on your system and setup.

1. Export the USB configuration from Hackintool.
2. Add the new USBPorts.kext to your /CLOVER/kexts/Other folder.
3. Remove USBInjectAll.kext from the /CLOVER/kexts/Other folder.
4. Remove/disable the USB port limit patches in the config.plist, and
5. Reboot the system.
6. Then test the 9 USB ports to make sure they are all working as expected.

Job should be done.

 

[legaleye3000]

Hello all - Can't get any usb ports to work. On Big Sur 11.4, USBInjectALL version 0.7.6 installed, and XHCIPortLimit is enabled. The PLR patches for Catalina are entered and enabled based on first post in this thread. HackinTool shows only 1 port active (in green). See screen shot attached. Any help appreciated. Thank you!