BT firmware compatibility issues with DW1820A (CN-08PKF4) WiFi + BT card #715

JeffreyVIP · 2020-02-13T15:00:21Z

WiFi + BT card : DW1820A with P/N CN-08PKF4
macOS version: 10.15.3
EFI: OpenCore based, installed from HaC-Mini release version 2.5
brcm kexts is referenced in HaC-Mini project.
Sometimes BT devices can't be connected, although BT devices can be discovered.
Most times below command followed with a system shutdown and power on will fix the issue.
sudo kextcache -i /

log show --last boot | grep -y brcmpatchram
working case:

2020-01-29 21:16:15.850285+0800 0x1be      Default     0x0                  0      0    kernel: (BrcmFirmwareData) BrcmPatchRAM: Loaded compressed embedded firmware for key "BCM4350C5_003.006.007.0222.4689_v8785".
2020-01-29 21:16:15.850573+0800 0x1be      Default     0x0                  0      0    kernel: (BrcmFirmwareData) BrcmPatchRAM: Decompressed firmware (12582 bytes --> 31740 bytes).
2020-01-29 21:16:15.850806+0800 0x1be      Default     0x0                  0      0    kernel: (BrcmFirmwareData) BrcmPatchRAM: Firmware is valid IntelHex firmware.
2020-01-29 21:16:15.952112+0800 0x1be      Default     0x0                  0      0    kernel: (BrcmPatchRAM3) BrcmPatchRAM: [0a5c:6412]: USB [3052CB851AC2 v274] "BCM2045A0" by "Broadcom Corp"
2020-01-29 21:16:15.956899+0800 0x1be      Default     0x0                  0      0    kernel: (BrcmPatchRAM3) BrcmPatchRAM: [0a5c:6412]: Firmware upgrade not needed.
2020-01-29 21:16:15.956921+0800 0x1be      Default     0x0                  0      0    kernel: (BrcmPatchRAM3) BrcmPatchRAM: Processing time 0.105 seconds.

not working case:

2020-01-29 23:06:15.176768+0800 0x1bd      Default     0x0                  0      0    kernel: (BrcmFirmwareData) BrcmPatchRAM: Loaded compressed embedded firmware for key "BCM4350C5_003.006.007.0222.4689_v8785".
2020-01-29 23:06:15.176941+0800 0x1bd      Default     0x0                  0      0    kernel: (BrcmFirmwareData) BrcmPatchRAM: Decompressed firmware (12582 bytes --> 31740 bytes).
2020-01-29 23:06:15.177118+0800 0x1bd      Default     0x0                  0      0    kernel: (BrcmFirmwareData) BrcmPatchRAM: Firmware is valid IntelHex firmware.
2020-01-29 23:06:15.277478+0800 0x1bd      Default     0x0                  0      0    kernel: (BrcmPatchRAM3) BrcmPatchRAM: [0a5c:6412]: USB [3052CB851AC2 v274] "BCM2045A0" by "Broadcom Corp"
2020-01-29 23:06:15.653321+0800 0x1bd      Default     0x0                  0      0    kernel: (BrcmPatchRAM3) BrcmPatchRAM: [0a5c:6412]: Firmware upgrade completed successfully.
2020-01-29 23:06:15.653367+0800 0x1bd      Default     0x0                  0      0    kernel: (BrcmPatchRAM3) BrcmPatchRAM: Processing time 0.476 seconds.

It seems bypass 'firmware upgrade' can fix the issue, If yes, please provide a option to bypass the upgrade so that the DW1820A BT card can also work.

similar issue is reported here:
osy/HaC-Mini#125

Thank you very much!
Really Appreciated!

The text was updated successfully, but these errors were encountered:

FuckDoctors · 2020-03-03T01:48:37Z

Same here.
DW1820A(1028:0023) Labeled as "CN-0VW3T3"

hftsai256 · 2020-03-24T17:55:55Z

