I use BCM4345C5 from here https://github.com/armbian/firmware/blob/master/brcm/BCM4345C5.hcd putting it into the /usr/lib/firmware/brcm and after full shutdown it works. Reboot is not sufficient. Sometimes it shows that it's on and cannot find any device, but so is the wifi on Pinebook Pro, so you know, full shutdown and hope it works on next boot.

--- Best regards, Alex

On Friday, August 9th, 2024 at 12:06, Andreas Reschke arm_ml@rirasoft.de wrote:

Hello,

first: don't know if Bluetooth has worked before. If updated today the laptop and noticed Bluetooth isn't working.

dmesg | grep -i bluetooth missed 'brcm/BCM4345C5.hcd

After searching Internet I've found https://copr.fedorainfracloud.org/coprs/jwillikers/pinebook-pro and installed ap6256-firmware-2020.02-10.fc39.aarch64.rpm

No failure on

root@pinebook-pro:/home/andreas# dmesg | grep -i bluetooth [ 54.157295] Bluetooth: Core ver 2.22 [ 54.168145] NET: Registered PF_BLUETOOTH protocol family [ 54.168154] Bluetooth: HCI device and connection manager initialized [ 54.168167] Bluetooth: HCI socket layer initialized [ 54.168173] Bluetooth: L2CAP socket layer initialized [ 54.168215] Bluetooth: SCO socket layer initialized [ 54.375968] Bluetooth: HCI UART driver ver 2.3 [ 54.381603] Bluetooth: HCI UART protocol H4 registered [ 54.387230] Bluetooth: HCI UART protocol BCSP registered [ 54.418449] Bluetooth: HCI UART protocol LL registered [ 54.420446] Bluetooth: HCI UART protocol ATH3K registered [ 54.438694] Bluetooth: HCI UART protocol Three-wire (H5) registered [ 54.438939] Bluetooth: HCI UART protocol Intel registered [ 54.450367] Bluetooth: HCI UART protocol Broadcom registered [ 54.450978] Bluetooth: HCI UART protocol QCA registered [ 54.466370] Bluetooth: HCI UART protocol AG6XX registered [ 54.481649] Bluetooth: HCI UART protocol Marvell registered [ 54.871946] Bluetooth: hci0: BCM: chip id 130 [ 54.878835] Bluetooth: hci0: BCM: features 0x0f [ 54.881103] Bluetooth: hci0: BCM4345C5 [ 54.881119] Bluetooth: hci0: BCM4345C5 (003.006.006) build 0000 [ 54.915175] Bluetooth: hci0: BCM4345C5 'brcm/BCM4345C5.hcd' Patch [ 55.863677] Bluetooth: hci0: BCM: features 0x0f [ 55.889055] Bluetooth: hci0: BCM4345C5 Ampak_CL1.5 UART 37.4 MHz BT 5.0 [Version: Version: 0033.0080] [ 55.889093] Bluetooth: hci0: BCM4345C5 (003.006.006) build 0080 [ 55.890379] Bluetooth: hci0: BCM: Using default device address (43:45:c5:00:1f:ac) [ 57.583111] Bluetooth: BNEP (Ethernet Emulation) ver 1.3 [ 57.587702] Bluetooth: BNEP filters: protocol multicast [ 57.592713] Bluetooth: BNEP socket layer initialized

root@pinebook-pro:~# rfkill | grep blue 1 bluetooth hci0 unblocked unblocked root@pinebook-pro:~#

Bluetooth doesn't find any controller.

Greetings

Andreas

Hi Andreas,

first: don't know if Bluetooth has worked before. If updated today the laptop and noticed Bluetooth isn't working.

Nope, the bliuetooth for the brcmfmac parts is complicated.

dmesg | grep -i bluetooth missed 'brcm/BCM4345C5.hcd

After searching Internet I've found https://copr.fedorainfracloud.org/coprs/jwillikers/pinebook-pro and installed ap6256-firmware-2020.02-10.fc39.aarch64.rpm

Well per the rules for copr that shouldn't be there, but that aside....

There's two different WiFi parts, both using brcmfmac, in the Pinebook Pro so it will depend on which one you have.

One of those parts is a Cypress part, now part of Infineon, and the WiFi for that part will work OOTB. The WiFi for the synaptics part won't work OOTB. That should tell you what variant of the HW you have. You then need to go and find the right version of the BT firmware for the one you have because neither of those firmware are upstream.

The most useful bit of debug is actually from the wifi module:

# dmesg | grep FWID [ 20.285673] brcmfmac: brcmf_c_preinit_dcmds: Firmware: BCM4356/2 wl0: Apr 9 2021 00:40:07 version 7.35.349.104 (775a9ab CY) FWID 01-64b609e0

The two letter right before the FWID tells you who makes the module. The above is from the Rock960 which has a Cypress part.

Basically Broadcom made the original HW, they then sold it to Cypress... but kept rights to it.... then Broadcom sold it to Synaptics.... but kept the rights to it. So there's 3 vendors making similar but not the same HW, in all cases the BT firmware can only be described as a mess!

Peter

Hi,

On 8/9/24 12:06 PM, Andreas Reschke wrote:

Hello,

first: don't know if Bluetooth has worked before. If updated today the laptop and noticed Bluetooth isn't working.

