btuart: Allow BDADDR to be supplied by service

[rfinnie]

For systems where the rpt-patched bluez package is not installed and cannot automatically determine the address.

[pelwell]

Please give more details of the motivation behind this commit - what aspect of the unpatched BlueZ does this work around? And why use an environment variable when a command line parameter would seem cleaner?

[rfinnie]

Sure, on a Raspberry Pi 4, bluez will only automatically set its bdaddr with raspberry-pi-mods.patch applied, otherwise it defaults to aa:aa:aa:aa:aa:aa. On a Pi 4 + Debian/Ubuntu/etc, with the proposed change I could just install pi-bluetooth and put in a systemd override to force $BDADDR:

/etc/systemd/system/hciuart.service.d/local.conf

[Service]
Environment=BDADDR=b8:27:eb:1f:ef:0a

As for command line parameter, when the script is intended to be used as an initscript, traditionally options are usually passed by environment variable since the user doesn't need to know if/how to override the command line (in this case there's nothing existing on the command line, but still). (Historically done via /etc/default -- come to think of it, that's simple to support, so I've updated the proposal to enable using /etc/default/hciuart.)

[pelwell]

I'm happy to merge this change, but there are a few things I need to say first:

1. I'm hoping to move away from hciattach completely - it's a deprecated command - and get the kernel to apply the patch file. Unfortunately the kernel can't set the BDADDR, but there is an optional utility in BlueZ called bdaddr that could be used.

2. Pi 4 shouldn't need it's BDADDR setting - it should be programmed into OTP. Are you sure it isn't set already?

[pelwell]

(The Ethernet, WLAN and BT addresses should be sequential)

[rfinnie]

2. Pi 4 shouldn't need it's BDADDR setting - it should be programmed into OTP. Are you sure it isn't set already?

Hmm, I've got 3 Pi 4s, bought at different times (two 4GBs, one 2GB), one each running Raspbian, straight Debian and Ubuntu. Raspbian works fine without an explicit bdaddr, Debian/Ubuntu hciattach both fall back to aa:aa:aa:aa:aa:aa, so I assumed it was a matter of the rpt-specific patch being the culprit. Do you know if I can check the OTP-programmed BT address directly? FWIW, both the Ethernet and WLAN hardware addresses are sane, WLAN follows Ethernet, and Ethernet == smsc95xx.macaddr cmdline provided by the firmware.

[pelwell]

There are no downstream BlueZ patches that have anything to do with BDADDR handling. The closest that raspberrypi-sys-mods gets to Bluetooth is creating the UART aliases serial0 and serial1.

The best way to confirm that your OTP is programmed is to flash a build of Raspberry Pi OS to a spare card - the Lite version is fine - and boot it on your Pi 4. As you will see from the btuart script there is nothing to set the address for the Pi 4 case, and there is nowhere in the software that takes the Ethernet address and adds 2 (or the WLAN address and adds 1) to derive it, so if hcitool dev shows a DC:A6:32:xx:yy:zz address then the OTP is programmed.

However, I've discovered that if you remove the Bluetooth firmware (/lib/firmware/brcm/BCM4345C0.hcd) and reboot you will get a BDADDR of AA:AA:AA:AA:AA:AA, so perhaps the firmware is not present (or not being loaded) in your case.

[rfinnie]

Aha! Turns out lack of bluez raspberry-pi-mods.patch WAS responsible, in a roundabout way:

--- a/tools/hciattach_bcm43xx.c
+++ b/tools/hciattach_bcm43xx.c
@@ -43,7 +43,7 @@
 #include "hciattach.h"

 #ifndef FIRMWARE_DIR
-#define FIRMWARE_DIR "/etc/firmware"
+#define FIRMWARE_DIR "/lib/firmware"
 #endif

 #define FW_EXT ".hcd"

(/etc/firmware, really? That should be upstreamed.)

Pointing /etc/firmware to /lib/firmware and all is now good.

Thanks for the help! If you want to accept this PR, please go ahead since it doesn't hurt anything, otherwise please close it as I don't need it.

[pelwell]

We're taking steps towards an hciattach-free future, so I don't think it's the right time for this patch.