A warm reset will preserve the firmware that has already been loaded onto the board. I was double checking this and figured out that bypassing firmware upload itself cannot not resolve this issue, and, more over, uploading firmware is essential to get this card up and running. The only way I've found so far to get around this is to load firmware version v12.0.1.940 shown as v7 c5799 -- It can be downloaded from this repo and I managed to upload this from Ubuntu. For example, mine is 0a5c:6412 so that the correct firmware is this one.

One thing I cannot understand is that the firmware shipped with BrcmPatchRAM3.kext (v12.0.1.1105) seems to be newer than the one works for me (v12.0.1.940), but its version number looks older.

Is there any chance to include this firmware of DW1820A in the next update of BrcmPatchRAM3.kext?

Thanks.

vit9696 · 2020-03-24T20:31:49Z

Fixed in master.

hftsai256 · 2020-03-24T22:50:26Z

I pulled in the latest commit 38268f7 from BrcmPatchRAM repo and can see it fails to load the firmware (full log attached at the very bottom):

kernel: (BrcmPatchRAM3) BrcmPatchRAM: [0a5c:6412]: State "Initialize" --> "Firmware version".
kernel: (BrcmFirmwareData) BrcmPatchRAM: getFirmware
kernel: (BrcmFirmwareData) BrcmPatchRAM: loadFirmware
kernel: (BrcmFirmwareData) BrcmPatchRAM: OSKextRequestResource: 00000000
kernel: (BrcmFirmwareData) BrcmPatchRAM: OSKextRequestResource Callback: dc008006.
kernel: (BrcmFirmwareData) BrcmPatchRAM: OSKextRequestResource: 00000000
kernel: (BrcmFirmwareData) BrcmPatchRAM: OSKextRequestResource Callback: dc008006.
kernel: (BrcmFirmwareData) BrcmPatchRAM: OSKextRequestResource: 00000000
kernel: (BrcmFirmwareData) BrcmPatchRAM: OSKextRequestResource Callback: dc008006.
kernel: (BrcmFirmwareData) BrcmPatchRAM: OSKextRequestResource: 00000000
kernel: (BrcmFirmwareData) BrcmPatchRAM: OSKextRequestResource Callback: dc008006.
kernel: (BrcmFirmwareData) BrcmPatchRAM: Unable to locate BrcmFirmwareStore configured firmwares.
kernel: (BrcmPatchRAM3) BrcmPatchRAM: [0a5c:6412]: State "Firmware version" --> "Update aborted".
kernel: (BrcmPatchRAM3) BrcmPatchRAM: [0a5c:6412]: Firmware upgrade failed.
kernel: (BrcmPatchRAM3) BrcmPatchRAM: Processing time 0.370 seconds.

My EFI is generated by OC-tool with the attached plist zip archive.

BrcmPatchRAM_0a5c_6412.log
config.plist.zip

vit9696 · 2020-03-25T08:44:00Z

Sorry, forgot to update IOKitPersonalities. Should be fixed now (upload the log if not).

havvk · 2020-03-25T10:20:49Z

It is still not working here after pulled latest commit 70bda57.
It can discover devices, but can't connect to them.

kernel[0]: (BrcmPatchRAM3) BrcmPatchRAM: Version 2.5.2 starting on OS X Darwin 19.3.
kernel[0]: (BrcmPatchRAM3) BrcmPatchRAM: [0a5c:6412]: USB [5800E34033E6 v274] "BCM2045A0" by "Broadcom Corp"
kernel[0]: (BrcmPatchRAM3) BrcmPatchRAM: [0a5c:6412]: Firmware upgrade completed successfully.
kernel[0]: (BrcmPatchRAM3) BrcmPatchRAM: Processing time 0.379 seconds.

