Contribute
Register

A Beginner's Guide to Creating a Custom USB SSDT

I'm using Intel 9260 includes Bluetooth adapter (connect through USB Power, Wifi on PCI.E slot).
The problem is I've complied SSDT-UIAC and SSDT-EC-USBX but I afraid it will crash current EFI boot so I have not replaced SSDT-EC-USBX yet because the different was too large (SSDE-EC-USBX I'm using from Opencore guide: https://github.com/dortania/Getting...extra-files/compiled/SSDT-EC-USBX-DESKTOP.aml)

So for now, I've only add one more file is SSDT-UIAC. However it doesn't work although it's Internal, the port I'm using is HS01

View attachment 478784

btw, it's missing XHC on the top as well :(


Yes, there are certainly problems in this configuration.

Two things would be helpful:

1) A IORegistryExplorer v2.1 export file - *.IOReg so we can see the ports in whatever state.

2) A list of kexts you have in EFI/OC/Kexts and in Drive: Library/Extensions

Something is stopping XHCI from showing so double-check your BIOS setting for XHCI Hand-off.

:)
 
Yes, there are certainly problems in this configuration.

Two things would be helpful:

1) A IORegistryExplorer v2.1 export file - *.IOReg so we can see the ports in whatever state.

2) A list of kexts you have in EFI/OC/Kexts and in Drive: Library/Extensions

Something is stopping XHCI from showing so double-check your BIOS setting for XHCI Hand-off.

:)
Thanks UtterDisbelief, I've checked my configuration: XHCI Han-off is enable. Here is my IORef and list of kext

1593675848111.png
1593675876856.png

Also, this is my SSDT-UIAC
 

Attachments

  • IOReg-vinh.ioreg
    7.3 MB · Views: 94
  • SSDT-UIAC.dsl
    5.5 KB · Views: 72
Thanks UtterDisbelief, I've checked my configuration: XHCI Han-off is enable. Here is my IORef and list of kext

View attachment 478804View attachment 478805
Also, this is my SSDT-UIAC


Okay, great. Thanks for the uploads.

Drive: Library/Extensions is fine. We can forget about that for now.

OC/Kexts - Is where the action is ...

This set-up is confusing Hackintool when it reads the XHC controller. This might be a bug or a pointer to something else. Although I do not think it will make much difference you probably do not require the XHCI-unsupported.kext for your chipset. If that doesn't make a difference then remove USBInjectAll.kext and check again to see what it shows. You should now only get 15-ports.

At present you have 20-ports configured and this is not recommended. The whole point of configuring USB is to keep within the 15-limit. Yes, some people disagree. I'll leave that for now.

You are using the iMacPro1,1 system definition so perhaps try a more reliable one, just for testing purposes, such as - iMac14,2 . (Disconnect from wireless first to avoid Apple servers being confused while you test). It is known to be more easy-going, but may reduce performance vey slightly. At least it is worth testing for this problem.

Currently the Bluetooth adapter is buried too deep in "hubs" to be controllable. This may also be due to the IntelBluetoothInjector.kext and IntelBluetoothFirmware.kext and may not be easily resolved. In which case it might be better to use a USB BT adapter.

:)
 
Okay, great. Thanks for the uploads.

Drive: Library/Extensions is fine. We can forget about that for now.

OC/Kexts - Is where the action is ...

This set-up is confusing Hackintool when it reads the XHC controller. This might be a bug or a pointer to something else. Although I do not think it will make much difference you probably do not require the XHCI-unsupported.kext for your chipset. If that doesn't make a difference then remove USBInjectAll.kext and check again to see what it shows. You should now only get 15-ports.

At present you have 20-ports configured and this is not recommended. The whole point of configuring USB is to keep within the 15-limit. Yes, some people disagree. I'll leave that for now.

You are using the iMacPro1,1 system definition so perhaps try a more reliable one, just for testing purposes, such as - iMac14,2 . (Disconnect from wireless first to avoid Apple servers being confused while you test). It is known to be more easy-going, but may reduce performance vey slightly. At least it is worth testing for this problem.

Currently the Bluetooth adapter is buried too deep in "hubs" to be controllable. This may also be due to the IntelBluetoothInjector.kext and IntelBluetoothFirmware.kext and may not be easily resolved. In which case it might be better to use a USB BT adapter.

:)

Thanks for the advice.
I updated to iMac19,1 but it didn't resolve much.
I'm trying to create USB boot, avoid doing directly from my hard drive EFI (I installed hackintosh on an individual ssd) but keep notifying this error no matter how I reload it

1593690822604.png


Step I did to Format USB by disk Utility:
- Erase & select Mac OS Extended (Journaled)
- Create EFI folder, copy exist EFI from hard drive to USB EFI
- Boot to USB EFI, caught above error
 
Last edited:
Thanks for the advice.
I updated to iMac19,1 but it didn't resolve much.
I'm trying to create USB boot, avoid doing directly from my hard drive EFI (I installed hackintosh on an individual ssd) but keep notifying this error no matter how I reload it

