Contribute
Register

XHC USB Kext Creation Guideline

Status
Not open for further replies.
By default, macOS does not implement more than 15 HS/SS ports. With a working port limit kext patch, which always is macOS version dependent and requires an update after each macOS update (non-vanilla), you can circumvent Apple's 15-port USB limit and implement more than 15 HS/SS ports (not recommended though and not possible under all macOS versions.) I strongly recommend to use a truncated 15-port XHC USB kext instead and to disable any USB port limit kext patch in your config.plist. This will make your system more vanilla and will prevent possible buffer overruns induced by the USB port limit kext patch. The fully implemented XHC USB kext allows the subsequent drop of specific HS/SS ports up to the taste of each user.

Clear enough?

Clear enough! Thanks for that. I'll follow your recommendation and disable HS07/HS08 since I'd like to play around with OpenCorsairLink. ;-)
 
  • Like
Reactions: kgp
it's done ..... but I don't know what's the matter??

a moment ago usb is in eh01/eh02 .but now in xhci.... why??

and I use Hackintool export the kext and it's done....
all.png


ss.png

qqq.png

20190117230710.png
 

Attachments

  • USBPorts.kext.zip
    1.2 KB · Views: 71
it's done ..... but I don't know what's the matter??

a moment ago usb is in eh01/eh02 .but now in xhci.... why??

and I use Hackintool export the kext and it's done....
View attachment 379999

View attachment 379993
View attachment 379995
View attachment 379997

Because you did not use my X99 EFI-Folder distribution but at most a deviation of it. The ACPI replacements in the config.plist are crucial and the ones you previously used have been wrong! If you rename XHC or XHCI to EH01 or EH02, the XHC USB kext won't work.

Still your XHCI implementation is inadequate! You miss most of the HSxx ports implemented in the original James-Asrock-X99M-Killer-3.1-iMacPro-XHCI-15port.kext, i.e. HS01,HS02, HS06, HS07, HS08, HS09 and HS10. Did you remove them from the kext?? By this, most of your USB2.0 ports will be non-functional and your USB3.0 ports will not be backwards compatible with USB2.0. BTW.. The kext you attached above is not at all James-Asrock-X99M-Killer-3.1-iMacPro-XHCI-15port.kext but contains a weird EH02 and XHCI implementation!

Try to understand the technical principals before spamming all related threads with unnecessary questions. Is it really that difficult to follow and strictly stay with the respective instructions? Nobody is able to help if you do not stay with the respective instructions.

I really would recommend to start from scratch. Strictly use my X99 EFI-Folder distribution + a properly adopted TSCAdjustReset.kext + James-Asrock-X99M-Killer-3.1-iMacPro-XHCI-15port.kext. Ensure that your MSR is unlocked, else enable the XCPM_core_sope kernel patch and KernelPM. You already implemented all necessary modifications for your Haswell-E, thus else, this slightly modified EFI-Folder configuration should run OoB, including XHCI!

Take your time, carefully read all my respective guides and come back with remaining questions, if still necessary. If you opt for different approaches than the ones presented here, post your issues elsewhere.

Good luck,

KGP
 
Last edited:
@kgp sorry kgp my English is very bad 。and I don't understand what you said . I read your article once need 3days more
I used 3usb2.0 and 4 usb3.0
 
I am afraid, there are still several inconsistencies in your kexts.
View attachment 379866

Apart from minor cosmetic modifications, I also performed the following substantial modifications:

Fully implemented kext (18 ports):

1.) IONameMatch: XHC -> XHCI
2.) Removal of SS07 -> SS10
3.) SSxx -> SSPx
4.) Removal of HS13/HS14
5.) port-count: 0a000000 -> 16000000

Truncated 15-port kext:

For its most general application, I actually dropped one back-panel USB2.0 connector (HS08) and one internal USB2.0 header (HS11/HS12) in the truncated 15-port kext. By this there is still one USB 2.0 back-panel connector (HS07) and one internal USB2.0 header (HS09/HS10) operational. All USB3.0 external connectors and the only USB3.0 internal header are fully operational in addition.

Please test and verify the attached kexts. In case that everything works as expected, I will upload both kexts to the XHC USB Kext Github library.

Cheers,

KGP

Edit: There was still a minor inconsistency in the 15-port kext, which I previously uploaded. SSxx -> SSPx and modified file reloaded.
OK, i thought the fully implemented kext should include everything. IORegistryExplorer shows me SS10 as last port. That's why i renamed them from SSPx to SSxx. If you only want 6 of them, this is not necessary.

I can try your kexts tomorrow.

I am not sure if XHCI is the right IONameMatch. In IORegistryExplorer it is also called XHC and my kexts didn't work if i used XHCI on this board. I´ll try again.

Just for understanding: What i the use of the 18Port Kext, when we can only use 15? Is there a new way to go over Portlimit, that i missed?
 
OK, i thought the fully implemented kext should include everything. IORegistryExplorer shows me SS10 as last port. That's why i renamed them from SSPx to SSxx. If you only want 6 of them, this is not necessary.

I can try your kexts tomorrow.

I am not sure if XHCI is the right IONameMatch. In IORegistryExplorer it is also called XHC and my kexts didn't work if i used XHCI on this board. I´ll try again.

Just for understanding: What i the use of the 18Port Kext, when we can only use 15? Is there a new way to go over Portlimit, that i missed?

I don't get your point.

