[solved] Mojave 10.14.1 update lost USB 3.0

[Amylowellow]

@Amylowellow,
Attached. I'm not sure if the ports are numbered properly.

dsl, not aml

 

[chiefbeats]

dsl, not aml

@Amylowellow ,
Attached. I got it to work! It was incorrect port numbering. I also realized the port count must be 26, not 15, in order for everything to work. What's weird now is Clover crashed when I try to go to Mount EFI. It seems there is something about the USB configuration that it doesn't like.

 

[Amylowellow]

"HS09", Package() // HS Top lower left (4 ports)
{
"UsbConnector", 2,
"port", Buffer() { 9, 0, 0, 0 },
},
"HS10", Package() // HS Top upper left (4 ports)
{
"UsbConnector", 2,
"port", Buffer() { 10, 0, 0, 0 },
},
"HS13", Package() // HS Rear upper right (4 ports)
{
"UsbConnector", 2,
"port", Buffer() { 13, 0, 0, 0 },
},
"HS14", Package() // HS Rear upper left (4 ports)
{
"UsbConnector", 2,
"port", Buffer() { 14, 0, 0, 0 },
},

Need to be type 0 I think.

Also USR1/USR2 you probably can delete those. I don't think they actually exist.

But other than that the dsl look fine to me.

 

[chiefbeats]

Need to be type 0 I think.

Also USR1/USR2 you probably can delete those. I don't think they actually exist.

But other than that the dsl look fine to me.

You're exactly right. Stupid oversight on my part! I think I concur with USR1/USR2 as well. I've never been able to get them to activate. This is actually good because I can bring back ports HS11 and HS12 now. These were ports on the front of my case that I had to sacrifice to get this to work. Thanks!

 

[chiefbeats]

@RehabMan,
The SSDT is breaking Clover for some reason. When I go to select "Mount EFI" in Clover, it crashes/closes.

When I use -uia_ignore_rmcf, the problem goes away. Problem export attached (used script). SSDT-UIAC attached. USB ports appear to being working properly, however.

 

[RehabMan]

@RehabMan,
The SSDT is breaking Clover for some reason. When I go to select "Mount EFI" in Clover, it crashes/closes.

Clover Configurator is not related to anything produced by the Clover team.
I don't use Clover Configurator ever to directly edit my config.plist (you cannot trust it).

When I use -uia_ignore_rmcf, the problem goes away. Problem export attached (used script). SSDT-UIAC attached. USB ports appear to being working properly, however.

The ioreg here shows SSDT-UIAC.aml and USBInjectAll.kext working as designed, no -uia_ignore_rmcf involved.

 

[chiefbeats]

Clover Configurator is not related to anything produced by the Clover team.
I don't use Clover Configurator ever to directly edit my config.plist (you cannot trust it).



The ioreg here shows SSDT-UIAC.aml and USBInjectAll.kext working as designed, no -uia_ignore_rmcf involved.

@RehabMan,
I'm sorry, but it can't just be that simple. There's something to be said about the fact that I've never had a problem with Clover Configurator until using your patch method.

Is it possible to configure the USBInjectAll.kext info.plist to perform the same function as the SSDT patch? The idea is to have only one kext that needs to be installed instead of installing a kext and creating an SSDT.

In your readme's and guides you mention a port injector, but I've not seen any instructions for that specifically. It seems like everything is based on using the SSDT in conjunction with the USBInjectAll.kext. How can I modify USBInjectAll.kext to perform the same function? Also, you mention that USBInjectAll.kext is to be temporary. What's the actual long term solution? Is it the port injector method?

 

[RehabMan]

@RehabMan,
I'm sorry, but it can't just be that simple. There's something to be said about the fact that I've never had a problem with Clover Configurator until using your patch method.

Clover Configurator reads config.plist only. It does not look at anything in ACPI/patched.

If you have an issue with Clover Configurator, bring it to the CC developer. I have nothing to do with the app, and I never use it to edit my config.plist.

Is it possible to configure the USBInjectAll.kext info.plist to perform the same function as the SSDT patch? The idea is to have only one kext that needs to be installed instead of installing a kext and creating an SSDT.

You could create an injector kext that would override default USBInjectAll.kext Info.plist.
But the SSDT works just fine (as your ioreg proves).