生产企业： Broadcom
传输： USB
芯片组： Unknown (6e)
固件版本： v7 c5799
蓝牙电源：打开
可被发现：打开
可连接：是
自动寻找点：打开
远程唤醒：打开
供应商ID： 0x0A5C
产品ID： 0x6412
蓝牙核心规范： 4.1 (0x7)
HCI修正版： 0x16A7
LMP版本： 4.1 (0x7)
LMP子版本： 0x6607
设备类型（主要）： Computer
设备类型（完整）： Mac Portable
复合类设备： 0x38010C
设备类（主要）： 0x01
设备类（次要）： 0x03
服务类： 0x1C0
自动寻找键盘：打开

vit9696 · 2020-03-25T11:15:31Z

Well, it is all we can do from our side. The request was to update the firmware, which we did. If you have a newer firmware that works for you, we can imagine including it. Bugs with the firmware should be filed at Broadcom, we only have the binary blobs.

hftsai256 · 2020-03-25T15:08:40Z

Thanks @vit9696. I can confirm the firmware can be loaded with commit 70bda57 however I've found a more serious issue:

What would work:
Cold boot (v4096) -> Upload firmware in Ubuntu (v5799, can connect to device) -> Warm reset to MacOS (v5799, can connect to devices)

What would not work:
Cold boot (v4096) -> Upload firmware in MacOS (v5799, cannot connect, reason 0x16) -> Warm reset to Ubuntu (v5799, cannot connect) -> Warm reset to MacOS (v5799, cannot connect)

Again I think this quick check rules out the fact that whether uploading firmware or not will not impact bluetooth connectivity. On the other hand, I'm suspecting the firmware loaded by BrcmPatchRAM3 is somehow corrupted. I was verifying this by starting from the firmware binary blob downloaded from Microsoft Update Catalog (v12.0.0.1012, released on 03/29/2017), compressed with zlib (via Python3, best compression - 9), and then I get a bite-wise identical zhx file.

Should this discover be detailed in a separate ticket?

[PS] I blew up my memory sticks and they will be on their way for RMA. May not be able to test it in the next couple of weeks.

vit9696 · 2020-03-25T15:26:46Z

It is unlikely that BrcmPatchRAM3 uploads the wrong firmware (I checked that part, and it looks sane to me), but it is quite possible, that Linux does extra things. Unfortunately I am too unfamiliar with the process to debug this (I do not even have any non-Apple BT hardware) and I also do not have spare resources to look at it. I reopened the issue in the hopes somebody else could give it a try.

CC @headkaze @Mieze

benbaker76 · 2020-03-25T15:31:47Z

The request was to update the firmware, which we did.

I updated the firmware to 12.0.1.1105 and your commit says you updated to 12.0.1.1012. Are you sure it's a newer version?

Either way your latest commit works fine for me so it sounds like these users have a configuration issue. Several common causes are not placing the kexts in the appropriate location and not having USB configured correctly.

vit9696 · 2020-03-25T15:46:28Z

@headkaze I reverted to 12.0.1.1012 as it is the latest version available on technet, it is the one used on Linux, and it was reported to work fine. Now that it actually did not help, I am not sure what is the correct route for this, it seems that the only place that has the new firmware is Dell support website:
https://www.dell.com/support/home/us/en/04/drivers/driversdetails?driverid=99v46

Interestingly, it says the following in the changelog:

Regular Update For Major Release.
Fixed the issue where Bluetooth version 5.0, 4.0, and 4.2 are unable to connect with peripheral devices.

You are right that the version linked from Dell (12.0.1.1105) is indeed newer at the very least:

[Version]
Signature="$WINDOWS NT$"
Class=Bluetooth
ClassGuid={e0cbf06c-cd8b-4647-bb8a-263b43f0f974}
Provider=%BRCM%
DriverVer=03/29/2017,12.0.1.1012
CatalogFile=bcbtums-x64.cat

[Version]
Signature="$WINDOWS NT$"
Class=Bluetooth
ClassGuid={e0cbf06c-cd8b-4647-bb8a-263b43f0f974}
Provider=%BRCM%
DriverVer = 10/26/2018,12.0.1.1105
CatalogFile = bcbtums-x64.cat

