BrcmPatchRAM - Upload firmware into Broadcom Bluetooth USB devices

[RehabMan]

Hmm. Could that have an affect on my Bluetooth?

Take a look at this IOReg. This is what happens after a "failed" firmware upload (BT is dead right now). The kext output indicates that the firmware upload was successful.

EDIT: Looks like BT is always under HS07 when it is loaded in XHCI. Is there anything I might want to change in my port injector for this port?

UsbConnector for HS07 is wrong. It is internal, therefore should be 255, not 3.

 

[CoBrA2168]

UsbConnector for HS07 is wrong. It is internal, therefore should be 255, not 3.

The same for HS08 too, correct? (since that's the webcam). I made those changes but IOReg still says UsbConnector is 0x3.

EDIT: Nevermind...I forgot to copy the compiled AML to ACPI/patched. Now it's showing as Built-In. Do you think that will have an affect on functionality?

 

[RehabMan]

The same for HS08 too, correct? (since that's the webcam).

Yes.

Do you think that will have an affect on functionality?

I never attempt to predict the future.

 

[CoBrA2168]

Yes.



I never attempt to predict the future.

Ok, I will just continue testing.

One last question about EHCI vs XHCI: is there any benefit or downside to letting the USB devices fall under XHCI instead of using FakePCIID_XHCIMux to force the USB 2.0 devices on EHCI? I have port injector SSDTs for both and this doesn't seem to be why my bluetooth isn't working correctly.

 

[RehabMan]

Ok, I will just continue testing.

One last question about EHCI vs XHCI: is there any benefit or downside to letting the USB devices fall under XHCI instead of using FakePCIID_XHCIMux to force the USB 2.0 devices on EHCI? I have port injector SSDTs for both and this doesn't seem to be why my bluetooth isn't working correctly.

On my systems, I find XHCI to be faster than EHCI (with same USB2 device)...

 

[CoBrA2168]

On my systems, I find XHCI to be faster than EHCI (with same USB2 device)...

It appears that bluetooth will still sometimes fail to upload the RAM, even though the USB seems correct (it's always loading up on HS07 under XHCI and is always present, even after sleep/wake cycle).

Do I have any other alternatives other than using the 2 kexts in this post? Are there other methods of injecting the firmware? Could I need further changes to my DSDT?

Here's what the log looks like from BcrmPatchRAM when it "fails"

Nov 18 07:47:02 Josh-Lenovo kernel[0]: BrcmPatchRAM2: Version 2.2.7 starting on OS X Darwin 15.6.
Nov 18 07:47:02 Josh-Lenovo kernel[0]: BrcmPatchRAM2: [0a5c:216f]: USB [C48E8FF8AA1A v274] "BCM20702A0" by "Broadcom Corp"
Nov 18 07:51:02 Josh-Lenovo kernel[0]: BrcmPatchRAM2: [0a5c:216f]: Firmware upgrade completed successfully.
Nov 18 07:51:02 Josh-Lenovo kernel[0]: BrcmPatchRAM2: [0a5c:216f]: Found existing IOKit personality "com.apple.iokit.BroadcomBluetoothHostControllerUSBTransport".
Nov 18 07:51:02 Josh-Lenovo kernel[0]: BrcmPatchRAM2: Processing time 240.24 seconds.

In these cases when it fails, it always takes 240 seconds or 180 seconds (4 minutes or 3 minutes). This also happened when I had EHCI disabled, so I don't think that's the cause of the problem.

 

[RehabMan]

It appears that bluetooth will still sometimes fail to upload the RAM, even though the USB seems correct (it's always loading up on HS07 under XHCI and is always present, even after sleep/wake cycle).

Do I have any other alternatives other than using the 2 kexts in this post? Are there other methods of injecting the firmware? Could I need further changes to my DSDT?

Here's what the log looks like from BcrmPatchRAM when it "fails"

Nov 18 07:47:02 Josh-Lenovo kernel[0]: BrcmPatchRAM2: Version 2.2.7 starting on OS X Darwin 15.6.
Nov 18 07:47:02 Josh-Lenovo kernel[0]: BrcmPatchRAM2: [0a5c:216f]: USB [C48E8FF8AA1A v274] "BCM20702A0" by "Broadcom Corp"
Nov 18 07:51:02 Josh-Lenovo kernel[0]: BrcmPatchRAM2: [0a5c:216f]: Firmware upgrade completed successfully.
Nov 18 07:51:02 Josh-Lenovo kernel[0]: BrcmPatchRAM2: [0a5c:216f]: Found existing IOKit personality "com.apple.iokit.BroadcomBluetoothHostControllerUSBTransport".
Nov 18 07:51:02 Josh-Lenovo kernel[0]: BrcmPatchRAM2: Processing time 240.24 seconds.

In these cases when it fails, it always takes 240 seconds or 180 seconds (4 minutes or 3 minutes). This also happened when I had EHCI disabled, so I don't think that's the cause of the problem.

It could be a timing issue between BrcmPatchRAM and the native BT kexts... (eg. contention for the actual device).
I have not run into it though...

I would test firmware upload separate from bluetooth. Remove native BT kexts so they won't load... Then test with only BrcmPatchRAM loading firmware to see if it happens without any possibility of contention.

If it still happens, then you know it is likely a contention issue... (serious changes required for BrcmPatchRAM).
If it does not happen, then you know it is likely a general USB problem or some problem with your specific device.

 

[CoBrA2168]

It could be a timing issue between BrcmPatchRAM and the native BT kexts... (eg. contention for the actual device).
I have not run into it though...

That's what I was thinking too.

Is there a way I can delay BcrmPatchRAM from loading after a wake?

 

[CoBrA2168]

It could be a timing issue between BrcmPatchRAM and the native BT kexts... (eg. contention for the actual device).
I have not run into it though...

I would test firmware upload separate from bluetooth. Remove native BT kexts so they won't load... Then test with only BrcmPatchRAM loading firmware to see if it happens without any possibility of contention.

If it still happens, then you know it is likely a contention issue... (serious changes required for BrcmPatchRAM).
If it does not happen, then you know it is likely a general USB problem or some problem with your specific device.

Is that native kext called IOBluetoothFamily?

 

[RehabMan]

Is that native kext called IOBluetoothFamily?

Disabling native BT:

cd /System/Library/Extensions
sudo mv IOBluetoothFamily.kext IOBluetoothFamily.kext.bak