Fujitsu W380 with XEON X3460, EHCI #1 no drivers loaded

[gappy2k]

Hi, first thanks for the forum. I learned a lot for installing my hackintosh.
But now I got a problem. My first USB 'EH01' is not running on Sierra. EH02 is running fine. Looking in ioreg the device-id for 'EH01' is wrong. Could this a problem? I tried everything from this thread first page except the XHCI patches because I don't have USB3.

USBInjectAll says on on boot only:"USBInjectAll: trying 'EH02'" and " ..trying'HUB2'" but not EH01.
I packed my dsdt and config.plist at the thread.

My dsdt.aml and config.plist
CloverFiles.zip

Hopefully somebody could help, thanks.

 

[RehabMan]

Hi, first thanks for the forum. I learned a lot for installing my hackintosh.
But now I got a problem. My first USB 'EH01' is not running on Sierra. EH02 is running fine. Looking in ioreg the device-id for 'EH01' is wrong. Could this a problem? I tried everything from this thread first page except the XHCI patches because I don't have USB3.

USBInjectAll says on on boot only:"USBInjectAll: trying 'EH02'" and " ..trying'HUB2'" but not EH01.
I packed my dsdt and config.plist at the thread.

View attachment 234584
My dsdt.aml and config.plist
CloverFiles.zip

Hopefully somebody could help, thanks.

Read post #1, "Problem Reporting".

 

[gappy2k]

Oh, sorry I forgot. There is my Problem reporting. I attached two pics from windows usbview which shows both controllers (3B34 is the Backside output) of my Futjisu W380 Tower.

 

[RehabMan]

Oh, sorry I forgot. There is my Problem reporting. I attached two pics from windows usbview which shows both controllers (3B34 is the Backside output) of my Futjisu W380 Tower.

Nothing wrong with device-id on EH01.
Why do you have the _OSI->XOSI patch without SSDT-XOSI.aml? It is an invalid configuration.
Your patched DSDT is not in sync with native. SystemMemory addresses have changed since you last extracted/patched...

<         OperationRegion (SMI1, SystemMemory, 0xBF7C7EB4, 0x90)
>         OperationRegion (SMI1, SystemMemory, 0xBF4B3EB4, 0x90)
<         OperationRegion (ABGC, SystemMemory, 0xBF7C7FB4, One)
>         OperationRegion (ABGC, SystemMemory, 0xBF4B3FB4, One)
<         OperationRegion (TCG1, SystemMemory, 0xBF7C7FB5, 0x07)
>         OperationRegion (TCG1, SystemMemory, 0xBF4B3FB5, 0x07)

 

[gappy2k]

Nothing wrong with device-id on EH01.
Why do you have the _OSI->XOSI patch without SSDT-XOSI.aml? It is an invalid configuration.
Your patched DSDT is not in sync with native. SystemMemory addresses have changed since you last extracted/patched...

<         OperationRegion (SMI1, SystemMemory, 0xBF7C7EB4, 0x90)
>         OperationRegion (SMI1, SystemMemory, 0xBF4B3EB4, 0x90)
<         OperationRegion (ABGC, SystemMemory, 0xBF7C7FB4, One)
>         OperationRegion (ABGC, SystemMemory, 0xBF4B3FB4, One)
<         OperationRegion (TCG1, SystemMemory, 0xBF7C7FB5, 0x07)
>         OperationRegion (TCG1, SystemMemory, 0xBF4B3FB5, 0x07)

Hi,
I put the function into my dsdt.aml, since i didn't know to load like sorted order. But the XOSI is working, i could give a try to sorted order?
One problem could be. I extraced the fist dsdt with windows and did the patching to boot macos.

So i'll do a fresh patch of my origin dsdt.aml from clover to keep memorys sync? The only Patches I did to my dsdt was, Rename Patch to Darwin and the T_0 Patch. I think clover could this do on runtine.
But then my device EH01 is original USB1, could i patch it after clover did rename patch?

Thanks for the first hint. I reply later after changing.

 

[RehabMan]

Hi,
I put the function into my dsdt.aml, since i didn't know to load like sorted order. But the XOSI is working, i could give a try to sorted order?
One problem could be. I extraced the fist dsdt with windows and did the patching to boot macos.

So i'll do a fresh patch of my origin dsdt.aml from clover to keep memorys sync? The only Patches I did to my dsdt was, Rename Patch to Darwin and the T_0 Patch. I think clover could this do on runtine.
But then my device EH01 is original USB1, could i patch it after clover did rename patch?

Thanks for the first hint. I reply later after changing.

You must re-extract ACPI, re-patch whenever:
- BIOS options have changed
- BIOS has been updated (or downgraded)
- hardware has changed

 

[gappy2k]

Hi,

You must re-extract ACPI, re-patch whenever:
- BIOS options have changed
- BIOS has been updated (or downgraded)
- hardware has changed

I can't say that I changed something to the ACPI BIOS, but I went back to start with your hint
I deleted my DSDT.aml and could boot my macOS.
I took things from Your config.plist ACPI implementation for Lenovo U430 and did the XOSI Patch and USB1/2->EH01/2 rename for my board.
Now I boot without a dedicated dsdt.aml and only with changes from config.plist. But the behaviour is the same. Only EH02 is active and EH01 not.
USBInjectALL is injected from CLOVER.
Hopefully you could help.

 

[RehabMan]

Hi,

I can't say that I changed something to the ACPI BIOS, but I went back to start with your hint
I deleted my DSDT.aml and could boot my macOS.
I took things from Your config.plist ACPI implementation for Lenovo U430 and did the XOSI Patch and USB1/2->EH01/2 rename for my board.
Now I boot without a dedicated dsdt.aml and only with changes from config.plist. But the behaviour is the same. Only EH02 is active and EH01 not.
USBInjectALL is injected from CLOVER.
Hopefully you could help.

You should try with config.plist/Devices/USB/FixOwnership=true.

 

[gappy2k]

You should try with config.plist/Devices/USB/FixOwnership=true.

Sorry I had no luck, same behaviour.
I also did the trick an Rename USB1->EH02 and USB2->EH01, then USBinject inject the working one, USB2 as EH01 (Adress 0x1A000000) again. The back USBports (0x1D) won't come up. I looked through ACPI SPEC 6.1 but I can't really see a problem. The only thing what gets me thinking is the 3rd VRTHub after the Hub in my ACPI specification, as ACPI Spec describes only one hub after the usb controller.
But the ports of EH02 (0x1A) will also injected without USBInject ors XOSI patch, they run since installation. Only EH01 is my Problem.
Do you have a next idea? How could I debug the USB Inject, why there is not finding the EH01? Or do you think there is a hard ACPI USB problem?

I added my 'dames' boot output where the change EH01/EH02 is booting.

Thanks Gappy

 

[RehabMan]

Sorry I had no luck, same behaviour.
I also did the trick an Rename USB1->EH02 and USB2->EH01, then USBinject inject the working one, USB2 as EH01 (Adress 0x1A000000) again. The back USBports (0x1D) won't come up. I looked through ACPI SPEC 6.1 but I can't really see a problem. The only thing what gets me thinking is the 3rd VRTHub after the Hub in my ACPI specification, as ACPI Spec describes only one hub after the usb controller.
But the ports of EH02 (0x1A) will also injected without USBInject ors XOSI patch, they run since installation. Only EH01 is my Problem.
Do you have a next idea? How could I debug the USB Inject, why there is not finding the EH01? Or do you think there is a hard ACPI USB problem?

Thanks Gappy

Must always provide "Problem Reporting" files.