vit9696 · 2020-03-25T15:54:03Z

There actually is another firmware version, 12.0.1.1104 (BCM4350C5_003.006.007.0222.4688):
https://github.com/ameeno/DELL-DW1820A-Drivers/tree/master/Windows%2010/dw1820a%20Bluetooth%20-%20Win10. Perhaps it is worth trying too.

vit9696 · 2020-03-25T15:58:14Z

CC @ameeno, perhaps you can shed some light on all these versions and perhaps the issue itself.

hftsai256 · 2020-03-25T15:58:24Z

@headkaze TBH I have the same question as well. So far the only working firmware on my machine is the one from Winterheart's Github Repo, and by looking into its commit history it might belong to release 12.0.1.940. (Yet it is showing c5799 in MacOS.)

Does it means that the smaller version number shown on MacOS's bluetooth info page is actually newer (i.e. v7 c4689 is newer than v7 c5799)? I can't figure out how to create hcp files required by Linux kernel so I don't know how to confirm if 12.0.1.1105 (v7 c4689) works under Ubuntu.

BTW my USB configurations are generated with USBMap, with the port for 1820A configured as internal (255). SSDT-CPUX.aml, SSDT-UIAC.aml, SSDT-USBX.aml are all in place with XhciPortLimit enabled.

benbaker76 · 2020-03-25T16:12:45Z

I'm no expert in this driver. I only made changes to make it work in Catalina and updated the firmware.

There are instructions in the readme for adding your own custom firmware but I've never tried it.

The main work on this driver is by @the-darkvoid and @RehabMan but I'm not sure if they're available to help anymore.

@vit9696 it might be worth updating the firmware to 12.0.1.1104 as that changelog describes a common issue

ameeno · 2020-03-25T18:56:39Z

Hi, thanks for reaching out.

If I recall correctly, The changes had something to do with a Modification of the BrcmPatchRAM2.kext/Contents/Info.plist to add the correct device ID string for the BT in the DW1820a, As well as ensuring that firmware referenced also exists inside: BrcmFirmwareRepo.kext/Contents/Resources/ with the appropriate filename and syntax.

I believe Diff'ing the files will reveal all?

Its been a really long time since I made the changes & got it working.

On a side note, it has come to light that there are several variants of this card, some of which work some of which don't.

hope that is useful.

ameeno · 2020-03-25T18:58:19Z

Oh, as this relates to Windows: similar thing really, the standard drivers don't contain the correct firmware for the device ID. for the bt portion. getting the right firmware to load is the key.

vit9696 · 2020-03-25T19:15:18Z

Mhm. I changed the DW1820A firmware to 8784 (12.0.1.1104) version, the one present in @ameeno repository. While it is older than the latest 8785 (12.0.1.1105) from Dell it was tested working by several people at the very least.

I also added a simple tool, firmware_update.tool, to quickly rebuild the firmware tree of BrcmPatchRAM with the supplied firmware update directory. Just unpack Windows drivers and pass that directory to the tool, it will handle the rest on its own. This should let you test all the available firmware versions on the internet and see what works for you and what does not.

My current suspect is that your card may indeed be "problematic", and it is possible that it may not work at all despite the efforts, however.

havvk · 2020-03-26T03:43:41Z

I turned on the computer just now, then I found that bluetooth was working.
Although it couldn't connect to other devices after I updated to commit 70bda57 and rebooted yesterday.(detail @ #715 (comment))
And it's weird that I can't see content about BrcmPatchRAM in the kernel log.
BTW:I'm still using the version of commit 70bda57.

havvk · 2020-03-26T04:28:09Z

I updated to the last commit 7f607ac (firmware 8784),the same thing happened.
After update, rebooted the computer -- could't connect to other device
shut down the computer, then turned on the computer -- It works
then rebooted the computer -- It works
then shut down, unplugged and plugged power cord, turned on the computer -- could't connect to other device
shut down the computer, then turned on the computer -- It works

