[Guide] Creating a Custom SSDT for USBInjectAll.kext

[RehabMan]

Hi @RehabMan, I desperately need your help in determining if there are errors in my SSDT-UIAC.aml creation. I have followed this guide as best as I could, but there seem to be problems - my USB3 (Sabrent UIN3) card reader, connected to a USB3 header on the motherboard, is recognised and powered up (and works flawlessly) when I boot using the SSDT-UIAC, but it disappears after the first sleep/wake, and then the computer cannot go into proper sleep (it sleeps, and then the fans spin up again and the screen comes back on, again and again, in an endless loop). I am afraid I might have made a mistake marking/not marking a USB2/USB3 or an internal hub as something else.

Also, if I don't boot from scratch (turn the power switch off on the SMPS/power supply, and then back on), the card reader does not get powered on and/or detected. Can't figure out why. Beyond my knowledge and understanding.

Could you please go through my files. I have supplied all problem reporting files, along with other files that I think might help.

The card reader works flawlessly on a linux boot (on a separate hard drive) on the same computer, which leads me to believe that the problem lies somewhere with how I have done my ACPI implementation and/or SSDT creation.

Your help is greatly appreciated.

Attach ioreg from after sleep/wake.
Note: Since SS01 is connected to an internal device, it should be marked UsbConnector=255 (you have 3).

 

[jasperlevi]

Attach ioreg from after sleep/wake.
Note: Since SS01 is connected to an internal device, it should be marked UsbConnector=255 (you have 3).

Thanks. Attaching ioreg from after sleep/wake. Marking internal SS01 as UsbConnector=255. What about corresponding HS01? Should I mark that as UsbConnector=255 (internal) as well, or leave it as 3?

 

[RehabMan]

Thanks. Attaching ioreg from after sleep/wake. Marking internal SS01 as UsbConnector=255. What about corresponding HS01? Should I mark that as UsbConnector=255 (internal) as well, or leave it as 3?

This ioreg still shows SSP1 with UsbConnector=3.

From my understanding, you have nothing connected to the USB2 pins on that connector, therefore nothing on HS01, therefore HS01 should be excluded.

Is the hub at SSP5/HS09 an internal hub? If so, UsbConnector=255 applies.

 

[jasperlevi]

This ioreg still shows SSP1 with UsbConnector=3.

From my understanding, you have nothing connected to the USB2 pins on that connector, therefore nothing on HS01, therefore HS01 should be excluded.

Is the hub at SSP5/HS09 an internal hub? If so, UsbConnector=255 applies.

Sorry, I had just sent the ioreg after sleep/wake without rebooting earlier. I have now made the changes you suggested, adding UsbConnector=255 for SSP5/HS09, although I had to keep the HS01, as the card reader would stop working if I disabled it. This time, the card-reader persisted after one sleep/wake, after which it reverted to the same behaviour - sleep, and waking up immediately after it, going back to sleep after the timeout period, and waking up again, in a loop.

 

[RehabMan]

Sorry, I had just sent the ioreg after sleep/wake without rebooting earlier. I have now made the changes you suggested, adding UsbConnector=255 for SSP5/HS09, although I had to keep the HS01, as the card reader would stop working if I disabled it. This time, the card-reader persisted after one sleep/wake, after which it reverted to the same behaviour - sleep, and waking up immediately after it, going back to sleep after the timeout period, and waking up again, in a loop.

Your USB configuration fails a basic sanity check...

The number of HSxx ports with UsbConnector=3 does not match the number of SSPx ports with UsbConnector=3.
Each should be a matched set.

Also, FakePCIID_XHCIMux.kext might help. You could probably treat the card reader as a USB2 only device (by disabling the associated SSPx port) just as a test.

 

[Macguru341]

Thanks for great guide but I am new to this and I have some questions :

