A Beginner's Guide to Creating a Custom USB SSDT

[UtterDisbelief]

Didn’t know that, sorry if it’s something that everyone knows by now. I thought that the costum ssdt would be something more “bulletproof “ . I guess I’ll have to wait. Thanks

Hi all.

I agree with what the other guys have said -

1) Move USBInjectAll to the EFI folders. That way there should be no new blocking by Catalina. Also bear in mind you need to use @Sniki 's fork of USBInjectAll.kext if you are running with system-definition "iMac19,2". @RehabMan 's only goes as far as "iMac19,1".

2) You don't need the EHC controller renames in your config.plist (unless you fully intend to move USB2 ports away from XHC).

3) Error in your SSDT_UAIC.aml. It's only minor but it would bug me knowing it's there and leaving it! Your "port count" for the "8086_a2af" controller shows as "0x1A" and it should be "0x16". As everything worked with Mojave, this could be just a detail rather than a problem.

4) You should disable the port-limit removal patch in your config.plist.

5) Clean up duplicated *.efi files in drivers/UEFI and /drivers64UEFI.

 

[Nels0n]

Hi all.

I agree with what the other guys have said -

1) Move USBInjectAll to the EFI folders. That way there should be no new blocking by Catalina. Also bear in mind you need to use @Sniki 's fork of USBInjectAll.kext if you are running with system-definition "iMac19,2". @RehabMan 's only goes as far as "iMac19,1".

2) You don't need the EHC controller renames in your config.plist (unless you fully intend to move USB2 ports away from XHC).

3) Error in your SSDT_UAIC.aml. It's only minor but it would bug me knowing it's there and leaving it! Your "port count" for the "8086_a2af" controller shows as "0x1A" and it should be "0x16". As everything worked with Mojave, this could be just a detail rather than a problem.

4) You should disable the port-limit removal patch in your config.plist.

5) Clean up duplicated *.efi files in drivers/UEFI and /drivers64UEFI.

You are Gold! I did everything you said and now works again. Just having some random ejects but ill see that more deeper tomorrow. Thanks!

Try putting USBInjectAll.kext in /EFI/CLOVER/kexts/Other/ and see if it helps.

The same for you. Thanks!

 

[ntnlluni]

Hi @UtterDisbelief ,
I've been googling since now 5 days without fix my issue. In my Rampage hackintosh, I'm can't enable the XHC USB Controller. I tried almost everything. I did read that as I'm on Mojave, I don't need usb injection at all. So tried to add and remove from clover kext folder GenericUSBXHCI.kext, FakePCIID_XHCIMux.kext, XHCI-unsupported.kext and USBInjectAll.kext without luck. In BIOS I enabled the USB handoff and legacy support, where available. I added the patches for renaming the controllers, I also tried the last USB limit patch but apparently it doesn't work on 10.14.6. I can't compile my SSDT as the controller is not visible. I also tried removing FakePCIID.kext from kext folder, but the boot fails without it. Can anybody please give me any advice? I'm really desperate. I did read all this thread and tried all the combination but I obviously missed something.
Many thanks in advance!


edit: I just found a post saying "X79 has no chipset USB 3.0, only third party PCIe USB 3.0. His board has ASM1042 xHCI". I suppose that I've been trying to enable a controller that actually is not on the board"

 

[UtterDisbelief]

Hi @UtterDisbelief ,
I've been googling since now 5 days without fix my issue. In my Rampage hackintosh, I'm can't enable the XHC USB Controller. I tried almost everything. I did read that as I'm on Mojave, I don't need usb injection at all. So tried to add and remove from clover kext folder GenericUSBXHCI.kext, FakePCIID_XHCIMux.kext, XHCI-unsupported.kext and USBInjectAll.kext without luck. In BIOS I enabled the USB handoff and legacy support, where available. I added the patches for renaming the controllers, I also tried the last USB limit patch but apparently it doesn't work on 10.14.6. I can't compile my SSDT as the controller is not visible. I also tried removing FakePCIID.kext from kext folder, but the boot fails without it. Can anybody please give me any advice? I'm really desperate. I did read all this thread and tried all the combination but I obviously missed something.
Many thanks in advance!

Hello there.

Well, the basic problem here is that X79 does not have an XHCI controller, only EHCI. The USB3 ports are provided by an ASMedia piggy-back chip.

Because of this the ports will only show up in IORegistryExplorer on the PR** section of the tree. It looks as though presently you only have 1x port showing, at address 02, 00, 00, 00. The reason is because your controllers are lableled - EUSB and USBE - not EHC2 .

You will need USBInjectAll.kext and for the ASMedia, GenericUSBXHCI.kext.

The problem is getting those 12x USB2 ports to show up...

1) Try those new renames - you will need both EUSB to EH01 & USBE to EH02. Remove the other ones you have there. You can use the ACPI pull-down patches menu if you are using Clover Configurator etc.

2) No need for FakePCIID_XHCIMux.kext at this point as it only usually works when an Intel XHC controller is present.