Then I used firmware_update.tool to update firmware to 8765.
The test result is same as 5799 or 8764.
After update and reboot, it will not work at once.
Shutting down then turning on should resolve it.

I tested with windows running in VMware, and found the following result.
Unplugged and plugged power cord, turned on the computer, It should not work at this moment.
Then I connect bluetooth module to windows in VMware.

After windows recognized it, I disconnect bluetooth module from windows in VMware.
Then the bluetooth got working in MacOS immediately.

goodbest · 2020-03-26T14:47:26Z

I updated to the last commit 7f607ac (firmware 8784),the same thing happened.
After update, rebooted the computer -- could't connect to other device
shut down the computer, then turned on the computer -- It works
then rebooted the computer -- It works
then shut down, unplugged and plugged power cord, turned on the computer -- could't connect to other device
shut down the computer, then turned on the computer -- It works

Then I used firmware_update.tool to update firmware to 8765.
The test result is same as 5799 or 8764.
After update and reboot, it will not work at once.
Shutting down then turning on should resolve it.

I tested with windows running in VMware, and found the following result.
Unplugged and plugged power cord, turned on the computer, It should not work at this moment.
Then I connect bluetooth module to windows in VMware.

After windows recognized it, I disconnect bluetooth module from windows in VMware.
Then the bluetooth got working in MacOS immediately.

I had the same observations too:

unplug, plug, boot and reboot do the trick to make it work
Using DW1820A (BCM94350ZAE) for Hac-Mini osy/HaC-Mini#113 (comment)
rebooting from windows will make it work
DW1820A Bluetooth does not work properly in some circumstances osy/HaC-Mini#125 (comment)

By the way:
Please do not forget the 0a5c_6414 devices, which may have the same chips for DW1820A. (Part No. 00JT494/00JT493)
They are on the same boat

hftsai256 · 2020-03-26T15:07:37Z

@havvk Sorry I'm confused about the description:

Then I used firmware_update.tool to update firmware to 8765.
The test result is same as 5799 or 8764.
After update and reboot, it will not work at once.
Shutting down then turning on should resolve it.

Does it mean that you were uploading v8784 via BrcmPatchRAM3 and it didn't work straight out from boot, but will work after you warm reset your machine? That is to say, the firmware is loaded properly through BrcmPatchRAM3, but it requires a warm reset. Neither Windows nor Linux is involved in this process.