In your readme's and guides you mention a port injector, but I've not seen any instructions for that specifically. It seems like everything is based on using the SSDT in conjunction with the USBInjectAll.kext. How can I modify USBInjectAll.kext to perform the same function? Also, you mention that USBInjectAll.kext is to be temporary. What's the actual long term solution? Is it the port injector method?

You can create a standalone USB injector kext. I used to use that before I created USBInjectAll.kext...
There is even a facility in the Intel-FB-patcher app that can create it for you.

I never said USBInjectAll.kext is temporary. I think you're referring to the port limt patch. And now my guide does not even utilize the port limit patch (got tired of chasing down yet another port limit patch for each version).

Long term solutions:
- USB injector kext
- USBInjectAll.kext + SSDT-UIAC.aml to configure it

Both are equally valid, equally effective solutions when implemented correctly.

 

[chiefbeats]

Clover Configurator reads config.plist only. It does not look at anything in ACPI/patched.

If you have an issue with Clover Configurator, bring it to the CC developer. I have nothing to do with the app, and I never use it to edit my config.plist.



You could create an injector kext that would override default USBInjectAll.kext Info.plist.
But the SSDT works just fine (as your ioreg proves).



You can create a standalone USB injector kext. I used to use that before I created USBInjectAll.kext...
There is even a facility in the Intel-FB-patcher app that can create it for you.

I never said USBInjectAll.kext is temporary. I think you're referring to the port limt patch. And now my guide does not even utilize the port limit patch (got tired of chasing down yet another port limit patch for each version).

Long term solutions:
- USB injector kext
- USBInjectAll.kext + SSDT-UIAC.aml to configure it

Both are equally valid, equally effective solutions when implemented correctly.

Is there not a system kext that can be modified similarly to perform the same function? Technically, aren't the system kexts and your patching method doing the same thing? Using this method (https://www.tonymacx86.com/threads/xhc-usb-kext-creation-guideline.242999/) seems to reveal the responsible kexts but you and @kgp seemed to butt heads on this one. I don't fully understand all this, but I feel like I'm in too deep at this point. Haha! My curiosity has gotten the best of me. It seems that if we can simply use a kext or patch to fix the problem, we can simply modify the preexisting ones instead.

Since using this SSDT method, all the ports are listed and operate at proper speeds, but Trackpad operation, for example, does not seem to be working 100% because there are negative changes as a result of using it. When I boot into the desktop, there is a slight delay before my mouse is usable. This did not exist before. Also, while in use, there are slight delays and glitches in the haptic feedback that didn't exist before. Comes and goes.

 

[RehabMan]

Is there not a system kext that can be modified similarly to perform the same function?

Of course there is. If you had read my guide, you would know how.
But why would you modify a system kext when you can do it from outside?
A modified system kext will need to be modified after each update....

Technically, aren't the system kexts and your patching method doing the same thing? Using this method (https://www.tonymacx86.com/threads/xhc-usb-kext-creation-guideline.242999/) seems to reveal the responsible kexts but you and @kgp seemed to butt heads on this one.

No head butting there.

I don't fully understand all this, but I feel like I'm in too deep at this point.

Suggestion: Understand fully before criticizing methods that others have worked to produce.

Since using this SSDT method, all the ports are listed and operate at proper speeds, but Trackpad operation, for example, does not seem to be working 100% because there are negative changes as a result of using it.

What are you referring to?
What kind of trackpad?
What, specifically, is different?

When I boot into the desktop, there is a slight delay before my mouse is usable. This did not exist before. Also, while in use, there are slight delays and glitches in the haptic feedback that didn't exist before. Comes and goes.

You probably have other mistakes. For example, just from looking at your ioreg:
- USB power properties not implemented (not new USBX ones, not legacy either)
- GenericUSBXHCI not recommended (it is buggy and no one is maintaining it)
- Plex Tuner and Chrome hooking various USB ports for some reason...
- forgot SATA-unsupported.kext (for your Intel SATA controller that is missing entries in AppleAHCIPort.kext Info.plist)
- CPU PM not implemented (you need config.plist/ACPI/SSDT/Generate/PluginType=true)
- config.plist/SystemParameters/InjectKexts should be set "Detect"... all "kexts you need" installed to /L/E
- note kextcache output shows clear problem with mismatch between AirportBrcmFixup.kext and Lilu.kext
- also kextcache output shows USBInjectAll.kext not properly installed