Contribute
Register

[Guide] 10.11+ USB changes and solutions

Status
Not open for further replies.
Incomplete "Problem Reporting" files, no idea.

Hey RehabMan, the question was more of a hypothetical question... If the device doesn't get listed in ioreg, then there's no amount of kexting/patching that will suddenly make it appear right?

FYI, I was able to get the AW-CE123H BT adapter working after futzing around with hardware... Trial and error does pay off.. =) I decided to try plugging in my X220's BT daughter card back onto the motherboard and discovered that OS X still didn't see either BT devices on the AW-CE123H or the BTDC. Confused, I swapped HDD's to my windows install and noticed that the BDC was getting detected but failed to initialize (which was different behaviour than I had experienced previously when both BT devices were installed). So I swapped back to the OS X install and it still didn't see any BT devices. I swapped back to Windows, and Disabled the uninitialized BT module. I then swapped back to the OS X install and booted and not only do I now see both BT devices in ioreg, System Info lists the devices as BTLE capable now (which is what i was trying to do in the first place). I've tested Airdrop successfully but handoff/continuity is still MIA.

I've removed all troubleshooting kexts and patches.. No renaming of ports, no USBInjectAll, Just BrcmFirmwareRepo, BrcmPatchRAM2, FakePCIID, FakePCIID_Broadcom_Wifi, and Broadcom_Bluetooth

I'm not entirely sure what made it work but the order the Bluetooth Devices are being detected by the BIOS seems to be related. I'm going to do a write up in a separate thread to share my findings...

Now time to figure out continuity and handoff

Thanks
 

Attachments

  • IORegistryExplorer_output_with_both_BT_adapters.ioreg
    5.2 MB · Views: 109
Hey RehabMan, the question was more of a hypothetical question... If the device doesn't get listed in ioreg, then there's no amount of kexting/patching that will suddenly make it appear right?

Sometimes it is the excess of (incorrect) fixes that causes the problem.
 
Sometimes it is the excess of (incorrect) fixes that causes the problem.

Yes, I tend to try a lot of different things and that certainly makes it more confusing when it suddenly works... BTW, you mentioned in the past that to avoid confusion between two BT devices, I could disable the USB port that the undesirable BT device is connected to. Can you elaborate on that process?

I found out that after resuming from sleep, the thinkpad's BTDC takes precedence over the wifi+BT device and I lose BTLE. =(I'm hoping if I disable the USB Port that the BTDC is connected to, it'll stop this from happening)

Thanks,
 
Yes, I tend to try a lot of different things and that certainly makes it more confusing when it suddenly works... BTW, you mentioned in the past that to avoid confusion between two BT devices, I could disable the USB port that the undesirable BT device is connected to. Can you elaborate on that process?

I found out that after resuming from sleep, the thinkpad's BTDC takes precedence over the wifi+BT device and I lose BTLE. =(I'm hoping if I disable the USB Port that the BTDC is connected to, it'll stop this from happening)

Thanks,

You can use USBInjectAll.kext to inject only the ports you want.
 
You can use USBInjectAll.kext to inject only the ports you want.

Oh! I get it now.. haha.. I read through the documentation and didn't quite understand but now I think I do...

So if my unwanted BT device is on

IOService:/AppleACPIPlatformExpert/PCI0@0/AppleACPIPCI/EH02@1A/EH02@1a000000/URMH@1a100000/IOUSBHostDevice@1a100000/AppleUSB20InternalIntelHub@1a100000/PRTB@1a140000

All I need to do is install USBInjectAll.kext to /S/L/E and modify my clover config.plist to have the following kernel flag:

uia_exclude=PRTB

Do I also need the DSDT patch to rename EHC1 to EH01 (though i think with series 6 chipsets, it's already named EH01/EH02 from what I can see in my ioreg output)?

Thanks!

Edit: I went ahead and did the above.. found out that USBInjectAll.kext renames the ports so I had to adjust the kernel flag. Device ended up on HP24 so:

uia_exclude=HP24

Now in ioreg, i see HP24 gets skipped! Yay! and resuming from sleep doesn't screw up my BT...
 
Last edited:
Oh! I get it now.. haha.. I read through the documentation and didn't quite understand but now I think I do...

So if my unwanted BT device is on

IOService:/AppleACPIPlatformExpert/PCI0@0/AppleACPIPCI/EH02@1A/EH02@1a000000/URMH@1a100000/IOUSBHostDevice@1a100000/AppleUSB20InternalIntelHub@1a100000/PRTB@1a140000

All I need to do is install USBInjectAll.kext to /S/L/E and modify my clover config.plist to have the following kernel flag:

uia_exclude=PRTB

Do I also need the DSDT patch to rename EHC1 to EH01 (though i think with series 6 chipsets, it's already named EH01/EH02 from what I can see in my ioreg output)?

Thanks!

Edit: I went ahead and did the above.. found out that USBInjectAll.kext renames the ports so I had to adjust the kernel flag. Device ended up on HP24 so:

uia_exclude=HP24

Now in ioreg, i see HP24 gets skipped! Yay! and resuming from sleep doesn't screw up my BT...

It is best to use an SSDT (for customizing USBInjectAll) so you can inject only the ports needed, and set UsbConnector to the correct value for each port.
 
It is best to use an SSDT (for customizing USBInjectAll) so you can inject only the ports needed, and set UsbConnector to the correct value for each port.

Okay.. So I read through the patching laptop DSDT/SSDT thread. I got as far as extracting the SSDTs using patchmatic but disassembly via iasl fails or it's writing files somewhere I'm not aware of.

I think i'm well over my head at this point... Am i going in the right direction or have I completely misinterpreted your advice?

Thanks again!!!
 
Okay.. So I read through the patching laptop DSDT/SSDT thread. I got as far as extracting the SSDTs using patchmatic but disassembly via iasl fails or it's writing files somewhere I'm not aware of.

I think i'm well over my head at this point... Am i going in the right direction or have I completely misinterpreted your advice?

Thanks again!!!

You should extract with Clover F4, but...

You do not need to patch any OEM SSDTs/DSDT in order to create a custom SSDT for USBInjectAll. Modify SSDT-UIAC-ALL.dsl to correspond to your USB configuration.
 
You should extract with Clover F4, but...

You do not need to patch any OEM SSDTs/DSDT in order to create a custom SSDT for USBInjectAll. Modify SSDT-UIAC-ALL.dsl to correspond to your USB configuration.

I tried F4 via clover but it never wrote anything.. in anycase, since that's not really needed, What exactly do I do with the modified SSDT-UIAC-ALL.dsl file? I thought that file needs to be recompiled into a new .aml file?

Thanks,
 
I tried F4 via clover but it never wrote anything..

Perhaps ACPI/origin does not exist. Or you didn't press F4 (some laptops reverse Fn+F4 for F4).

in anycase, since that's not really needed, What exactly do I do with the modified SSDT-UIAC-ALL.dsl file? I thought that file needs to be recompiled into a new .aml file?

Thanks,

First, you need to use IORegistryExplorer to determine the USB ports that are actually used (and determine which are USB2, which are USB3, which are attached to internal devices). Then customize SSDT-UIAC-ALL.dsl to fit your findings... Save as AML (MaciASL, format: ACPI Machine Language Binary), and place in ACPI/patched where it can be loaded by Clover (if you're using SortedOrder, make sure it refers to your SSDT-UIAC file).
 
Status
Not open for further replies.
Back
Top