Why is bluetooth not working on my Chromebook (Arch Linux ARM)?

Question

I have Arch Linux ARM installed on a Chromebook C201. I've been trying to get bluetooth working without success and I can't figure out where the problem is.

The output of dmesg seems to indicate that the system is finding and initializing the onboard bluetooth controller successfully:

$ dmesg | grep Blue
[    4.058823] Bluetooth: Core ver 2.22
[    4.058865] Bluetooth: HCI device and connection manager initialized
[    4.058873] Bluetooth: HCI socket layer initialized
[    4.058877] Bluetooth: L2CAP socket layer initialized
[    4.058886] Bluetooth: SCO socket layer initialized
[    4.061738] Bluetooth: Generic Bluetooth SDIO driver ver 0.1
[    4.971101] Bluetooth: BNEP (Ethernet Emulation) ver 1.3
[    4.971104] Bluetooth: BNEP filters: protocol multicast
[    4.971113] Bluetooth: BNEP socket layer initialized

As far as I can see, the kernel modules that are required for bluetooth also seem to have been loaded on boot:

$ lsmod | grep ^b
bnep                   20480  2
btsdio                 16384  0
bluetooth             352256  9 btsdio,bnep

In /sys/class/bluetooth I have the following:

$ ls /sys/class/bluetooth
hci0

So, it looks like some sort of bluetooth device is there.

I have the bluez and bluez-utils packages installed and I have enabled bluetoothd, which I have confirmed is running:

$ systemctl status bluetooth.service
● bluetooth.service - Bluetooth service
   Loaded: loaded (/usr/lib/systemd/system/bluetooth.service; enabled; vendor preset:>
   Active: active (running) since Sun 2019-02-03 07:22:15 EST; 6h ago
     Docs: man:bluetoothd(8)
 Main PID: 324 (bluetoothd)
   Status: "Running"
    Tasks: 1 (limit: 4915)
   Memory: 2.4M
   CGroup: /system.slice/bluetooth.service
           └─324 /usr/lib/bluetooth/bluetoothd

I have also checked that the bluetooth controller is not being blocked by rfkill:

$ rfkill list
0: phy0: Wireless LAN
    Soft blocked: no
    Hard blocked: no
1: hci0: Bluetooth
    Soft blocked: no
    Hard blocked: no

However, if I try to run bluetoothctl (or blueman), no bluetooth adapters can be found:

$ bluetoothctl
Agent registered
[bluetooth]# list
[bluetooth]#

I can't think of anything else to try. Is there something that I'm missing?

---

Edit:

The only answer given didn't solve the issue, and there seems to have been very little response to this question, despite getting some extra visibility from the bounty. Should I infer, then, that everything that should be there seems to be correctly in place? Does that point to it being more likely to be a bug, perhaps in bluez or in the kernel module?

Answer 1

The SDIO-connected bluetooth module detected on the C201 is a decoy. You should not be using the btsdio driver on the C201, in fact I suggest disabling or blacklisting this module outright on the C201 so that you don't have to deal with a dysfunctional host controller registered with the kernel.

The BCM4354 bluetooth module on the C201 is connected via UART, accessible using the hci-uart and btbcm drivers. Make sure broadcom support is enabled in the hci-uart driver (CONFIG_BT_HCIUART_BCM=y). These drivers require an extra bootup step to connect the device with the bluetooth subsystem. You can run e.g.,

# btattach -S 3000000 -B /dev/ttyS0 -p bcm
Attaching Primary controller to /dev/ttyS0
Switched line discipline from 0 to 15
Device index 0 attached

Then you should see the device registered. This module requires proprietary firmware to operate. I took the file BCM4354_003.001.012.0358.0746.hcd from the preinstalled OS image, save it to /lib/firmware/brcm/BCM4354.hcd in order for the kernel to locate it.

On further inspection, the baudrate option to btattach doesn't seem to actually do anything so this ends up with the bluetooth controller being attached at 115kbaud which is a bit on the slow side. The proper way seems to be to add the controller to the devicetree. So I applied the following patch to the devicetree sources in Linux 5.2, and things are working at a much more usable speed of 3Mbaud (and as a bonus, you don't run btattach anymore, everything registers automatically at bootup).

You must enable CONFIG_SERIAL_DEV_CTRL_TTYPORT=y for the serdev devicetree features to work.

diff --git a/arch/arm/boot/dts/rk3288-veyron.dtsi b/arch/arm/boot/dts/rk3288-veyron.dtsi
index 1252522392c7..36000dbb8dda 100644
--- a/arch/arm/boot/dts/rk3288-veyron.dtsi
+++ b/arch/arm/boot/dts/rk3288-veyron.dtsi
@@ -57,7 +57,7 @@
        clocks = <&rk808 RK808_CLKOUT1>;
        clock-names = "ext_clock";
        pinctrl-names = "default";
-       pinctrl-0 = <&bt_enable_l>, <&wifi_enable_h>;
+       pinctrl-0 = <&wifi_enable_h>;

        /*
         * Depending on the actual card populated GPIO4 D4 and D5
@@ -71,8 +71,7 @@
         * - BT_I2S_WS_BT_RFDISABLE_L
         * - No connect
         */
-       reset-gpios = <&gpio4 RK_PD4 GPIO_ACTIVE_LOW>,
-                 <&gpio4 RK_PD5 GPIO_ACTIVE_LOW>;
+       reset-gpios = <&gpio4 RK_PD4 GPIO_ACTIVE_LOW>;
    };

    vcc_5v: vcc-5v {
@@ -402,6 +401,16 @@
    /* Pins don't include flow control by default; add that in */
    pinctrl-names = "default";
    pinctrl-0 = <&uart0_xfer &uart0_cts &uart0_rts>;
+
+   bluetooth {
+       compatible = "brcm,bcm43438-bt";
+       max-speed = <3000000>;
+
+       pinctrl-names = "default";
+       pinctrl-0 = <&bt_enable_l>;
+
+       shutdown-gpios = <&gpio4 RK_PD5 GPIO_ACTIVE_HIGH>;
+   };
 };

 &uart1 {

Answer 2

If your bluez version is prior to 5.50-6 then a known issue: https://bugs.archlinux.org/task/61386

5.50-6 is working here, on a (Intel) Chromebook coincidentally.