Let us know how that changes things

 

[ntnlluni]

A huge thank you @UtterDisbelief for your help to the community, and your great guide, I learned a lot of things thanks to it.
So yes, you are absolutely correct. As suggested, with those kext in place, I'm able to see two controllers. Now I'm apparently back to a previous working configuration that I believed to be incorrect, I'll explain why:

When I tried to connect a USB device to all the ports, the device is recognized only when inserted in the USB2 ports, not in the USB3 ports. In Hackintool, the USB2 port lines become "green"/active and the USB device name recognised while connected. The same doesn't happen for the USB3 ports (blue ports and type-c@pci). The strange things is that the despite be not recognized from hackintool, the device (a keyboard) "works". Do you believe this behaviour is necessarily symptom of an incorrect USB setup? For me is representing definitely an issue, as I can't identify the port in hackintool, and if the type c is a normal or SW port, for create the SSDT.

I also have a doubt about the SSDT, after creating and dropping it to the acpi/patched folder, do I need to define it in clover/config.plist, or are .aml loaded automatically?
As for screenshot attached, there are two different controllers + PRT1, a type-c usb adapter (I'm aiming to enable it as I need the port for a type-c Audio Interface). I expected the 15 limit to apply per controller, so I can ideally enable 15 ports for HP, 15 for PR and the PRT1, is my understand correct?
I'm remotely control the hackintosh now, so I can't attach all the usb to the ports, to show you all the active/green line ports in the screenshot, but I recall the first 10-15 port to be recognized, not the other, nor the usb type-c.

edit: attached the screenshot with the one detected by Hackintool. As mentioned part of the USB3 are actually working even if not detected at all. The type-c apparently is activating just a port, so I'm guessing is a type-c+sw. I don't have way to identify the USB3 and set Hackintool according.

e mentioned ports become discoverable only after injecting the SSDT backuped up in the ACPI/patched copy 3/ folder of my previous post EFI.zip

Many thanks again for your help!

 

[UtterDisbelief]

A huge thank you @UtterDisbelief for your help to the community, and your great guide, I learned a lot of things thanks to it.
So yes, you are absolutely correct. As suggested, with those kext in place, I'm able to see two controllers. Now I'm apparently back to a previous working configuration that I believed to be incorrect, I'll explain why:

When I tried to connect a USB device to all the ports, the device is recognized only when inserted in the USB2 ports, not in the USB3 ports. In Hackintool, the USB2 port lines become "green"/active and the USB device name recognised while connected. The same doesn't happen for the USB3 ports (blue ports and type-c@pci). The strange things is that the despite be not recognized from hackintool, the device (a keyboard) "works". Do you believe this behaviour is necessarily symptom of an incorrect USB setup? For me is representing definitely an issue, as I can't identify the port in hackintool, and if the type c is a normal or SW port, for create the SSDT.

I also have a doubt about the SSDT, after creating and dropping it to the acpi/patched folder, do I need to define it in clover/config.plist, or are .aml loaded automatically?
As for screenshot attached, there are two different controllers + PRT1, a type-c usb adapter (I'm aiming to enable it as I need the port for a type-c Audio Interface). I expected the 15 limit to apply per controller, so I can ideally enable 15 ports for HP, 15 for PR and the PRT1, is my understand correct?
I'm remotely control the hackintosh now, so I can't attach all the usb to the ports, to show you all the active/green line ports in the screenshot, but I recall the first 10-15 port to be recognized, not the other, nor the usb type-c.

edit: attached the screenshot with the one detected by Hackintool. As mentioned part of the USB3 are actually working even if not detected at all. The type-c apparently is activating just a port, so I'm guessing is a type-c+sw. I don't have way to identify the USB3 and set Hackintool according.

e mentioned ports become discoverable only after injecting the SSDT backuped up in the ACPI/patched copy 3/ folder of my previous post EFI.zip

Many thanks again for your help!

Good news. Glad you got the ports working again

Several things to cover here:

1) No, there is only 1x 15-port limit and that applies to the Intel chipset (X79 in your build). Remember a real Mac Pro will allow you to use an add-on PCI-e card with extra USB ports. The built-in limit does not apply to these. When a PC motherboard manufacturer uses a 'piggy-back' chip like ASMedia to add extra ports, macOS treats them in the same way, as separate from the main ones.

2) Your screengrab from Hackintool shows only the two X79 EHCI controllers in the top panel. Those are the HP** sections below. The PR** ports will be the ASMedia ports. I do not know how Hackintool identifies controllers, but I would expect it to be able to spot the ASMedia one. The fact it doesn't is a mystery to me. However you can at least see all the extra ports along with your USB-C socket.

You can always check for yourself by looking in - About This Mac / System Report / USB. You should be able to see all three controllers. 8086_1d26 and 8086_1d2d are the X79. The 'other' one will be the ASMedia etc.

There are potential problems with 3rd-party USB controllers and they are related to speed, power output and safe mount/unmount. They nearly always work in macOS but are not easily configurable.

