Contribute
Register

The New Beginner's Guide to USB Port Configuration

Appendix #3

This guide concentrates on the XHCI controller all modern Intel chipsets have. Some older motherboards feature chipsets with both the previous EHCI standard and the newer XHCI. Even older still might have just two EHCI. If you see three lines in the top panel of Hackintool with two EHC and one XHC controller then prioritise the XHC because this is where USB3.0 comes from. If you only see two EHC controllers then your system is stuck at USB2.0. You can use these ports though, as you move to the next stage. For more information on these see my original guide as you will need to put some renames in place in your config.plist.


Thanks for the guide! it's a great piece of work and helpful people like you deserve a whole LOT of credit. Really...

A quick question: let's say I'm using an older chipset that has both XHCI and EHCI controllers but I only want to use the USB ports managed by the XHCI controller and not bother with the USB2.0 ports from the EHCI controller(s).
Would it be OK to just omit the renames (and thus macOS would not detect these ports at all)? Or should I go through the renames and then delete all those EHCI-related USB2.0 ports using hackingtool?

Tx
-a-
 
Final Technical Note: Because Apple is reigning-in on what 3rd-party kexts can be installed, it was initially worrying that using any form of kext installation to modify the ACPI/USB ports could get blocked in future. However by putting our USBPorts.kext in the EFI/ or OC/ folder macOS doesn't 'see' it. What's more, if you run kextstat from Terminal you will notice that although other kexts are visible to macOS, USBPorts.kext is not. My take on this is because there is no 'executable' within it's container.


I was taught to put all my kexts into L/E and only the minimum (those kexts required to be able to reach the recovery partition) into E/C/K/O while setting clover to "detect" for kexts injection (kexts in E/C/K/O are only injected if L/E is NOT detected).
It's seems like you say now that it's better to leave L/E vanilla and put every 3rd party kexts into E/C/K/O while setting kexts injection to "YES" in clover configurator (kexts in E/C/K/O are injected no matter what), right? Can you please confirm? Or have I misunderstood something?

Tx
-a-
 
Last edited:
I was taught to put all my kexts into S/L/E and only the minimum (those kexts required to be able to reach the recovery partition) into E/C/K/O while setting clover to "detect" for kexts injection (kexts in E/C/K/O are only injected if S/L/E is NOT detected).
It's seems like you say now that it's better to leave S/L/E vanilla and put every 3rd party kexts into E/C/K/O while setting kexts injection to "YES" in clover configurator (kexts in E/C/K/O are injected no matter what), right? Or did I misunderstood something?

Tx
-a-
only Apple system kexts belong in /S/L/E

3rd party kexts would go in /L/E
 
2) Your motherboard features a Renesas USB chipset alongside the Intel to give more USB3 speed ports than the Z97 alone provides. This creates "hubs" totalling 4-ports on the back-panel. You can see them in your IORegistryExplorer output and in the Hackintool screengrab - they have the "IOUSBHostDevice" label on them. Generally you will not be able to configure Renesas controlled ports, however in this set-up they are actually supplementing the Intel ports by adding USB3 functionality to some of the USB2 ports to give you more.

Could you please elaborate on the red part?
What is wrong with Renesas controlled ports? Or Renesas controllers
What does it mean exactly to be unable to configure them? What are the consequences?

Thanks a lot :)
-a-
 
With this to hand we can now remove ports from the Hackintool list that we do not need so that we can get down to the magic number of 15 as stipulated by Apple.

(...)

Appendix #2

Please bear in mind Port-Limit Removal Patches are not designed for permanent use because they overwrite and go beyond areas of memory set aside for the job by Apple. Think of your USB ports like a box of a dozen eggs, two rows of six. When full the lid closes and all is safe. If you put another five eggs in down the centre, they appear to fit perfectly - but now you can't close the lid. Things can fall out and break.

In short, long-term use of the patch means data loss and system crashes are only a whisker away.

