broadcom-bt-firmware: the missing .hcd files for Broadcom Bluetooth on Linux

A packaging gap created by a vendor changing its distribution channel

The repository is for various Broadcom Bluetooth firmware, and the overview explains the situation precisely. The package is intended to provide firmware of Broadcom WIDCOMM Bluetooth devices, including the BCM20702, BCM20703 and BCM43142 chipsets and others, for the Linux kernel, and the reason it exists is a change on Broadcom's side: since February 2017 Broadcom ships their drivers directly to the Windows Update service, with a link to the Microsoft Update catalogue where the files can be downloaded. So the firmware exists, and is downloadable, but the Linux vendor that stopped packaging it is Broadcom itself. The `brcm/` directory in the repository is where the files live, `source/` holds the sources they were extracted from, `tools/` holds the extraction tooling, and `generate_files.sh` is the script that drives it, which is why the repository's primary language is listed as Perl.

The security section is the most important paragraph in the README

The README spends a paragraph on security considerations, and it is unusually blunt. It notes that several vulnerabilities have been discovered in the Bluetooth stack, naming CVE-2018-5383, CVE-2019-9506, which is KNOB, CVE-2020-10135, which is BIAS, and more. It then says that since Broadcom has stopped active support for its consumer devices, your system may be subject to security risks, and that you will have to use these devices at your own risk, and that as a repository maintainer the author cannot provide security fixes. That is the honest position for a project whose whole content is vendor binary blobs, and it deserves to be read before installation rather than after. The mitigation is available but not automatic, which is why the packages exist at all: on a platform where the driver cannot find its firmware, the Bluetooth stack does not work, and a device that does not enumerate is not a device you can patch.

Getting the packages, and the per distribution advice

The installation section is short. The first step is to check whether your Linux distribution already ships the firmware, with a link to the Repology project page for the package across distributions, and a packaging status badge at the top of the README. If it does not, there are autogenerated DEB and RPM packages for RedHat and Debian based distributions, published on the repository's releases page, which is the route most people should take, since the packages install the files into the right place for the kernel to find. The manual route exists for the cases the packages do not cover, and the next section explains it. The repository also carries a `DEVICES.md` file listed as the source of truth for supported devices, and a `CMakeLists.txt`, which is there so the extraction tooling and the packaging share one build definition.

Diagnosing which firmware file the kernel wants

The detection section answers the question most people actually have, which is why the dongle stopped working. When you insert a Broadcom Bluetooth device, your distribution may not load it properly, and the way to find out is to look at the kernel messages, and the README gives two commands for that.

dmesg | grep -i bluetooth
dmesg | grep -i bluetooth | grep -i firmware

The sample output shows the pattern to look for. The lines identify the chipset, for example `Bluetooth: hci1: BCM20702A1 (001.002.014) build 0000`, and then the failure, a direct firmware load for `brcm/BCM20702A1-0b05-17cb.hcd` that failed with error -2, followed by a line saying the patch `brcm/BCM20702A1-0b05-17cb.hcd` was not found. The filename in that message is the answer, because the kernel has told you the exact file it wants and where it expects it to live.

Dropping the file in and rebooting

The fix is a file copy, and the README keeps it short because there is not much to it. You place the required `.hcd` file into `/lib/firmware/brcm` and reboot your computer, and after the reboot the kernel messages change to show the firmware loaded successfully, with the build number in the `build 1467` field rather than `build 0000` and a final line identifying the device as a Broadcom Bluetooth Device. The README then points you to Bluez for further configuration, which is the right hand-off, since the firmware gets the controller enumerated and the Bluetooth stack takes it from there. The reason a reboot is required rather than a module reload is that the firmware is loaded when the driver probes the device, so the copy has to be in place before that probe happens.

The naming quirk, and the WiFi chips that need two firmwares

Two practical complications are documented, and both cost people an afternoon if they hit them cold. The first is that the name the kernel asks for may not be the name the file has, for example the system may request `BCM4354A2-13d3-3485.hcd` while the actual file is `BCM4356A2-13d3-3485.hcd`, which happens because of incorrect naming in the Linux kernel. The fix is to rename the file to the name the kernel wants, and the README gives a small table with the original name, the name requested by Linux and a note that this was fixed in Linux kernel 5.8. The second is combined WiFi and Bluetooth controllers, such as the BCM4354 and BCM4356, which are integrated into a WiFi chipset and require two kinds of firmware, one for WiFi and one for Bluetooth. Without the WiFi firmware the Bluetooth side will not initialise and will not work properly, and while the WiFi firmware is already included in the kernel you may need extra work to place the correct NVRAM, with a link to the kernel wireless wiki page for the brcm80211 driver, and the example output in the README shows both loading, with a brcmfmac line that names a customised `brcmfmac4356-pcie.txt`.

Two licences, one for the blobs and one for the tooling

The licence section splits the repository in two, and the split follows the nature of the content. The firmware files are licensed under the Broadcom WIDCOMM Bluetooth Software License Agreement, which is in the repository as `LICENSE.broadcom_bcm20702`, and the other parts of the project are licensed under the standard MIT licence, in `LICENSE.MIT.txt`. That is the only arrangement that makes sense for redistributed vendor binaries, and it is also the arrangement that tells you where to look if you are auditing what you are about to install, since the MIT terms say nothing about the blobs and the Broadcom terms say nothing about the scripts. The maintenance picture is a long gap followed by a recent bump, with release tags v12.0.1.1105_p3 in August 2020, p4 in October 2022 and p5 in July 2026, and the last push on the same day as that newest tag, so the packaging is current even though the underlying vendor support is not.

Editorial conclusion

Adopt this repository if you have a Broadcom WIDCOMM Bluetooth chipset, such as a BCM20702, BCM20703 or BCM43142, and Linux cannot find its firmware, because the alternative is a dongle that does not enumerate. Do not adopt it on a machine where you need the Bluetooth stack to be trustworthy, because the README says in plain terms that Broadcom has stopped active support for its consumer devices, that your system may be subject to security risks, that you must use these devices at your own risk, and that the maintainer cannot provide security fixes. Before you install, check the security section and read the list of affected advisories, including the KNOB and BIAS issues named in the README, and treat the firmware as a compatibility fix rather than a maintained component. The firmware files themselves are under the Broadcom WIDCOMM Bluetooth Software License Agreement and the rest of the project is MIT, the newest release tag is v12.0.1.1105_p5 from 2026-07-29, and the last push was the same day.

Frequently asked questions

Official sources

1. Issues
2. README
3. Releases
4. winterheart/broadcom-bt-firmware on GitHub