Contribute
Register

[Guide] Creating a Custom SSDT for USBInjectAll.kext

RehabMan said:
Your SSDT-UIAC.aml has no effect because you coded it for 8086_a12f, but your XHC device-id is 09d2f.
Click to expand...
Ah I see, I missed that point. I think I’ve got it now. Hopefully this is correct.

In your guide you say that Skylake does not have EHCI controller, so should I just disable or delete those two patches in config.plist?

Do I still need the AppleXCHI patch in KextsToPatch?

Thank you!
 
Build 1
Z390 AORUS PRO WIFI |  i9 9900K |  Radeon Other
Kittciokas said:
It's written in SSDT-XOSI.dsl comments:
Code: 
To use this SSDT, you must compile it as AML, place in ACPI/patched, add
// to config.plist/ACPI/SortedOrder, and use the "change _OSI to XOSI"
// patch in config.plist/ACPI/DSDT/Patches (see config_patches.plist)
Click to expand...

You would only need to add it to SortedOrder if you're using SortedOrder.
Typically, SortedOrder is not used anymore (since I added AutoMerge=true feature to Clover).
 
pkdesign said:
Ah I see, I missed that point. I think I’ve got it now. Hopefully this is correct.

In your guide you say that Skylake does not have EHCI controller, so should I just disable or delete those two patches in config.plist?

Do I still need the AppleXCHI patch in KextsToPatch?

Thank you!
Click to expand...

Obviously, no need for EHCx->EH0x renames if you have no EHCI controller.
No need for any port limit patch if you have successfully limited your injected ports to be within macOS limits (15 per controller).

But your SSDT is wrong. You wrote "8086_09d2f" instead of "8086_9d2f".
 
CheeseGrater II
PRIME Z270-A |  i7 7700K |  RX 580 Pulse 8GB
Hack II
ROG STRIX Z370-H GAMING |  i3 8350K |  RX 580 Pulse 8GB
RehabMan said:
You would only need to add it to SortedOrder if you're using SortedOrder.
Typically, SortedOrder is not used anymore (since I added AutoMerge=true feature to Clover).
Click to expand...
I read your previously linked guide https://www.tonymacx86.com/threads/guide-patching-laptop-dsdt-ssdts.152573/ and "Saving files for loading by the bootloader" part perfectly explained it. Thank you.

I have two questions:

1. You said _OSI->XOSI patch requires SSDT-XOSI.aml, i didn't have one before and USB 3 worked perfectly. So why _OSI->XOSI patch and SSDT-XOSI.aml is required? I read about simulating Windows, but USB 3 worked without it.

2. As i now understand, that Patch by PMHeart for disabling 15 port limit is no longer needed? We need it only to discover all ports in order to create Custom SSDT? And that's why that PMHeart patch didn't work on 10.14.1 when i tried to make custom SSDT and it worked on 10.14.0?
And that patch, which works only for one or few macOS versions, after macOS updates might stop working for whatever reason, thus 15 port limits comes back and only those ports, that fit into 15 port limit stays availabe. Did i understood that correctly?

Thank you, one more time.
 
Kittciokas said:
I read your previously linked guide https://www.tonymacx86.com/threads/guide-patching-laptop-dsdt-ssdts.152573/ and "Saving files for loading by the bootloader" part perfectly explained it. Thank you.

I have two questions:

1. You said _OSI->XOSI patch requires SSDT-XOSI.aml, i didn't have one before and USB 3 worked perfectly. So why _OSI->XOSI patch and SSDT-XOSI.aml is required? I read about simulating Windows, but USB 3 worked without it.

2. As i now understand, that Patch by PMHeart for disabling 15 port limit is no longer needed? We need it only to discover all ports in order to create Custom SSDT? And that's why that PMHeart patch didn't work on 10.14.1 when i tried to make custom SSDT and it worked on 10.14.0?
And that patch, which works only for one or few macOS versions, after macOS updates might stop working for whatever reason, thus 15 port limits comes back and only those ports, that fit into 15 port limit stays availabe. Did i understood that correctly?

Thank you, one more time.
Click to expand...

Spoofing a version of Windows with _OSI related patches is usually a good idea, but not always necessary (completely system dependent).

Port limit patch is not necessary at all, ever (in the past, it was merely a convenience to simplify port discovery). Read post #1.
 
I have a question regarding something I'm seeing on a Haswell based system (Z97x-UD5-BK mobo), during the port discovery process (with port limit patch successfully applied on high sierra, I can see HS01 through HS15, and SSP1 through SSP6). Everything seems fine, apart from a single USB3 connector HS10 not corresponding to an equivalent SSPx when USB3 devices are used. Basically I get the following -:

(device id 8086_8cb1)

HS01 corresponds to SSP1
HS02 corresponds to SSP2
HS03 corresponds to SSP3
HS05 (USB2)
HS06 (USB2)
HS07 (USB2)
HS08 (USB2)
HS09 corresponds to SSP5
HS10 -> Cant find corresponding SSPx despite it being a USB3.0 port. USB3.0 devices just show up on HS10 as USB2.0.
HS11 (USB2)
HS12 (USB2)

I can live with it as is, and have already made a working SSDT, but just wondering if I've possibly missed something simple to get that last USB3.0 port working as a USB3.0 port.
 
Last edited:
alvindarkness said:
I have a question regarding something I'm seeing on a Haswell based system (Z97x-UD5-BK mobo), during the port discovery process (with port limit patch successfully applied on high sierra, I can see HS01 through HS15, and SSP1 through SSP6). Everything seems fine, apart from a single USB3 connector HS10 not corresponding to an equivalent SSPx when USB3 devices are used. Basically I get the following -:

(device id 8086_8cb1)

HS01 corresponds to SSP1
HS02 corresponds to SSP2
HS03 corresponds to SSP3
HS05 (USB2)
HS06 (USB2)
HS07 (USB2)
HS08 (USB2)
HS09 corresponds to SSP5
HS10 -> Cant find corresponding SSPx despite it being a USB3.0 port. USB3.0 devices just show up on HS10 as USB2.0.
HS11 (USB2)
HS12 (USB2)

I can live with it as is, and have already made a working SSDT, but just wondering if I've possibly missed something simple to get that last USB3.0 port working as a USB3.0 port.
Click to expand...

As per post #1, do not use the port limit patch... not even during port discovery.
Use the various exclude flags (eg. use uia_exclude_hs while testing SSPx).
 
RehabMan said:
As per post #1, do not use the port limit patch... not even during port discovery.
Use the various exclude flags (eg. use uia_exclude_hs while testing SSPx).
Click to expand...

Thanks for your help, I'll give it another go later today using the exclude flags.
 
You must log in or register to reply here.
Copyright © 2010 - 2024 tonymacx86 LLC
Back
Top