Contribute
Register

The New Beginner's Guide to USB Port Configuration

You are right, I had to "Rebuild KextCache and Repair Permissions" for the injector to disappear, now it shows this:

Screenshot 2020-04-05 at 19.07.11.png

The ports on the case still don't work and nothing shows up when I unplug/plug devices in :( - any ideas?
 
You are right, I had to "Rebuild KextCache and Repair Permissions" for the injector to disappear, now it shows this:

View attachment 459904
The ports on the case still don't work and nothing shows up when I unplug/plug devices in :( - any ideas?


Hopefully @headkaze will pop back and shed some light here.

My take on this is that you have all XHC ports set as "Internal" whereas you should configure each according to its type using the pull-down menu.

Not sure that is fully causing your problem. I think an IORegistryExplorer Export file might prove handy.

:)
 
Hopefully @headkaze will pop back and shed some light here.

My take on this is that you have all XHC ports set as "Internal" whereas you should configure each according to its type using the pull-down menu.

Not sure that is fully causing your problem. I think an IORegistryExplorer Export file might prove handy.

:)

This is how I configured all ports:
Screenshot 2020-04-05 at 16.45.32.png

This is how they showed up after boot :( -
Screenshot 2020-04-05 at 19.07.11.png
 
This is how I configured all ports:
View attachment 459924
This is how they showed up after boot :( -
View attachment 459925


Curious. If you are using the same USBPorts.kext you uploaded previously in post #562 then the UsbConnector types are all configured correctly. So more likely something else is causing the kext to be ignored.

Trying to be logical here:

1) Are you using the MacPro system-definition 6,1 ?

2) Are you placing the USBPorts.kext in EFI/CLOVER/kexts/Other?

3) Have you removed any USBPorts or USBInjectAll kexts from L/E and rebuilt caches? (I guess so from. yuor comment above).

4) No SSDTs in EFI/CLOVER/ACPI/patched folder?

:)
 
Curious. If you are using the same USBPorts.kext you uploaded previously in post #562 then the UsbConnector types are all configured correctly. So more likely something else is causing the kext to be ignored.

Trying to be logical here:

1) Are you using the MacPro system-definition 6,1 ?

2) Are you placing the USBPorts.kext in EFI/CLOVER/kexts/Other?

3) Have you removed any USBPorts or USBInjectAll kexts from L/E and rebuilt caches? (I guess so from. yuor comment above).

4) No SSDTs in EFI/CLOVER/ACPI/patched folder?

:)

1) Yes, I am using MacPro 6,1 - anything else my second display doesn't work :(
2) Yes, after mounting, it's in /Volumes/EFI/EFI/CLOVER/kexts/Other/USBPorts.kext -- the config.plist I'm editing is /Volumes/EFI/EFI/CLOVER/config.plist which is the correct path
3) Yes:
Code:
Mac-Pro.local ➜  ~  sudo kextstat | egrep  -i 'usbi|usbp'
Mac-Pro.local ➜  ~

4) Hmm:
Code:
Mac-Pro.local ➜  ~  find /Volumes/EFI | grep -i patc
/Volumes/EFI/EFI/CLOVER/ACPI/patched/SSDT-EC.aml
/Volumes/EFI/EFI/CLOVER/ACPI/patched/SSDT-USBX.aml

Should I delete those?

EDIT: If I delete those files, it stops booting:
IMG_1735.jpg
 
Last edited:
1) Yes, I am using MacPro 6,1 - anything else my second display doesn't work :(
2) Yes, after mounting, it's in /Volumes/EFI/EFI/CLOVER/kexts/Other/USBPorts.kext -- the config.plist I'm editing is /Volumes/EFI/EFI/CLOVER/config.plist which is the correct path
3) Yes:
Code:
Mac-Pro.local ➜  ~  sudo kextstat | egrep  -i 'usbi|usbp'
Mac-Pro.local ➜  ~

4) Hmm:
Code:
Mac-Pro.local ➜  ~  find /Volumes/EFI | grep -i patc
/Volumes/EFI/EFI/CLOVER/ACPI/patched/SSDT-EC.aml
/Volumes/EFI/EFI/CLOVER/ACPI/patched/SSDT-USBX.aml

Should I delete those?

EDIT: If I delete those files, it stops booting:
View attachment 459954


Yes, keep those two SSDTs in place. They are what prevent the "1689" error which you can see second line up from the bottom. The SSDT-EC is an "Embedded Controller" and SSDT-USBX is used to boost power output to ports. Actually the latters settings are also in USBPorts.kext so may be duplication. Not sure.

I was wondering about an SSDT-UIAC or SSDT-USB patch.

Quite why those UsbConnector types do not work is a pointer to something, but I haven't spotted it on what I've seen so far ...

What setting do you have in config.plist for <key>Devices</key> <key>USB</key> ?
What setting do you have in config.plist for <key>SystemParameters</key> <key>InjectKexts</key> ?

:)
 
@UtterDisbelief I would appreciate some advice if you have some time. So a user recently asked me the difference between the SSDT-EC and SSDT-USBX files generated by Hackintool and the OpenCore SSDT-EC and SSDT-EC-USBX located @ OpenCorePkg/tree/master/Docs/AcpiSamples.

At first I didn't think there was much difference until I read the following:
Try NOT to rename EC0, H_EC, etc. to EC. These devices are incompatible with macOS and may break at any time. AppleACPIEC kext must NOT load. See the disable code below.