dmesg | grep -i bluetooth missed 'brcm/BCM4345C5.hcd

After searching Internet I've found https://copr.fedorainfracloud.org/coprs/jwillikers/pinebook-pro and installed ap6256-firmware-2020.02-10.fc39.aarch64.rpm

No failure on

root@pinebook-pro:/home/andreas# dmesg | grep -i bluetooth [   54.157295] Bluetooth: Core ver 2.22 [   54.168145] NET: Registered PF_BLUETOOTHprotocol family [   54.168154] Bluetooth: HCI device and connection manager initialized [   54.168167] Bluetooth: HCI socket layer initialized [   54.168173] Bluetooth: L2CAP socket layer initialized [   54.168215] Bluetooth: SCO socket layer initialized [   54.375968] Bluetooth: HCI UART driver ver 2.3 [   54.381603] Bluetooth: HCI UART protocol H4 registered [   54.387230] Bluetooth: HCI UART protocol BCSP registered [   54.418449] Bluetooth: HCI UART protocol LL registered [   54.420446] Bluetooth: HCI UART protocol ATH3K registered [   54.438694] Bluetooth: HCI UART protocol Three-wire (H5) registered [   54.438939] Bluetooth: HCI UART protocol Intel registered [   54.450367] Bluetooth: HCI UART protocol Broadcom registered [   54.450978] Bluetooth: HCI UART protocol QCA registered [   54.466370] Bluetooth: HCI UART protocol AG6XX registered [   54.481649] Bluetooth: HCI UART protocol Marvell registered [   54.871946] Bluetooth: hci0: BCM: chip id 130 [   54.878835] Bluetooth: hci0: BCM: features 0x0f [   54.881103] Bluetooth: hci0: BCM4345C5 [   54.881119] Bluetooth: hci0: BCM4345C5 (003.006.006) build 0000 [   54.915175] Bluetooth: hci0: BCM4345C5 'brcm/BCM4345C5.hcd' Patch [   55.863677] Bluetooth: hci0: BCM: features 0x0f [   55.889055] Bluetooth: hci0: BCM4345C5 Ampak_CL1.5 UART 37.4 MHz BT 5.0 [Version: Version: 0033.0080] [   55.889093] Bluetooth: hci0: BCM4345C5 (003.006.006) build 0080

This all look good.

[   55.890379] Bluetooth: hci0: BCM: Using default device address (43:45:c5:00:1f:ac)

And this is the problem. These wifi/bluetooth chips do not have a unique MAC programmed into them. The kernel recognizes that this is using a default MAC which means that 2 devices in the same room will cause collisions and to avoid this the kernel brings the Bluetooth HCI up in an unconfigured state.

The problem is that userspace does not really have support for this yet. Userspace should see this generate a random MAC once and store this on disk and then use from then on. But the code to do that is not there yet.

To manually fix this you need the btmgmt utility this is part of bluez, which should already be installed.

You can fix this manually by running:

/usr/bin/btmgmt -i hci0 public-addr 'B0:F1:EC:87:1D:B3'

after this "bluetoothctl list" should show a working Controller entry, if not try restarting bluez:

"sudo systemctl restart bluetooth"

but IIRC bluez should pick up that the controller is configured properly now itself after running the btmgmt command.

Note if you have multiple boards then you need to make sure you use a unique address per board.

I personally use a small udev rule + service file to automatically do this as soon as the hci0 device becomes ready:

--- 60-hci-btaddress.rules --- install under /etc/udev/rules.d ACTION=="add", SUBSYSTEM=="bluetooth", ENV{DEVTYPE}=="host" \ ENV{DEVPATH}=="*/serial[0-9]*/serial[0-9]*/bluetooth/hci[0-9]*", \ TAG+="systemd", ENV{SYSTEMD_WANTS}="hci-btaddress@%k.service" ---

--- hci-btaddress@.service --- install under /etc/systemd/system/ [Unit] Description=HCI btaddress check/fixup

[Service] Type=simple ExecStart=/usr/bin/btmgmt -i %I public-addr 'B0:F1:EC:87:1D:B3' ---

After installing these things should automatically work after a reboot.

Note this is just a workaround, but it should get things working.

Regards,

Hans

p.s.

For a proper fix the problem is that my .service file hardcodes the MAC to be able to have something which we can submit to bluez upstream (1), we need some utility which when invoked check if a MAC address was already generated and stored somewhere under /var/lib/bluetooth/ and if not then that utility should generate a valid random MAC and store. This utility should always print the generated/cached MAc to stdout for the udev rule to consume.

This little helper binary should probably take some sort of canonicalized link to the parent device as argument so that this setup can also work in the (mostly theoretical) case of there being 2 bluetooth controllers needing a MAC to be generated.

udev/systemd already generates a fixed MAC for the wifi part based on the MAC address reporting a type of being random-generated "ifp->ndev->addr_assign_type = NET_ADDR_RANDOM;" in drivers/net/wireless/broadcom/brcm80211/brcmfmac/common.c so another option would be to see if we can leverage the existing udev/systemd code which checks for addr_assign_type = NET_ADDR_RANDOM on the network device side and see if we can borrow parts of that for the bluetooth side. If nothing else at least the random MAC generation code would be good to borrow since not all random 48 bit numbers are valid random MAC addresses.

1) And / or integrate into the Fedora bluez packages as a downstream fix