I'd also assume you have 0a5c_6414 card. AFAIK 6412, 6413 and 6414 are in the same ballpark but react slightly different from one to another. E.g. firmware must be loaded through Windows/Linux on my 6412 (0VW3T3) as warm reset cannot rescue its functionality. I'm ordering two more DW1820A with different flavors (seller claims they are 096JNT but we'll see). Also I'm also considering my card is somewhat broken as @vit9696 suggested.

Does Windows leaves driver logs so that we could check which firmware does Windows actually load? I'm not 100% certain but based on the version number maybe the original BrcmPatchRAM/extra_firmwares/0a5c_6412/BCM4350C5_003.006.007.0222.4689_v8785.zhx is correct. And therefore it makes me wonder if there's something wrong during the uploading process -- i.e. getting the correct offset on both ends, uploading firmware when it's not ready yet, etc.

vit9696 · 2020-03-26T18:55:21Z

Maybe your particular card does not support handshake, and thus is not reset properly? Try removing the entry from this list: https://github.com/acidanthera/BrcmPatchRAM/blob/2d94e78/BrcmPatchRAM/BrcmPatchRAM3.cpp#L54

You can then play with the delays via boot-args:
https://github.com/acidanthera/BrcmPatchRAM/blob/d091c37e3f4caa83465659e56ebabe9d10738062/README.md#configuration

vit9696 · 2020-03-26T20:23:12Z

Actually reworked configuration arguments in the latest commit to make more sense. Handshake support can now be configured independently via bpr_handshake boot argument. Refer to README for updated details.

havvk · 2020-03-27T04:06:38Z

Than you for your continued support.
I updated to the latest commit, and set bpr_handshake=0 bpr_preresetdelay=3000 in boot-args. It still isn't working, and there are something in kernel log I had never see before.

vit9696 · 2020-03-27T04:12:32Z

3000 might be a bit too much, I am not sure whether the driver will not be unhappy of this. However, if trying lower values e.g. 100, 200, 300, 400 does not work, I guess you are indeed out of luck at least for now. The logs are fine, although it is a bit suspicious that the device constantly power-cycles.

havvk · 2020-03-27T04:41:19Z

@hftsai256 yes.the firmware is loaded properly through BrcmPatchRAM3, but it requires a warm reset. Neither Windows nor Linux is involved in this process.

I have 2 0a5c_6412 cards, which type is DW1820A(8PKF4).

havvk · 2020-03-27T04:46:28Z

3000 might be a bit too much, I am not sure whether the driver will not be unhappy of this. However, if trying lower values e.g. 100, 200, 300, 400 does not work, I guess you are indeed out of luck at least for now. The logs are fine, although it is a bit suspicious that the device constantly power-cycles.

I have tried values 100,200,300,400, it still doesn't work.
After I rebooted, It got working.
And the kernel log shows only 2 lines about setPowerState now.

vit9696 · 2020-03-27T05:19:51Z

Hmmmm. Hard to say, it might be the case that we need some kind of extra device reset. Somebody probably needs to check Linux source code and maybe backport stuff if necessary. I will keep the issue open for now.

mishurov · 2020-03-29T02:41:37Z

The same story here. CN-0VW3T3. I've never noticed it because I mainly work on Linux and occasionally reboot to MacOS. But after pci-aspm-default setting, I removed physical pin masking from the card and it requires poweroff instead of reboot, something related to aspm on Linux, I guess.

The Bluetooth driver always after shutting down ignores previously saved LinkKeys and requires to pair devices again. Current master.

goodbest · 2020-04-01T06:18:15Z

Hmmmm. Hard to say, it might be the case that we need some kind of extra device reset. Somebody probably needs to check Linux source code and maybe backport stuff if necessary. I will keep the issue open for now.

This may not be relevant, but I want to provide some possible clue:

To use DW1820A or it's variants (0a5c_6412, 0a5c_6414,etc), you have to set pci-aspm-default=0 or disable aspm in BIOS. (Don't have to do this for DW1560 etc)

Does this have anything to do with the extra device reset or fw upload issue?

See als
#794

Sniki · 2020-04-12T09:33:56Z

@vit9696 i have some information, for some reasons emulating windows with _OSI, fixes the problem and you can connect to bluetooth devices.
I know Emulating windows with _OSI is not recommended and i don't do it but it will maybe help us trace the route of the problem.
Rename _OSI with XOSI and add the SSDT-XOSI

Reboot and devices will connect properly, i had a lot of people on tmx86 that reported this problem and this dirty solution worked for all of them, will look if i can find that post and link it here, good thing there was an issue for this here so i can report it.

Maybe someone with this can trace where the problem is.

Thanks !

vit9696 · 2020-04-12T20:02:20Z

Well, you should not have much difficulty tracing this in the ACPI table.

RV-ABZ · 2020-04-18T03:22:36Z

I've posted some observations and potential leads regarding issue of loading Bluetooth firmware on DW1820a cards upon cold boots.
https://www.insanelymac.com/forum/topic/339175-brcmpatchram2-for-1015-catalina-broadcom-bluetooth-firmware-upload/?do=findComment&comment=2717888

1st of all, FW version provided for DW1820a 0a5c:6412 is not v8784 but v4688 or v4689; this mistake was probably the result of some erroneous assumption that FW version = 4096 + version stated in file name. It's not always the case and this only applies to some versions.

