Contribute
Register

A Beginner's Guide to Creating a Custom USB SSDT

Thank you very much. Here are the files (I am sorry I cannot create problem reporting files, for some reason no F-key will work in the Clover boot). Used Hackintool to create the files. I still have to trim a few ports. I remove all the port limit patches and it seems to be stable, but waiting a while to see what happens.

Hi there.

Okay ...

Some observations:

1) Your motherboard does not have an XHC controller, only UHC and EHC. This you can see in the Hackintool output with device IDs.

2) EHC is USB2.0 only. Your motherboard uses a 3rd-party NEC chip for USB3.0.

3) The reason why your ports appear in the PR** part of the IOReg tree is because of the Hackintool-generated SSDT.

4) You have correctly inserted the EHC controller renames in your config.plist but they are not being used.

5) Did you install the USBInjectAll.kext and then Hackintool's SSDT-UIAC.aml file? Or did you use Hackintool's USBPorts.kext instead? They are mutually exclusive etc.
 
or some reason no F-key will work in the Clover boot
See if you can see a key Marked 'Fn' or similar on your keyboard (normally key is in a different colour). (or on mac KB's see above the Arrow keys).
Some laptops/PC's have a Fn Key which uses causes the Function Keys to behave differently - eg, if they have been setup to work as Media keys pressing the 'Fn' key with a Function key will revert it to behave as a normal Function Key not as a media playing related key. If that doesnt work try the function keys with various combinations of shift/ctrl/alt. (also check BIOS for a setting that deals with this)
 
So use the hackintool usb Kext? I only used hackintool because PR ports also appeared using your method, and I could not figure out why and could not continue with your method. I turned off mono usb 3.0 and have a add on card. Ports PR11-14 are the front panel and not used yet (have to remove 15-18 still). Any changes you suggest or is it ok as is?
I have tried every key combo, different keyboards and check bios, have never been able to have clover save anything via key press at boot.
 
So use the hackintool usb Kext? I only used hackintool because PR ports also appeared using your method, and I could not figure out why and could not continue with your method. I turned off mono usb 3.0 and have a add on card. Ports PR11-14 are the front panel and not used yet (have to remove 15-18 still). Any changes you suggest or is it ok as is?
I have tried every key combo, different keyboards and check bios, have never been able to have clover save anything via key press at boot.

I'm sorry the method in this thread does not work for you. This is only a general beginner's guide and doesn't touch on older motherboards with legacy controllers.

I can't support Hackintool here. I can tell you though that you either use the SSDT-UIAC.aml and SSDT-EC.aml files it produces, together with USBInjectAll.kext - OR - the USBPorts.kext on its own.

There's nothing wrong with ports being on the PR** area of the IOReg tree. In fact a lot of older hardware and specialist motherboards cause this to happen in ACPI.

It's difficult to configure an add-in USB card because it will use a third-party chipset. It will probably work ok though:)

If you have installed Clover in legacy mode for your older motherboard, it will work slightly differently.

Check out @RehabMan 's full, expert guide in the Mojave Laptop support section for all the background. Information doesn't come much better :thumbup:
 
I can't support Hackintool here. I can tell you though that you either use the SSDT-UIAC.aml and SSDT-EC.aml files it produces, together with USBInjectAll.kext - OR - the USBPorts.kext on its own.


@UtterDisbelief,

Hackintool does not generate the SSDT-EC.aml file which is used is to fake an Embedded Controller (EC) to satisfy MacOS USB Power Delivery on systems that do not have an active EC correctly defined in the DSDT. Without a AHCI device called "EC" the AppleBusPowerController module will not load.

It's use and a code example are available in Rehabman's USB Power Patching Guide :-


Cheers
Jay
 
Last edited:
@UtterDisbelief,

Hackintool does not generate the SSDT-EC.aml file which is used is to fake an Embedded Controller (EC) to satisfy MacOS USB Power Delivery on systems that do not have an active EC correctly defined in the DSDT. Without a AHCI device called "EC" the AppleBusPowerController module will not load.

It's use and a code example are available in Rehabman's USB Power Patching Guide :-


Cheers
Jay

Sorry, I just meant that the two *.aml files are a part of the package Hackintool drops on your desktop to configure USB ports. I believe my instructions were correct. Happy to be corrected if I was wrong. If Hackintool does not generate the SSDT-EC.aml how does it appear in the files generated? Is it intended as an ACPI patch and just copied from elsewhere - by Hackintool?

I've read the code within it and understand that. I wasn't offering an explanation for its use, by the way.

This Beginner's Guide is a specific method (mostly for XHC and EHC, not UHC) that does not include SSDT-EC.aml nor create one.

As I said earlier, it would be rude to offer support here for someone else's work and method. Having said that, I really do like what @headkaze is doing :thumbup:
 
If Hackintool does not generate the SSDT-EC.aml how does it appear in the files generated? Is it intended as an ACPI patch and just copied from elsewhere - by Hackintool?


@UtterDisbelief,

Hackintool only generates SSDT-UIAC.aml and SSDT-USBX.aml, it does not generate SSDT-EC.aml.

SSDT-UIAC.aml defines Active USB ports and port types for USBInjectAll
SSDT-USBX.aml alternate method of defining USB Power Delivery values (Depends on SMBIOS)

With regards to SSDT-EC.aml ..... in order for MacOS to correctly manage USB Power delivery from Sierra onwards the AppleBusPowerController module needs to load, it will only load against a ACPI device called "EC" (can easy be checked by looking in the IOREG). If a systems DSDT does not have a native ACPI "EC" device or one that can be renamed to "EC" (Usually H_EC or EC0) then the solution is to fake the "EC" device using SSDT-EC.aml.

If the AppleBusPowerController module is not loaded then power deliver to USB ports wont work as expected.

However the above is not true for all cases as depending upon which type of SMBIOS is used dictates which type of USB power delivery method is used by MacOS. The safest solution to ensure proper USB Power Delivery is to implement both and let MacOS choose the appropriate method based on the SMBIOS used.
  • Ensure PC's Embedded Controller is named "EC" (or in very rare cases use a fake one via SSDT-EC.aml)
  • Ensure that ACPI Device "USBX" is defined using SSDT-USBX.aml
Hope that helps to clarify things ...

Cheers
Jay
 
Last edited:
@UtterDisbelief,

Hackintool only generates SSDT-UIAC.aml and SSDT-USBX.aml, it does not generate SSDT-EC.aml.

SSDT-EC.aml should only be used in very select circumstances as detailed in Rehabmans USB Power Management guide.

In essence in order for MacOS to correctly manage USB Power delivery from Sierra onwards the AppleBusPowerController module needs to load, it will only load against a AHCI device called "EC" (can easy be checked by looking in the IOREG). If a systems DSDT does not have a native AHCI "EC" device or a one that can be renamed to "EC" (eg: H_EC or EC0) then the solution is to fake the "EC" as detailed in RehabMans USB Power Management guide.

If AppleBusPowerController is not loaded then power deliver to USB ports wont work as expected.

Hope this clarifies things for you ...

Cheers
Jay

Okay ... But that doesn't match what's happening -

A.jpg


B.jpg


Is all I was saying really... Because an SSDT-EC.aml is included in the zip file the OP has posted above, along with SSDT-UIAC.aml.

I guess it must work differently for different folk and their hardware and the SMBIOS System Definition you mention in the paragraph about power-delivery etc.

:)
 
Last edited:
Okay ... But that doesn't match what's happening


@UtterDisbelief,

Wow .. ok I did not know that Hackintool did that, I've never ever seen it myself.

@headkaze must be parsing the DSDT/ACPI and evaluating the SMBIOS to decide if a fake EC is needed ... pretty clever :clap:

Sorry if I confused you .... guess i learned something that i did not know Hackintool does.

Everyday is a school day in the Hackintosh world :)

I've always manually patched my USB ports using Rehabmans original methods so tend to know when to rename a EC and when to use a fake one, but its great to know that @headkaze is automating these little intricacies in Hackintool, super helpful for those who are not up to speed.

Cheers
Jay
 
Last edited:
Thank you for your help. Will try removing USBInject and using the one created by Hackintool. So far, after removing the port limit patches (all of them), my system seems more stable and snappier. Any changes needed in my config plist? Again, thank you very much and I only turned to Hackintool because I got to the part to map the ports and no HS or SS ports showed, just PR ports (any tutorial I looked up did not show PR ports, and I could not get them to show as HS ports).
 
Back
Top