patchram

Broadcom PatchRAM DFU (Device Firmware Upgrade) utility for macOS.

Based on original dfu-tool & dfu-programmer for Linux and BrcmPatchRAM for macOS.

Supports the Intel HEX dfu file format (including zlib compressed).

NOTE: You will need to disable your bluetooth device for this tool to be able to access it.

Usage

patchram <vendorId hex> <productId hex> <firmware.dfu>

Example

./patchram 0x0a5c 0x216f ./BCM20702A1_001.002.014.1443.1572_v5668.zhx

This uses the USB DFU specification (http://www.usb.org/developers/docs/devclass_docs/DFU_1.1.pdf), to upload firmware into a DFU device.

Credits

Source

GitHub Link

Flashing firmware is dangerous and could render your device non-functional. Use this at your own risk!

USB KVM

Menu bar software for macOS 64-bit to support ActionStar chip based KVM hardware.

Vendor ID 0x2101 / 0x0835 is ActionStar (www.actionstar.com.tw)

Supported Hardware:

2101:1403, 2101:1404, 2101:1406, 2101:1407, 2101:1411, 0835:1403, 0835:1404, 0835:1406, 0835:1407, 0835:1411

Credits:

Source

GitHub Link

BrcmPatchRAM2 for macOS 10.15 Catalina

I'm just going to run through some of the changes I made to RehabMan's BrcmPatchRAM project for it to function in macOS Catalina. I don't really have time to go any further with it but hopefully my research and testing can help get an official working version out.

I'm using BrcmFirmwareData.kextBrcmPatchRAM2.kext and BrcmBluetoothInjector.kext and place them inside EFI/CLOVER/kexts/Other

BrcmBluetoothInjector.kext was not required on previous macOS releases but is on Catalina because of the following missing IOCatalogue methods:

kxld[com.no-one.BrcmPatchRAM2]: The following symbols are unresolved for this kext:
kxld[com.no-one.BrcmPatchRAM2]: IOCatalogue::addDrivers(OSArray*, bool)
kxld[com.no-one.BrcmPatchRAM2]: IOCatalogue::removeDrivers(OSDictionary*, bool)
kxld[com.no-one.BrcmPatchRAM2]: IOCatalogue::startMatching(OSDictionary*)

Since these methods are no longer available they must be removed from the project. The easiest way to do this is to comment out publishPersonality() and publishResourcePersonality() methods from BrcmPatchRAM.cpp / BrcmPatchRAM.h. Also remove all calls to these methods in BrcmPatchRAM.cpp.

The next issue is dealing with the 0xe00002c2 error when reading and writing to the BRCM hardware. Starting with BrcmPatchRAM::continuousRead() and BrcmPatchRAM::readCompletion() we need to add an kIODirectionIn option.

ie.
mReadBuffer = IOBufferMemoryDescriptor::inTaskWithOptions(kernel_task, kIODirectionIn, 0x200);

IOReturn result = mReadBuffer->prepare(kIODirectionIn);

IOReturn result = me->mReadBuffer->complete(kIODirectionIn);

Next in BrcmPatchRAM::bulkWrite we need to add kIODirectionOut options.

if (IOMemoryDescriptor* buffer = IOMemoryDescriptor::withAddress((void*)data, length, kIODirectionOut))

if ((result = buffer->prepare(kIODirectionOut)) == kIOReturnSuccess)

if ((result = buffer->complete(kIODirectionOut)) != kIOReturnSuccess)

Now that we don't have IOCatalogue::addDriversIOCatalogue::removeDrivers and IOCatalogue::startMatching methods to switch from using the uploader driver to native macOS driver we have to use BrcmBluetoothInjector.kext instead.

So my Bluetooth device is a BCM20702A0 with VendorID 0x0A5C and ProductID 0x216F (Dell DW1560 4352+20702 M.2) located in internal USB port HS14. So I'll use it as an example for the following modifications.

In BrcmPatchRAM2-Info.plist we need the following entry. Note the addition of the IOProbeScore. When the kext is loaded it will call BrcmPatchRAM::probe which will update the firmware and return NULL and then the BrcmBluetoothInjector.kext should load instead.

        <key>0a5c_216f</key>
        <dict>
            <key>CFBundleIdentifier</key>
            <string>com.no-one.$(PRODUCT_NAME:rfc1034identifier)</string>
            <key>DisplayName</key>
            <string>DW1560 Bluetooth 4.0 LE</string>
            <key>FirmwareKey</key>
            <string>BCM20702A1_001.002.014.1443.1572_v5668</string>
            <key>IOClass</key>
            <string>BrcmPatchRAM2</string>
            <key>IOMatchCategory</key>
            <string>BrcmPatchRAM2</string>
            <key>IOProviderClass</key>
            <string>IOUSBHostDevice</string>
            <key>IOProbeScore</key>
            <integer>4000</integer>
            <key>idProduct</key>
            <integer>8559</integer>
            <key>idVendor</key>
            <integer>2652</integer>
        </dict>

In BrcmBluetoothInjector-Info.plist we need the following entry. Note again the addition of the IOProbeScore. We want the BrcmBluetoothInjector.kext to load the macOS kext after the firmware has been uploaded to the hardware. Since BrcmBluetoothInjector.kext has not been updated in a long time you may need to add your hardware manually to the plist. Note that your Bluetooth device VendorID / ProductID is not the same as your WiFi hardware and will not show up in your PCI list. You will need to look at the USB ports to get this info.

        <key>0a5c_216f</key>
        <dict>
            <key>CFBundleIdentifier</key>
            <string>com.apple.iokit.BroadcomBluetoothHostControllerUSBTransport</string>
            <key>IOClass</key>
            <string>BroadcomBluetoothHostControllerUSBTransport</string>
            <key>IOProviderClass</key>
            <string>IOUSBHostDevice</string>
            <key>IOProbeScore</key>
            <integer>3000</integer>
            <key>idProduct</key>
            <integer>8559</integer>
            <key>idVendor</key>
            <integer>2652</integer>
        </dict>

You will know the firmware is uploaded when its version in About This Mac->System Report...->Bluetooth shows something like:

 Firmware Version:    v14 c5668

If it shows 4096 then the upload has failed.

I will attach my compiled versions for people to help test. I'm not 100% sure if this is method is going to work so I'd appreciate feedback on it.

Downloads (acidanthera)