View attachment 478840

Step I did to Format USB by disk Utility:
- Erase & select Mac OS Extended (Journaled)
- Create EFI folder, copy exist EFI from hard drive to USB EFI
- Boot to USB EFI, caught above error


iMac19,1 is not the same as iMac14,2.

You need to create a boot USB using UniBeast :thumbup:
 
I changed to iMac14,2 but it still wake up right after sleeping, maybe it really need to map USB
I don't have EFI, kexts for clover boot :(
 
No necessarily. You can still create an SSDT but you would need to do it the "old" way. This involves manually creating an SSDT template, something Hackintool now does behind the scenes, by filling-in the gaps using Sherlock Holmes-like deduction to figure out the port numbers.

For the same reason the latest High Sierra PLRPs don't work, Mojave has had Security Updates too and 10.14.6+ has no new PLRPs either, so be aware.

Remember the Renesas chipset will still work but is unconfigurable if GenericUSBXHCI.kext doesn't latch on to it. Hackintool can be hit and miss in recognising these third-party USB solutions. However, the ports do not figure in our 15-limit so if they work you can use them, but be aware they may be unreliable without drivers.

I'm trying 'the old way' but I don't have "a set of HS**@ labels followed by numbers" in IORegistry.

And my USB 3.0 isn't seen in OSX System Report or in IORegistry. Where I'm confused is this:

Is this guide for situations where USB 3 ports are seen in system details but don't work properly (and that's what we're fixing) or is it a guide for when there is no evidence of USB 3.0 ports in any system information - and it's fixing that? Or both?

Basically do my USB 3.0 ports have to be seen before they can be 'fixed' - or is the 'fixing' making them seen in system properties?

My USB 3.0 work at 5gb in OSX 10.8.5 but in HS there's no evidence of USB 3 ports in any system info....

I'm actually wondering about installling HS on a separate drive, WITHOUT security updates, so that I can use the 'new' method with Hackintool and then use the SSDT for the 'other drive' with the HS with updates on it. Would that be easier?
 

Attachments

  • IORegistry.png
    IORegistry.png
    122 KB · Views: 59
Last edited:
I'm trying 'the old way' but I don't have "a set of HS**@ labels followed by numbers" in IORegistry.

And my USB 3.0 isn't seen in OSX System Report or in IORegistry. Where I'm confused is this:

Is this guide for situations where USB 3 ports are seen in system details but don't work properly (and that's what we're fixing) or is it a guide for when there is no evidence of USB 3.0 ports in any system information - and it's fixing that? Or both?

Basically do my USB 3.0 ports have to be seen before they can be 'fixed' - or is the 'fixing' making them seen in system properties?

My USB 3.0 work at 5gb in OSX 10.8.5 but in HS there's no evidence of USB 3 ports in any system info....

I'm actually wondering about installling HS on a separate drive, WITHOUT security updates, so that I can use the 'new' method with Hackintool and then use the SSDT for the 'other drive' with the HS with updates on it. Would that be easier?


Both guides are for everyone using EHCI and XHCI controllers. One is more hands-on and the other more automated.

I referred you back to the original guide because it explains how to create an SSDT template manually, that's all. If you can't work with that, I'm sorry.

You have an old UHCI set of controllers. 1 & 4 are activated (there are a possible 6 in total). So, yes the ports will be enumerated differently to HS (High Speed) and SS (Super Speed). Yours is the first UHCI setup anyone has asked about and modern macOS versions were simply not coded for this by Apple. We are trying to work past this fact but it is bound to be difficult. We could rename the controllers as EHCI so that Apple sees them, but that may not work.

The IOReg screengrab you show indicates GenericUSBXHCI.kext doing its best to put the Renesas ports on an XHCI node. Your machine just does not have a real XHCI stack. Hackintool may not see this as it isn't where expected.

You ask : "Is this guide for situations where USB 3 ports are seen in system details but don't work properly (and that's what we're fixing) or is it a guide for when there is no evidence of USB 3.0 ports in any system information - and it's fixing that? Or both?"

The answer is neither. Those two scenarios are problems few have. These are guides showing how to set-up USB ports on new Hackintoshes, and for Beginners.

Sorry I don't appear to be helping you.
 
Last edited:
The answer is neither. Those two scenarios are problems few have. These are guides showing how to set-up USB ports on new Hackintoshes, and for Beginners.

Sorry I don't appear to be helping you.
Thanks for your knowledge and wisdom. My legacy mobo does seem a bit tricky to set up! I've just installed HS without security updates on a separate drive to see if the Port Limit Patch will work, but doesn't make a difference for me...

In the meantime, I've 'ordered' two different USB 3.0 PCI cards both with sata power connector (and 20 pin expansion for front panel to try out), so when they arrive I'll be able to see if HS will recognise them. If I can get a PCIe USB 3.0 to work (at 5gb speeds) then I'll post details.

Thanks again.
 
Last edited:
Back
Top