Then -and I don't know if this can be classified as a bug- I found that using a shorter name for FW file allowed my Hackintosh laptop to load my own firmware to the card when the kexts's default provided firmware failed in that respect until its name was too shorten. I changed it from BCM4350C5_003.006.007.0221.4688_v8784.zhx to BCM4350C5_v8784.zhx and then Bluetooth started working properly with it.

This may explain why many users reported failures at using those new versions of BrcmBluetoothInjector + BrcmFirmwareRepo + BrcmPatchRAM3 unless they were doing warm reboots from Windows. I used and tested only the kexts for caching (i.e. with Repo), not for injecting (i.e. with Data).

I was able to load extracted and uncompressed firmware version v5974 to my BT module and Bluetooth now works repeatedly on cold reboots, not just upon warm reboots from Windows.

vit9696 · 2020-04-18T05:28:30Z

@RV-ABZ Thanks for your research. I pushed two changes in BrcmPatchRAM:

I fixed version parsing to account for optional 4096, so that running firmware_update.tool will properly choose the latest available version.
I added SHA-1 hash printing of the uncompressed firmware to be loaded. I believe this should let you debug compression issues.

I have not changed anything regarding file names, but even if long files do not work, I am afraid the issue is with macOS, not BrcmPatchRAM. Our limits for file path are PATH_MAX, which is 1024 bytes. I would suggest you focusing on BrcmFirmwareData, as BrcmFirmwareRepo is deprecated and is not supported anymore.

There is a chance something is wrong with the decompression (although we use macOS-provided zlib once again), please try checking that as I believe it can be the key to the problem.

mishurov · 2020-04-18T08:39:36Z

I also think that it is a userspace issue. BT devices don't want to authenticate the adapter under macOS. Once authenticated and if a BT device haven't been powered off, it will connect even during cold reboots.

As I understand macOS on Macs saves into nvram two variables bluetoothActiveControllerInfo and bluetoothInternalControllerInfo. But I've checked and there's no bluetoothInternalControllerInfo, may be data from this variable is somehow being used for BT authentication. I don't know what should be written there perhaps it's just a BD_ADDR.

UPD. bluetoothInternalControllerInfo seems to have nothing to do with this issue. It's just the same as bluetoothActiveControllerInfo

I've made an experiment.

Scenario 1.

Cold boot to macOS
Pair a device
Shut down and boot again to macOS
Can't connect

Scenario 2.

Boot to Linux, reboot to macOS
Pair the device
Shut down
Boot to Linux, reboot to macOS
Can connect.
And furthermore, I always can connect on macOS after Linux, regardless

I.e. it works properly if driver is in state kUpdateNotNeeded. On Linux I use the very same firmware which I convert from the Windows binaries with hex2hcd, namely BCM4350C5_003.006.007.0222.4689.hex. It doesn't matter. Something wrong with the firmware upgrade process.

UPD 2. I'm not sure but I think that BrcmFirmwareStore.cpp parses too much, converts it into instructions, etc. For example the Linux driver uses almost raw data
https://github.com/torvalds/linux/blob/master/drivers/bluetooth/btbcm.c#L179

Also here seemingly a port from Linux for Intel BT, there's also no any parsing
https://github.com/zxystd/IntelBluetoothFirmware/blob/master/IntelBluetoothFirmware/IntelBluetoothFirmware.cpp#L393

vit9696 · 2020-04-20T05:24:59Z

@mishurov thanks for the research and patch fix. As for parsing I would agree it is unnecessarily overcomplicated, but this is the legacy we got unfortunately.

Could more people test the suggested fix in acidanthera/BrcmPatchRAM#4?

junaedahmed · 2020-04-21T01:28:55Z

Just tested with @mishurov fix. I confirm it works great on my 0a5c_6412 device.

vit9696 · 2020-04-21T06:19:32Z

Good, closing as resolved.

Andrey1970AppleLife added the project:brcm label Feb 14, 2020

