[Guide] Creating a Custom SSDT for USBInjectAll.kext

[jarvise]

Check that your SSDT content is correct after "port discovery" procedures/results, post #1.

I believe that everything is correct
I leave my SSDT and ioreg to give me his approval

and another question I have is to know if my safire RX580 is working with the good drivers, I have in clover / Graphics / FB NAme Orinoco and INJECT ATI INJECT Intel
and I have Lilu.kext and whatevergreen.kext
My SMBIOS is correct for my motherboard?
in several forums there are people who also have it as MACPRO 6.1 while I have it as IMAC 18.3

Is my SMBIOS 18.3 correct for my hardware?

 

[NorthAmTransAm]

Injection of just HS03,SSxx,USRx:

I don't quite understand what Im injecting here. Can anyone help me past this road block? I've got everything setup correctly so far or at least it seems that way.

Edit: To be clear, I'm having trouble getting IOreg to show SSxx like yours. I found the corresponding set in the template and made sure it compiled correctly and added it to my patched folder. Still shows up like so. What part am I being dumb about?

 

[RehabMan]

I leave my SSDT and ioreg to give me his approval

Only you can double check your port discovery.

 

[RehabMan]

I don't quite understand what Im injecting here. Can anyone help me past this road block? I've got everything setup correctly so far or at least it seems that way.

Edit: To be clear, I'm having trouble getting IOreg to show SSxx like yours. I found the corresponding set in the template and made sure it compiled correctly and added it to my patched folder. Still shows up like so. What part am I being dumb about?

View attachment 370366

You need to use -uia_exclude_hs to allow discovery/testing of SSxx.
Read the guide carefully.

 

[NorthAmTransAm]

You need to use -uia_exclude_hs to allow discovery/testing of SSxx.
Read the guide carefully.

Woohoo thats exciting. Learned a lot about Clover at boot as well. Thanks per usual. Onward.

Follow up question: I also haven't quite landed on this getting FakePCIID to show up in Ioreg like yours. Is there a common misstep I'm doing or is this something that will show up much later?

edit: to be fair I don't have a real understanding of that and wether or not I need the FakePCIID_XHCIMux.kext. I'll do some reading. However I did manage to get this to work. What a guide. Thanks @RehabMan. Now to add the USB C ports I totally forgot about.

Am I correct to assume I can now delete XHCI-300-series-injector.kext?

 

[RehabMan]

I also haven't quite landed on this getting FakePCIID to show up in Ioreg like yours.

FakePCIID_XHCIMux.kext does not apply to your hardware (your hardware has no ECHI controller).

 

[XDAN]

Hi, I'm stuck with the identifying the USB ports. Yes I did read the guide up and down many times. But I do still not see the SSPX Ports.

 

[deeveedee]

@RehabMan - this is a technical question about SSDT-UIAC.dsl, so I'm not providing problem reporting files. On my Thinkpad T61 running High Sierra 10.13.6, when I updated my SSDT-UIAC-ALL.dsl file during my upgrade from USBInjectAll.kext version 0.6.5 to 0.7.1, I didn't notice that the EH01.ports.PR11.UsbConnector value was 255 instead of 0 (my EH01.ports.PR11 is an external USB 2.0 port). As expected, a value of 0 allowed my connected USB devices to show on the Desktop and a value of 255 hid my connected USB devices from the desktop (only appearing in the Finder).

I'm not certain, but in addition to the difference in display behavior between UsbConnector=0 and UsbConnector=255, it appears that my USB port EH01.ports.PR11 behaves "better" when UsbConnector=255 (even though it's an external port). When UsbConnector=0, I've observed system "freezes" during large USB transfers. I have not observed these system "freezes" when UsbConnector=255.

I need more testing to confirm this. Do you believe there is any reason why a value of UsbConnector=255 would be more stable than a value of UsbConnector=0?

 

[NorthAmTransAm]

FakePCIID_XHCIMux.kext does not apply to your hardware (your hardware has no ECHI controller).

Ah, got it. I've got two more rogue ports I cant quite test because I don't have a USB C cable. After that I'm 100 percent mapped out. Feels great. Thanks for everything. I'll bother you on another forum surely.

Edit: Delete last because of a simple copy paste error. Current hang up is this line. Any advice?

Fixed. Though HS01 and HS02 do not apply to the USB 3.1 C and A ports at the top (back) of my Z370a Prime. They show up as RP05 which has 4 ports. Using a 3.0 hub in the type A port I get 3.0 on RP05 port 2 and 2.0 on Port 4. Safe to assume port 1 and 3 are the same for type C there. I guess there's no work to do here.

 

[deeveedee]

The debug_071 files show that USBInjectAll is not even loading under IOResources.
I have no idea why that might happen (especially with no kernel log data).
Not reproducible here.
Try with fresh install.
Note that there are a lot of releases between 0.7.1 and 0.6.5. If you can still repro on a fresh install, try each release to determine when the problem appeared.

When I first upgraded to High Sierra, USBInjectAll 0.7.1 was not available. I restored my Sierra partition and prior to upgrading to High Sierra, I updated USBInjectAll 0.6.5 to 0.7.1. Then I upgraded to High Sierra. USB ports work as they should following the upgrade to High Sierra. Just to repeat for clarity, on my very old Thinkpad T61, updating USBInjectAll from 0.6.5 to 0.7.1 after upgrading Sierra to High Sierra resulted in 'broken' USB ports that would not detect inserted devices. Updating USBInjectAll from 0.6.5 to 0.7.1 in Sierra and then upgrading Sierra to High Sierra preserved full USB functionality.

This also worked for FakeSMC and Hardware monitor. Upgrading FakeSMC after upgrading to High Sierra resulted in partial Hardware Monitor functionality that displayed only several system attributes. Updating FakeSMC prior to upgrading from Sierra to High Sierra preserved full Hardware Monitor functionality.