BrcmPatchRAM - Upload firmware into Broadcom Bluetooth USB devices

[the-darkvoid]

Skvo,

Thank you for the feedback, the vendor ID typo has been fixed in both posts.
Also I have included your device in the configuration, in the driver package I used its showing as:

%BRCM20702Combo.DeviceDesc%=BlueRAMUSB3411,     USB\VID_13D3&PID_3411       ; Dell Alienware 4352 20702A1 combo

So I named it "Dell Alienware (4352/20702A1 combo)" for now.

Configuration now allows for shared firmwares across devices through BrmFirmwareStore, simplifying the configuration of many devices.

So you can try if your device works fine with a newer firmware, my guess is that "BCM20702A1_001.002.014.1443.1612_v5708" as FirmwareKey will work just fine.
But even newer ones might work also.

Let me know results if you test any newer firmware versions.

 

[the-darkvoid]

Are there any functional differences between the different versions of the FW in the repo?

Other than the age old adage "newer is better", nothing that is documented or noticeable.
Personally I used the newest firmware available for my device and have not experienced any problems.
Through the BrmFirmwareStore repository you can now easily switch between firmware versions to test.

As more people test, I am sure we will get more clarity on how it works.

Additionally I have added some more details on the hex firmware filename formats in the first post, at least what I have noticed until now.

 

[vbo]

Sounds good. Thanks a lot for writing this kext and making it available!

 

[RehabMan]

Sounds good. Thanks a lot for writing this kext and making it available!

+1. Sounds like good results here...

It makes me want to attempt a BCM rebrand on my Lenovo u430. The Lenovo u430 accepts only a Lenovo branded BCM943228HMB, so I would need to rebrand a compatible card with the vendor/device/subven/subdev of the accepted Lenovo card, then do the appropriate kext patching to make the drivers work.

I'm currently using an AR9280 rebranded as (Lenovo) AR946x, but no BT of course.

 

[the-darkvoid]

It makes me want to attempt a BCM rebrand on my Lenovo u430. The Lenovo u430 accepts only a Lenovo branded BCM943228HMB, so I would need to rebrand a compatible card with the vendor/device/subven/subdev of the accepted Lenovo card, then do the appropriate kext patching to make the drivers work.

Rehabman,

If you get a non-PatchRAM Broadcom Bluetooth USB its theoretically possible to flash normal Apple firmware into it, turning it into an authentic Apple Bluetooth USB (Or alternatively flash it to authentic Lenovo)

The firmwares are sitting in:
/System/Library/Extensions/IOBluetoothFamily.kext/Contents/PlugIns/IOBluetoothUSBDFU.kext/Contents/Resources/*.dfu. The plist determines which device gets what firmware.

When OS X finds that an Bluetooth device has not been updated yet, IOBluetoothUSBDFU kicks in and performs a DFU upgrade of the Bluetooth device.

However Apple's IOBluetoothUSBDFU obviously validates the VID/PID before flashing.

I already wrote a tool which does this (much similar to Apples IOBluetoothUSBDFUTool), you can find the source code of it here: https://github.com/the-darkvoid/dfu-util-osx

I tried using it with my Toshiba NGFF Bluetooth, it does enter DFU mode correctly (New USB device called Broadcom DFU Upgrade device appears), but does not accept Apple firmwares.
My theory is that it does not accept them because its a PatchRAM based device and not a DFU firmware flashable device.

 

[RehabMan]

Rehabman,

If you get a non-PatchRAM Broadcom Bluetooth USB its theoretically possible to flash normal Apple firmware into it, turning it into an authentic Apple Bluetooth USB (Or alternatively flash it to authentic Lenovo)

The firmwares are sitting in:
/System/Library/Extensions/IOBluetoothFamily.kext/Contents/PlugIns/IOBluetoothUSBDFU.kext/Contents/Resources/*.dfu. The plist determines which device gets what firmware.

When OS X finds that an Bluetooth device has not been updated yet, IOBluetoothUSBDFU kicks in and performs a DFU upgrade of the Bluetooth device.

However Apple's IOBluetoothUSBDFU obviously validates the VID/PID before flashing.

I already wrote a tool which does this (much similar to Apples IOBluetoothUSBDFUTool), you can find the source code of it here: https://github.com/robvanoostenrijk/dfu-util-osx

I tried using it with my Toshiba NGFF Bluetooth, it does enter DFU mode correctly (New USB device called Broadcom DFU Upgrade device appears), but does not accept Apple firmwares.
My theory is that it does not accept them because its a PatchRAM based device and not a DFU firmware flashable device.

Thanks for the info, but...

I'll go without BT before using a precious USB port for it.

I'll only use BT if I can get it working with a built-in half-mini PCIe.

 

[the-darkvoid]

Rehabman,

Would it be interesting to apply the same architecture for an Atheros 3K bluetooth enabler?
Using the shared firmware storage approach it should be possible to support a multitude of Atheros devices (unsure though how many are supported on OS X).

I am aware an existing driver exists for a number of Atheros devices, but maybe it can be improved upon.

A list of devices using USB firmware flashing for Atheros chips can be find here:
http://lxr.free-electrons.com/source/drivers/bluetooth/ath3k.c

Let me know your thoughts. I would need your help as I have no Atheros Bluetooth chip to test with.

 

[RehabMan]

Rehabman,

Would it be interesting to apply the same architecture for an Atheros 3K bluetooth enabler?
Using the shared firmware storage approach it should be possible to support a multitude of Atheros devices (unsure though how many are supported on OS X).

I am aware an existing driver exists for a number of Atheros devices, but maybe it can be improved upon.

A list of devices using USB firmware flashing for Atheros chips can be find here:
http://lxr.free-electrons.com/source/drivers/bluetooth/ath3k.c

Let me know your thoughts. I would need your help as I have no Atheros Bluetooth chip to test with.

I don't have any Atheros BT devices either. The Atheros implementation is so poor that it is not worth implementing.

 

[the-darkvoid]

I don't have any Atheros BT devices either. The Atheros implementation is so poor that it is not worth implementing.

You mean the implementation of the actual product? Or what is existing for OS X?

Also I just updated BrcmPatchRAM to v0.3, it now uses firmware caching to speed up wake-up from sleep.
Bluetooth now re-appears instantly on wake-up.

 

[RehabMan]

You mean the implementation of the actual product? Or what is existing for OS X?

I think it is firmware issues... (and I think most are only BT3, not BT4LE)...

Also I just updated BrcmPatchRAM to v0.3, it now uses firmware caching to speed up wake-up from sleep.
Bluetooth now re-appears instantly on wake-up.

Nice...