Reference USB: https://applelife.ru/posts/550233
Reference EC: https://applelife.ru/posts/807985
And a bit further down:
Uncomment replacing EC0 with your own value in case your motherboard has an existing embedded controller of PNP0C09 type. While renaming EC0 to EC might potentially work initially, it connects an incompatible driver (AppleACPIEC) to your hardware. This can make your system unbootable at any time or hide bugs that could trigger randomly.

The way Hackintool would work in previous versions:
1. If AppleBusPowerController exists in IORegistry then we don't need an SSDT's or renames
2. Check for EC, EC0, H_EC and ECDV entries in IORegistry
3. If the name matches "PNP0C09" and _STA is not 0 then add a rename to config.plist (Eg. EC0->EC, H_EC->EC)
4. Else generate an SSDT-EC

Generally I like to follow OpenCore advice so I updated Hackintool to work like this:
1. Check for any entry in ACPI (other than "EC") for a "PNP0C09" entry
2. If the entry is found it will uncomment the code from SSDT-EC-USBX replacing EC0 with this entry
3. If it's not found it will still generate SSDT-EC-USBX but without the commented code

So on my laptop I have a rename ECDV->EC. So I thought I would just remove this rename and use SSDT-EC-USBX instead with the uncommented code and ECDV replacing EC0.
ie.
Code:
    External (_SB_.PCI0.LPCB.ECDV, DeviceObj)

    Scope (\_SB.PCI0.LPCB.ECDV)
    {
        Method (_STA, 0, NotSerialized)  // _STA: Status
        {
            If (_OSI ("Darwin"))
            {
                Return (0)
            }
            Else
            {
                Return (0x0F)
            }
        }
    }

But my machine would not boot! So now I'm trying to decide if the changes were a good move or not. What do you think I should do?
 
@UtterDisbelief I would appreciate some advice if you have some time. So a user recently asked me the difference between the SSDT-EC and SSDT-USBX files generated by Hackintool and the OpenCore SSDT-EC and SSDT-EC-USBX located @ OpenCorePkg/tree/master/Docs/AcpiSamples.

At first I didn't think there was much difference until I read the following:

And a bit further down:


The way Hackintool would work in previous versions:
1. If AppleBusPowerController exists in IORegistry then we don't need an SSDT's or renames
2. Check for EC, EC0, H_EC and ECDV entries in IORegistry
3. If the name matches "PNP0C09" and _STA is not 0 then add a rename to config.plist (Eg. EC0->EC, H_EC->EC)
4. Else generate an SSDT-EC

Generally I like to follow OpenCore advice so I updated Hackintool to work like this:
1. Check for any entry in ACPI (other than "EC") for a "PNP0C09" entry
2. If the entry is found it will uncomment the code from SSDT-EC-USBX replacing EC0 with this entry
3. If it's not found it will still generate SSDT-EC-USBX but without the commented code

So on my laptop I have a rename ECDV->EC. So I thought I would just remove this rename and use SSDT-EC-USBX instead with the uncommented code and ECDV replacing EC0.
ie.
Code:
    External (_SB_.PCI0.LPCB.ECDV, DeviceObj)

    Scope (\_SB.PCI0.LPCB.ECDV)
    {
        Method (_STA, 0, NotSerialized)  // _STA: Status
        {
            If (_OSI ("Darwin"))
            {
                Return (0)
            }
            Else
            {
                Return (0x0F)
            }
        }
    }

But my machine would not boot! So now I'm trying to decide if the changes were a good move or not. What do you think I should do?


Hi @headkaze .

I think the world needs to know, the reality is, I would come to you for advice! :thumbup:

However I delved into this and like you, found it intrguing. Your laptop ACPI code looks pretty much as it should. I only have a desktop to play with and the PNP0C09 shows-up in DSDT, but not against EC. The figures in "AppleBusPowerController" are against EC for extra power, so I don't need an SSDT or rename. I confess I wondered what the "switch" was that caused Hackintool to generate the SSDT-EC/USBX.aml's, and now I can see that.

Yes, reading the notes it does look unsafe to do the rename routine and better to stop AppleACPIEC loading at all. I guess the logic is that as an EISA device related to non-Mac hardware you don't want to load an Apple control as it doesn't "fit". Better to just patch ACPI with an SSDT-EC.

As for the USBX element, can the values against kusbsleep and kusbwake in "AppleBusPowerController" be more simply changed? Is the failure to boot caused by a power level being set low?

I'm probably swimming out of my depth now ... Your new method seems sound to me.

Only thing which leaves me :crazy:, is why PNP0C09 shows up against GFX0.CLID in my DSDT? But I can't complain. It boots. It works.

Sorry that's probably not what you need. At this point in Lockdown I've run out of brain ... :lol:
 
Last edited:
The figures in "AppleBusPowerController" are against EC for extra power, so I don't need an SSDT or rename.

I just remembered this tidbit from @whatnameisit

An EC device is needed so AppleBusPowerController attaches to it and injects correct power properties to XHC/EHCx in Mojave and older. In Catalina (as of now and probably higher), an EC device is needed for booting, and AppleBusPowerController loads if IORTC is found and then attaches to IOResources.

So I think I need to add a check for Catalina and not include the EC part if it is.

I think the world needs to know, the reality is, I would come to you for advice! :thumbup:

I must have the world fooled that I know what I'm doing! lol. Unless you've been doing this for many years and understand all the different nuances it's really a matter of research. I only have two Hacks now as I accidentally flashed the wrong BIOS on my old Hack (which was always really useful for testing purposes). These days I rely a lot on feedback as there are so many configuration quirks that can screw things up. It's hard to keep up sometimes!

Sorry that's probably not what you need. At this point in Lockdown I've run out of brain ... :lol:

I know the feeling! :lol:
 
Back
Top