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 -- _______________________________________________ arm mailing list -- arm@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to arm-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/arm@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