1. in the preparation for port discovery , you said to take the config_patches.plist and copy it all to my config.plist in the EFI/Clover directory - Do I need to copy it as it is and put it in the end of my config.plist?
2. FakePCIID.kext + FakePCIID_XHCIMux.kext : what do you mean if I plan to use it? as I understand this is used to avoid patching kexts , I use the Xiaomi notebook pro and I don't remember that I used it.
3. Also for the SSDT for USBInjectAll - where Can I check if I have this?
4. XHCI injector kext - how do I know if this is required in my laptop?
5. this is my XHC from IORegistryExplorer , how can I compare it to the USBInjectALL.Kext :

6. Also when I search I don't find EHC1 so I can guess that I don't have it right?

 

[RehabMan]

1. in the preparation for port discovery , you said to take the config_patches.plist and copy it all to my config.plist in the EFI/Clover directory - Do I need to copy it as it is and put it in the end of my config.plist?

Actually, that is not what the guide says at all.
You should copy the one applicable patch only into your own config.plist/KernelAndKextPatches/KextsToPatch.
As per post #1, use a plist editor such as Xcode or PlistEdit Pro.

2. FakePCIID.kext + FakePCIID_XHCIMux.kext : what do you mean if I plan to use it? as I understand this is used to avoid patching kexts , I use the Xiaomi notebook pro and I don't remember that I used it.

As per post #1, XHC routing to EHCI is an option for certain hardware.
So, it is your choice.
But for the hardware in your profile it is not relevant as 100-series and later has no ECHI controller, therefore FakePCIID_XHCIMux.kext has no application (it will do nothing if you install it).

3. Also for the SSDT for USBInjectAll - where Can I check if I have this?

It is something you create.
Read post #1.

4. XHCI injector kext - how do I know if this is required in my laptop?

Not required for the hardware in your profile, as 100-series xHCI is native.

5. this is my XHC from IORegistryExplorer , how can I compare it to the USBInjectALL.Kext :

No idea what you're asking "compare it to the USBInjectAll.kext".
Your device is 8086_9d2f.

6. Also when I search I don't find EHC1 so I can guess that I don't have it right?

Not expected. No EHCI hardware in 100-series and later.

 

[jasperlevi]

Your USB configuration fails a basic sanity check...

The number of HSxx ports with UsbConnector=3 does not match the number of SSPx ports with UsbConnector=3.
Each should be a matched set.

Wow! I don't know how I managed that! And hereI was thinking that I had it nailed...

Corrected the errors. Card reader survives the first sleep/wake. Sleeps properly the second time, but card reader remains dead on second wake. The sleep/wake loop starts happening from the third sleep cycle.

Also, SSP2/HS02 is also connected to the same internal USB3 header on the motherboard as the card reader. Should I mark those ports as internal (UsbConnector=255) as well?

Also, FakePCIID_XHCIMux.kext might help. You could probably treat the card reader as a USB2 only device (by disabling the associated SSPx port) just as a test.

The card reader is a USB3 device. Will it work as a USB2-only device with FakePCIID_XHCIMux.kext? Wouldn't want to lose the speed as well...

 

[RehabMan]

Also, SSP2/HS02 is also connected to the same internal USB3 header on the motherboard as the card reader. Should I mark those ports as internal (UsbConnector=255) as well?

What internal device are SSP2/HS02 connected to?

The card reader is a USB3 device. Will it work as a USB2-only device with FakePCIID_XHCIMux.kext? Wouldn't want to lose the speed as well...

If you eliminate the SSPx port associated, it may connect as USB2 (HSxx, or with FakePCIID_XHCIMux.kext as HPxx on one of the EHCI controller hubs).

 

[jasperlevi]

What internal device are SSP2/HS02 connected to?

The card reader and the single USB3 port on it (SSP01/HS01 and SSP02/HS02 respectively) both connect to the front USB3 header on the motherboard.

If you eliminate the SSPx port associated, it may connect as USB2 (HSxx, or with FakePCIID_XHCIMux.kext as HPxx on one of the EHCI controller hubs).

I can try this, but maybe later (tomorrow, possibly), as it is midnight here and I am rushing to complete work for a meeting tomorrow. As soon as I will install FakePCIID-XHCIMux.kext, all my USB2 port allocations will change all over the place, and I will have to map them out again.