how to use rtl8723bs bluetooth in linux 5.10

Question

I have Alpine Linux edge (future 3.15) x86 on an HP Stream 7 5709 tablet (tl;dr: Bay Trail, Intel Atom Z3735G system-on-a-chip), which has an onboard rtl8723bs Wi-Fi/Bluetooth, which I'm already using for Wi-Fi and is working fine.

sl7alp:~$ uname -a
Linux sl7alp 5.10.72-1-lts #2-Alpine SMP Sat, 16 Oct 2021 06:04:30 +0000 i686 Linux

For the Wi-Fi, its exact firmware file /lib/firmware/rtlwifi/rtl8723bs_nic.bin was missing in the distribution, but it's the same as the rtl8723bu version which is present so I just symlinked that one and it worked fine with the stock driver, there was nothing else needed for that.

But how about the Bluetooth?

According to basic descriptions of rtl8723bs around, its Wi-Fi connects to the system using SDIO, but its Bluetooth connects via a UART, and this is consistent with what I see in the Device Manager tree on Windows on this system; the UART it's connected to is one of the Atom Processor built in "HS-UART" ones (8086:0F0A).

Besides the default modules of the edge's 5.10 kernel I've got the appropriate additional kernel module, with the seemingly relevant additional features turned on in the .config, built and installed:

CONFIG_SERIAL_DEV_BUS=m
CONFIG_BT_HCIUART_RTL=y
CONFIG_BT_HCIUART_3WIRE=y
CONFIG_SERIAL_DEV_CTRL_TTYPORT=y

Subsequently, booting loads the relevant modules automatically:

sl7alp:~$ lsmod | grep serdev
serdev                 20480  1 hci_uart
sl7alp:~$ lsmod | grep hci_uart
hci_uart               49152  0
btrtl                  16384  1 hci_uart
btintel                24576  1 hci_uart
serdev                 20480  1 hci_uart
bluetooth             356352  3 btrtl,hci_uart,btintel

I can see the dmesg output which would be for the relevant HS-UARTs:

[    1.062751] 80860F0A:00: ttyS1 at MMIO 0x50919000 (irq = 16, base_baud = 2764800) is a 16550A
[    1.079576] 80860F0A:01: ttyS2 at MMIO 0x5091b000 (irq = 17, base_baud = 2764800) is a 16550A

But this doesn't automatically make the Bluetooth device available; bluetoothctl does not list any controllers, and rfkill doesn't show any.

I found the (seemingly older ~ 4.x kernel era) third party repository https://github.com/lwfinger/rtl8723bs_bt and its remaining step is what I expect, doing some kind of initialization handshake with it directly through the UARTs, and then telling the relevant piece of Bluetooth driver infrastructure to wake up and attach to it and handle its Bluetooth, but using that repo's ./start_bt.sh, it just errors out:

Using device /dev/ttyS1 for Bluetooth
Realtek Bluetooth init uart with init speed:115200, final_speed:115200, type:HCI UART H5
Realtek Bluetooth :Realtek hciattach version 2.5
Realtek Bluetooth :3-wire sync pattern resend : 1, len: 8
[...]
Realtek Bluetooth :3-wire sync pattern resend : 40, len: 8
Realtek Bluetooth ERROR: H5 sync timed out

and I can't concoct a command line for btattach or the vanilla hciattach from bluez-deprecated that works any better than that.

More investigation:

I see that the ACPI-based device enumeration under /sys/devices has the Bluetooth device as OBDA8723, under the first bay trail internal UART 80860F0A:00.

The h5 driver (bluetooth/hci_h5.c) provides an ACPI table with one entry for OBDA8723, and judging by the fact that system automatically decides to load the btrtl module, I expect that it is at least somewhat getting to where it needs to go to take effect.

However, sprinkling some extra pr_info()s around hci_h5, I can see that while the driver's main h5_init() runs when Bluetooth initially loads all the serdev drivers, its h5_btrtl_setup(), which it is referenced in the struct of function pointers passed with the ACPI table, never runs.

Oh darn:

And in fact serdev's function serdev_drv_probe() never even runs. Why?

According to reports of solving similar issues, it requires SERIAL_DEV_CTRL_TTYPORT. I had already enabled this, but:

From drivers/tty/serdev/Kconfig:

config SERIAL_DEV_CTRL_TTYPORT
        [...]
        depends on SERIAL_DEV_BUS != m

In other words, building a kernel with SERIAL_DEV_CTRL_TTYPORT requires that SERIAL_DEV_BUS be actually built-in to the kernel (=y), not just enabled as a module.

Answer 1

The HS-UART devices that can be enumerated using ACPI and that have drivers present will get instantiated automatically in a 5.10 kernel built with CONFIG_SERIAL_DEV_CTRL_TTYPORT, and that's enough to set up this Bluetooth controller automatically without any additional attach step. You don't need any additional utilities such as those floating around on GitHub for older versions. But you need to have the required kernel config -- CONFIG_SERIAL_DEV_CTRL_TTYPORT requires CONFIG_SERIAL_DEV_BUS=y, i.e. serdev built-in to the kernel, not just built as a module.

Once I installed a new kernel package built with a config including:

CONFIG_SERIAL_DEV_BUS=y
CONFIG_BT_HCIUART_RTL=y
CONFIG_BT_HCIUART_3WIRE=y
CONFIG_SERIAL_DEV_CTRL_TTYPORT=y

the system detected the controller right away:

[    5.809856] Bluetooth: hci0: RTL: examining hci_ver=06 hci_rev=000b lmp_ver=06 lmp_subver=8723
[    5.814460] Bluetooth: hci0: RTL: rom_version status=0 version=1
[    5.814467] Bluetooth: hci0: RTL: loading rtl_bt/rtl8723bs_fw.bin
[    5.815894] Bluetooth: hci0: RTL: loading rtl_bt/rtl8723bs_config-OBDA8723.bin
[    5.838004] Bluetooth: hci0: RTL: cfg_sz 64, total sz 24508
[    6.720942] Bluetooth: hci0: RTL: fw version 0x365d462e

It was enabled by default in rfkill, and I could then start the bluetooth service provided by bluez, and use bluetoothctl to find and set up bluetooth devices.

Update:

Note that in later kernels the bluetooth controller will come up initially during boot, as noted in the dmesg output, but will then disappear, with no further output in dmesg, but you can see your bluetooth devices and the controller going away in bluetoothctl if you have it open:

[DEL] Device E8:06:88:xx:xx:xx rakslice’s keyboard
[DEL] Controller 08:D8:33:xx:xx:xx BlueZ 5.62 [default]

This appears to be some combination of safe default configuration of bluetooth enablement and power saving features.

If I explicitly enable the the controller's power through the /sys/devices hierarchy, the controller appears in dmesg and bluetoothctl again:

sudo bash -c 'echo on > /sys/devices/platform/80860F0A:00/serial0/serial0-0/power/control'

However it still doesn't function properly:

[bluetooth]# connect E8:06:88:xx:xx:xx
Attempting to connect to E8:06:88:xx:xx:xx
Failed to connect: org.bluez.Error.NotReady br-connection-adapter-not-powered

I moved that issue to a separate question as the error message is unique and it's a nice solvable issue on its own: How to solve `bluez` connection attempts failing with `br-connection-adapter-not-powered`

tl;dr: After editing /etc/bluetooth/main.conf and setting AutoEnable=true under [Policy], and then restarting bluez, the controller will reappear in dmesg again if it was offline and will stay on.