vit9696 closed this as completed Mar 24, 2020

vit9696 added the help wanted Extra attention is needed label Mar 25, 2020

vit9696 reopened this Mar 25, 2020

vit9696 changed the title ~~brcm kexts -- bluetooth sometimes not working for DW1820A (CN-08PKF4) WiFi + BT card~~ BT firmware compatibility issues with DW1820A (CN-08PKF4) WiFi + BT card Mar 25, 2020

hftsai256 mentioned this issue Mar 26, 2020

Suggestion: Kexts in Extras Takes Higher Priority rusty-bits/OC-tool#23

Closed

mishurov mentioned this issue Apr 1, 2020

M.2 BCM4350 ASPM #794

Closed

vit9696 closed this as completed Apr 21, 2020

BT firmware compatibility issues with DW1820A (CN-08PKF4) WiFi + BT card #715

BT firmware compatibility issues with DW1820A (CN-08PKF4) WiFi + BT card #715

Comments

JeffreyVIP commented Feb 13, 2020 • edited Loading

FuckDoctors commented Mar 3, 2020

hftsai256 commented Mar 24, 2020 • edited Loading

vit9696 commented Mar 24, 2020

hftsai256 commented Mar 24, 2020 • edited Loading

vit9696 commented Mar 25, 2020

havvk commented Mar 25, 2020 • edited Loading

vit9696 commented Mar 25, 2020

hftsai256 commented Mar 25, 2020 • edited Loading

vit9696 commented Mar 25, 2020

benbaker76 commented Mar 25, 2020

vit9696 commented Mar 25, 2020 • edited Loading

vit9696 commented Mar 25, 2020

vit9696 commented Mar 25, 2020

hftsai256 commented Mar 25, 2020 • edited Loading

benbaker76 commented Mar 25, 2020

ameeno commented Mar 25, 2020

ameeno commented Mar 25, 2020

vit9696 commented Mar 25, 2020

havvk commented Mar 26, 2020

havvk commented Mar 26, 2020 • edited Loading

goodbest commented Mar 26, 2020 • edited Loading

hftsai256 commented Mar 26, 2020 • edited Loading

vit9696 commented Mar 26, 2020 • edited Loading

vit9696 commented Mar 26, 2020

havvk commented Mar 27, 2020

vit9696 commented Mar 27, 2020

havvk commented Mar 27, 2020

havvk commented Mar 27, 2020 • edited Loading

vit9696 commented Mar 27, 2020

mishurov commented Mar 29, 2020

goodbest commented Apr 1, 2020

Sniki commented Apr 12, 2020 • edited Loading

vit9696 commented Apr 12, 2020

RV-ABZ commented Apr 18, 2020 • edited Loading

vit9696 commented Apr 18, 2020

mishurov commented Apr 18, 2020 • edited Loading

vit9696 commented Apr 20, 2020

junaedahmed commented Apr 21, 2020

vit9696 commented Apr 21, 2020

JeffreyVIP commented Feb 13, 2020 •

edited

Loading

hftsai256 commented Mar 24, 2020 •

edited

Loading

hftsai256 commented Mar 24, 2020 •

edited

Loading

havvk commented Mar 25, 2020 •

edited

Loading

hftsai256 commented Mar 25, 2020 •

edited

Loading

vit9696 commented Mar 25, 2020 •

edited

Loading

hftsai256 commented Mar 25, 2020 •

edited

Loading

havvk commented Mar 26, 2020 •

edited

Loading

goodbest commented Mar 26, 2020 •

edited

Loading

hftsai256 commented Mar 26, 2020 •

edited

Loading

vit9696 commented Mar 26, 2020 •

edited

Loading

havvk commented Mar 27, 2020 •

edited

Loading

Sniki commented Apr 12, 2020 •

edited

Loading

RV-ABZ commented Apr 18, 2020 •

edited

Loading

mishurov commented Apr 18, 2020 •

edited

Loading