1.) The fully implemented kext should contain all HS/SS ports necessary to fully implement all onboard USB2.0 and USB3.0 connectors/headers of the respective motherboard. Following your own port-layout.rtf, on your motherboard only 18 HS/SS ports are required to achieve the latter, with SSP6 being the highest SS port to be implemented. There are no further USB3.0 connectors to which SS07 to SS10 could be assigned. BTW.. for USB2.0 backwards compatibility, also HSxx ports should be assigned to such USB3.0 connectors. If you still claim something contrary than currently implemented, proof and demonstrate it and update your port-layout.rtf, respectively. ;)

2.) I do not see why IONameMatch XHCI should not work in your case. Anyway, if the latter would be really the case, it would be rather because of SMBIOS iMac18,3 or some inappropriate ACPI replacement in your config.plist than because of your specific motherboard.

3.) I thought it was obvious why one also needs the fully implemented kext.

a.) The fully implemented kexts (18-ports in your case) still can be truncated to 15-ports up to each users personal taste and requirements, moreover as there is also the complete port-layout.rtf with the proper assignment of all HS/SS ports implemented. It appears to be the easier approach than modifying an already truncated 15-port kext subsequently.

b.) There are people who insist in using the USB port limit patch under macOS version different from 10.14.1 or 10.14.2. They insist in using all onboard USB2.0/USB3.0 onboard connectors/headers against all warnings of likely induced buffer overruns or all recommendations against loosing vanilla system compatibility. To avoid all unpleasant respective discussions, an additional disposal of fully implemented kexts seems also unavoidable, simply because of strategical reasons. ;)

c.) In contrary, the already truncated 15-port XHC USB kext basically should serve all noobs having no clue on the entire matter, i.e. a predefined OoB solution independent from the employed macOS version.
 
Last edited:
I don't get your point.

1.) The fully implemented kext should contain all HS/SS ports necessary to fully implement all onboard USB2.0 and USB3.0 connectors/headers of the respective motherboard. Following your own port-layout.rtf, on your motherboard only 18 HS/SS ports are required to achieve the latter, with SSP6 being the highest SS port to be implemented. There are no further USB3.0 connectors to which SS07 to SS10 could be assigned. BTW.. for USB2.0 backwards compatibility, also HSxx ports should be assigned to such USB3.0 connectors. If you still claim something contrary than currently implemented, proof and demonstrate it and update your port-layout.rtf, respectively. ;)

2.) I do not see why IONameMatch XHCI should not work in your case. Anyway, if the latter would be really the case, it would be rather because of SMBIOS iMac18,3 or some inappropriate ACPI replacement in your config.plist than because of your specific motherboard.

3.) I thought it was obvious why one also needs the fully implemented kext.

a.) The fully implemented kexts (18-ports in your case) still can be truncated to 15-ports up to each users personal taste and requirements, moreover as there is also the complete port-layout.rtf with the proper assignment of all HS/SS ports implemented. It appears to be the easier approach than modifying an already truncated 15-port kext subsequently.

b.) There are people who insist in using the USB port limit patch under macOS version different from 10.14.1 or 10.14.2. They insist in using all onboard USB2.0/USB3.0 onboard connectors/headers against all warnings of likely induced buffer overruns or all recommendations against loosing vanilla system compatibility. To avoid all unpleasant respective discussions, an additional disposal of fully implemented kexts seems also unavoidable, simply because of strategical reasons. ;)

c.) In contrary, the already truncated 15-port XHC USB kext basically should serve all noobs having no clue on the entire matter, i.e. a predefined OoB solution independent from the employed macOS version.

Well it is like I predicted. I will try another smbios tomorrow.

When I use your 15 Port Kext, nothing happens (Screenshot 1)

Screenshot 1 XHCI.png


When I rename the IOPortNameMatch to XHC everything works perfect (Screenshot 2)

Screenshot 2 XHC.png
 
Last edited:
Hi all,
hm... I think I got all my ports enabled, but USB3 devices only connected with USB2 speed. Maybe someone have a look at my kext. By now I still use my AML, everything works like I expected.
 

Attachments

  • USBPorts.kext.zip
    2.1 KB · Views: 70
Well it is like I predicted. I will try another smbios tomorrow.

When I use your 15 Port Kext, nothing happens (Screenshot 1)

View attachment 380093

When I rename the IOPortNameMatch to XHC everything works perfect (Screenshot 2)

View attachment 380094

I see.. I mean one could implement a XHC to XHCI ACPI replacement in the config.plist or just implement the latter replacement in the XHCI-SSDT. In this case also IOPortNameMatch XHCI should work without problems. Maybe XHC is indeed hardwired in the DSDT of your motherboard. In the latter case we can also stay with IOPortNameMatch XHC in the kext, although in this case IOPortNameMatch XHC will not be fully compatible with my other instructions concerning the USB system implementation, which bases on the XHCI implementation.

Else the two kexts attached to post #193 are working as expected? All USB2.0 and USB3.0 connectors(headers) are implemented and are working at expected speeds?
 
Hi all,
hm... I think I got all my ports enabled, but USB3 devices only connected with USB2 speed. Maybe someone have a look at my kext. By now I still use my AML, everything works like I expected.

Your attached kext is totally wrong and it is not at all the kext distributed in the originating post of this thread! Why don't you just follow my XHC USB Kext guideline in the originating post of this thread and implement everything as suggested? Otherwise no support here, my friend. BTW.. Are you using the same HackingTool software like @ywz306 for your XHC USB kext creation? Seems that this software really implements a totally weird and odd XHC USB configuration. This is definitely not the appropriate thread for posting related kexts or discuss related issues. No support for the HackingTool software along this thread, sorry..

Anyway.. I do not understand what this is all about and why you do not just use the respective XHC USB kexts for the Asus ROG Maximus X Hero of @Racke in post #224 in your case!
 
Last edited:
Status
Not open for further replies.
Back
Top