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@lists.fedoraproject.org
To unsubscribe send an email to arm-leave@lists.fedoraproject.org
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@lists.fedoraproject.org
Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
No comments:
Post a Comment