Probably out of the scope of this guide but maybe you could briefly answer this:
What would happen if one would buy one of the newest MacPros and add a bunch of PCIe USB3 controllers in it, exceeding the 15 ports limit... I guess it would work fine, right?
Would it be because all these extra USB3 ports would be downstream an USB hub or something?

Related question: If I have 15 USB ports on my hackintosh but then add an USB hub on one of them. These extra ports would work fine, right? No need to go through the whole guide once again and re-set all the USB ports, right?

Thanks for your help and excuse my ignorance.

Best,
-a-
 
only Apple system kexts belong in /S/L/E

3rd party kexts would go in /L/E
Right, my bad (typo) I'll edit the above post and correct it.

NOTE:
from this guide:
2. Where should I install 3rd Party Kexts ?

You should install all 3rd Party kexts (including FakeSMC) to /Library/Extensions (/L/E)
Warning: you can not simply use Finder to copy kexts into /L/E (see Section 7 below)



3. What about EFI/Clover/kexts/Other ?

It seems that many users are under the impression that you can simply copy all 3rd Party Kexts into EFI/Clover/kexts/Other and allow Clover to Inject the kexts by setting Clover -> System Parameters -> Inject Kexts to "Yes" which will result in a maintenance free and more native MacOS install.

This assumption is completely wrong ...



4. Why should I use /Library/Extensions over Clover Injected kexts ?

Contrary to Hackintosh myth, having Clover inject all the 3rd party kexts does not result in a cleaner install, in fact the exact opposite is true.

  • Injected Kexts live outside of "protected MacOS memory" *
  • Injecting a large amount of kexts can result in an unstable system.
  • Many 3rd party kexts will not work correctly when injected by Clover.
  • Injected Kexts are not included in the kernel cache and thus are excluded form MacOS error checking.
  • Installing kexts in /Library/Extensions is the Apple endorsed and recommended location for all 3rd Party kexts.
If you purchase a piece of hardware that requires the installation of a manufactures MacOS driver, the kexts will be installed in /Library/Extensions so why treat hackingtosh kexts any different ?

* Note: I use the term "protected MacOS memory" in this guide as a generic descriptive term. In reality kext's installed in /L/E are loaded into MacOS's kernel memory which is 'protected' (IE: segregated) form application memory and execution memory. Everything running in kernel memory (including kexts) is actively managed and monitored by MacOS.
 
thanks for the guide, however i had much better luck just following the steps listed in Hackintool in the USB section help.

the reasons why:
I needed to run 2 passes, one with uia_exclude on my SS ports, and one for my HS ports (as listed in the Hackintool help steps).

Also it wasn't 100% clear in the guide that Hackintool actually stores the USB ports state across reboots, and that you need to clear all and refresh in order to start over and/or get the current ports. This is good as it allows you to build a full list of ports by rebooting with different sets of ports excluded, but if you dont realize that and think you're getting a "live" readout of your current ports like you do in IOReg, it can be very confusing.
 
thanks for the guide, however i had much better luck just following the steps listed in Hackintool in the USB section help.

the reasons why:
I needed to run 2 passes, one with uia_exclude on my SS ports, and one for my HS ports (as listed in the Hackintool help steps).

Also it wasn't 100% clear in the guide that Hackintool actually stores the USB ports state across reboots, and that you need to clear all and refresh in order to start over and/or get the current ports. This is good as it allows you to build a full list of ports by rebooting with different sets of ports excluded, but if you dont realize that and think you're getting a "live" readout of your current ports like you do in IOReg, it can be very confusing.

It is always a learning curve following a set of instructions, the Hackintool ones are very straightforward, but on the other hand it is good to get a bit of background knowledge so you know what you are actually tweaking. Either way I used both and finally have my USB ports fully functioning. Something which isn't mentioned within Hackintool and the port configuration is the current, which can implemented to operate correctly as well.
 
So this might be a silly question.

But say I have an external USB 3.0 hub that I use with both USB 3.0 and USB 2.0 devices.

On the port that the hub is connected to on my hack, do I need to enable the HS and SS ports for USB 2.0 devices to work on the hub?
 
Back
Top