BrcmPatchRAM - Upload firmware into Broadcom Bluetooth USB devices

[the-darkvoid]

ATM, I have no idea where the firmwares are stored in 10.11... If you have some idea about it, let me know...

Firmware uploads are done by a user-mode process (at least they were up to Yosemite), I can still see this present in El Capitan. Though I haven't verified if its still actively used, it does look like.

The kext which takes care of this is IOBluetoothUSBDFU.kext which kicks in on boot, verifies if the device needs a firmware update.

The firmware update itself is done through /System/Library/Extensions/IOBluetoothFamily.kext/Contents/PlugIns/IOBluetoothUSBDFU.kext/Contents/Resources/IOBluetoothUSBDFUTool.

Each firmware is stored in the DFU files (you can find the matching devices in the associated plist).
The DFU format is simply a binary format of the normal HEX firmware format stored as USB upgrade instructions. Additionally there is a trailing data record which indicates the size, firmware version and device / vendor ID details.

Apple devices however are not PatchRAM devices, so any firmware update done on an Apple Bluetooth is persistent and stays across reboots. So Apple merely patches firmware into its bluetooth dongles when OS X is upgraded and provides a new firmware upgrade.

So ideally BrcmPatchRAM should still be applicable for El Capitan, in order to provide non-persistent (PatchRAM) firmware updates.

As you mentioned this might require a new branch of BrcmPatchRAM to accommodate the new USB structure, if its not possible to handle this within the existing code-base.

Or we could tap into the user-mode upgrade process Apple uses and add additional firmwares.
I wrote equivalent code for it before... (https://github.com/the-darkvoid/dfu-util-osx - use with care)

 

[RehabMan]

Firmware uploads are done by a user-mode process (at least they were up to Yosemite), I can still see this present in El Capitan. Though I haven't verified if its still actively used, it does look like.

The kext which takes care of this is IOBluetoothUSBDFU.kext which kicks in on boot, verifies if the device needs a firmware update.

The firmware update itself is done through /System/Library/Extensions/IOBluetoothFamily.kext/Contents/PlugIns/IOBluetoothUSBDFU.kext/Contents/Resources/IOBluetoothUSBDFUTool.

Each firmware is stored in the DFU files (you can find the matching devices in the associated plist).
The DFU format is simply a binary format of the normal HEX firmware format stored as USB upgrade instructions. Additionally there is a trailing data record which indicates the size, firmware version and device / vendor ID details.

Apple devices however are not PatchRAM devices, so any firmware update done on an Apple Bluetooth is persistent and stays across reboots. So Apple merely patches firmware into its bluetooth dongles when OS X is upgraded and provides a new firmware upgrade.

So ideally BrcmPatchRAM should still be applicable for El Capitan, in order to provide non-persistent (PatchRAM) firmware updates.

As you mentioned this might require a new branch of BrcmPatchRAM to accommodate the new USB structure, if its not possible to handle this within the existing code-base.

Or we could tap into the user-mode upgrade process Apple uses and add additional firmwares.
I wrote equivalent code for it before... (https://github.com/the-darkvoid/dfu-util-osx - use with care)

Support for patch-ram devices seems to be present in 10.11.

Evidence: Working BT on cold boot and after sleep with patch-ram device without BrcmPatchRAM.kext (only injected personality).

The only reason we need BrcmPatchRAM.kext for 10.11 is the case where the firmware Apple has does not work with a given device.

I may have a chance later this week to finish my changes to BrcmPatchRAM for the new USB interfaces. Stay tuned...

 

[the-darkvoid]

Rehabman,

What firmware version does El Capitan upload in your device? And what are the device details?
i will see if I can check where it comes from, maybe we can "inject" new devices as well as firmwares for Apple to upload.

 

[RehabMan]

Rehabman,

What firmware version does El Capitan upload in your device? And what are the device details?
i will see if I can check where it comes from, maybe we can "inject" new devices as well as firmwares for Apple to upload.

Device is 0a5c:21fb. I have two of these (one for my u430 and the other installed in my BRIX).

According to System Information, it loads v5744. Amazingly, the same firmware that is currently in BrcmPatchRAM's Info.plist for the same device.

 

[the-darkvoid]

Ok, I will do some digging to determine for sure where the firmware for your device is originating from in El Capitan.

 

[verleihnix]

Hmmm.. strange. Even my very limited laptop BIOS has an option for whether USB can cause wake...

There are ways to disable wake with DSDT patches...

Your other device has built-in firmware.

Is it a matter of BT FW or FW loaded by kext which causes the instant wake?
From my point of view my builds don't have generally sleep issues.
With the BT400 or a CSR 4.0 device it stays in sleep mode and it wakes by mouse key.
If you disable "wake by USB" it wakes only by power button.

 

[RehabMan]

Is it a matter of BT FW or FW loaded by kext which causes the instant wake?
From my point of view my builds don't have generally sleep issues.
With the BT400 or a CSR 4.0 device it stays in sleep mode and it wakes by mouse key.

Check "Wake reason" in system.log.

If you disable "wake by USB" it wakes only by power button.

As should be expected.

 

[verleihnix]

Check "Wake reason" in system.log.

11.08.15 17:56:39,000 kernel[0]: Wake reason: GLAN EHC2
11.08.15 17:56:39,000 kernel[0]: The USB device HubDevice (Port 1 of Hub at 0x1a000000) may have caused a wake by issuing a remote wakeup (2)
11.08.15 17:56:39,000 kernel[0]: The USB device BCM20702A0 (Port 1 of Hub at 0x1a100000) may have caused a wake by issuing a remote wakeup (3)

 

[RehabMan]

11.08.15 17:56:39,000 kernel[0]: Wake reason: GLAN EHC2
11.08.15 17:56:39,000 kernel[0]: The USB device HubDevice (Port 1 of Hub at 0x1a000000) may have caused a wake by issuing a remote wakeup (2)
11.08.15 17:56:39,000 kernel[0]: The USB device BCM20702A0 (Port 1 of Hub at 0x1a100000) may have caused a wake by issuing a remote wakeup (3)

EHC2 == USB. Your USB BT device is causing "instant wake". Disable "Wake on USB"...

You might be able to avoid it by disabling BT wake in Bluetooth prefs.

 

[verleihnix]

EHC2 == USB. Your USB BT device is causing "instant wake". Disable "Wake on USB"...

You might be able to avoid it by disabling BT wake in Bluetooth prefs.

Yes, but why does it only wake if BrcmPatchRAM is loaded?
Same BT device without BrcmPatchRAM stays a sleep till mouse button is pressed.
I would like to figure out why it happens to use a finding where the kext is needed to make the BT device functioning.