3) USBInjectAll and the SSDT-USB will not affect the ASMedia USB ports, only the X79 ones. If you create your own SSDT then you need two sections just for the EHC controller ports. If you check IORegistryExplorer you will see all those PR** ports but USBInjectAll.kext does not allow access to them through its *aml.

Hope that helps.

 

[ntnlluni]

Many thanks for your replies @UtterDisbelief.
So I need to admit that I'm quite confused now, because I get just USB2.0 bus, not USB3.0, as for system report screenshot attached.

Also the type-c ports doesn't work, and one think that is actually very strange, is that when I attach the keyboard, I see it duplicated on two ports, the HP11 and PRT1 (Quickfire TKL 6 keys). I know is duplicated because it appears and disappears simultaneously on both port while the keyboard is connected/disconnected. Also the device name is the same.

I'm also confused, as the PCI adapter is a type-c + USB3.0, so I would expect to have two ports in that controller, not just the PRT1. And off course, the Audio Interface on type-c doesn't work at all.

 

[UtterDisbelief]

Many thanks for your replies @UtterDisbelief.
So I need to admit that I'm quite confused now, because I get just USB2.0 bus, not USB3.0, as for system report screenshot attached.

Also the type-c ports doesn't work, and one think that is actually very strange, is that when I attach the keyboard, I see it duplicated on two ports, the HP11 and PRT1 (Quickfire TKL 6 keys). I know is duplicated because it appears and disappears simultaneously on both port while the keyboard is connected/disconnected. Also the device name is the same.

I'm also confused, as the PCI adapter is a type-c + USB3.0, so I would expect to have two ports in that controller, not just the PRT1. And off course, the Audio Interface on type-c doesn't work at all.

Okay, understood.

Looking at your screengrabs I can see that in System Report you have actually highlighted a hub. This is not a controller. Move the cursor up to one of the USB 2.0 Buses for the correct Device IDs etc. A Hub will tend to confuse any ports configuration. Some manufacturers use them, others do not.

For example here is my own USB tree. The hub is actually the one on the Apple wired keyboard:

Again from your System Report grab we can not see the USB 3.0 sub-system, which seems to imply:

1) it is disabled in your BIOS (This needs checking).

If it is enabled then macOS cannot see the controller for some other reason we'll have to explore.

2) Duplication of ports is usually caused by certain kexts that have been installed. So check which ones related to USB you have in EFI/CLOVER/kexts/Other and Library/Extensions.

Yes, so far this is difficult to pin down, but remember there is no magic or mystery, only a reason to be discovered.

 

[ntnlluni]

Thanks @UtterDisbelief. Yes I confirm your theory, I come the same conclusion, as I uninstalled the pci-e type-c card, and the PRT1 is still there. According to the Hackintool documentation, it should be a hub, that would explains why the duplicate entry.

I made further tests and I can confirm the following:

- USB2.0 is up, but if I create and install the SSDT for it with Hackintool (the tool creates for me SSDT-UIAC.aml and SSDT-EC.aml, not sure why), then I remove the injectall kext and restart, the hub stop to works. I do that as I understood the kext should be removed if a valid SSDT is installed, please correct me if I'm wrong.

- USB3.0 is not loaded, despite having it enabled on BIOS (screenshot), no matter what kind of kext I inject or if I disable the legacy support.

- The type-c controller is not recognized at all, probably for the same reason the 3.0 is not

- I definitely didn't get if I should inject also USBPorts.kext.

 

[UtterDisbelief]

Thanks @UtterDisbelief. Yes I confirm your theory, I come the same conclusion, as I uninstalled the pci-e type-c card, and the PRT1 is still there. According to the Hackintool documentation, it should be a hub, that would explains why the duplicate entry.

I made further tests and I can confirm the following:

- USB2.0 is up, but if I create and install the SSDT for it with Hackintool (the tool creates for me SSDT-UIAC.aml and SSDT-EC.aml, not sure why), then I remove the injectall kext and restart, the hub stop to works. I do that as I understood the kext should be removed if a valid SSDT is installed, please correct me if I'm wrong.

- USB3.0 is not loaded, despite having it enabled on BIOS (screenshot), no matter what kind of kext I inject or if I disable the legacy support.

- The type-c controller is not recognized at all, probably for the same reason the 3.0 is not

- I definitely didn't get if I should inject also USBPorts.kext.

The BIOS looks fine.

No, with Hackintool you still need USBInjectAll.kext when using the SSDT-UIAC.aml and SSDT-EC.aml it provides. Think of the SSDTs as configuration files for USBInjectAll. The SSDT-EC is an embedded controller that is sometimes needed with certain motherboards. If you want to remove USBInjectAll then you should use the USBPorts.kext instead. Then you can remove it and the SSDTs too.

To help with the missing USB 3.0 ports, we still need to know which kexts you have installed in EFI/CLOVER/kexts/Other and L/E.

Also, please bear in mind this isn't a support thread for Hackintool itself. @headkaze is the author who can give you deeper insights. I can only support the methods in this thread