Tengo Alpine Linux edge(futuro 3.15) x86 en una tableta HP Stream 7 5709 (tl;dr: Bay Trail, sistema en chip Intel Atom Z3735G), que tiene rtl8723bsWi-Fi/Bluetooth integrado, que estoy Ya lo estoy usando para Wi-Fi y está funcionando bien.
sl7alp:~$ uname -a
Linux sl7alp 5.10.72-1-lts #2-Alpine SMP Sat, 16 Oct 2021 06:04:30 +0000 i686 Linux
Para Wi-Fi, /lib/firmware/rtlwifi/rtl8723bs_nic.binfaltaba su archivo de firmware exacto en la distribución, pero es la misma rtl8723buversión que está presente, así que simplemente vinculé ese y funcionó bien con el controlador estándar, no se necesitaba nada más para eso.
Pero ¿qué pasa con el Bluetooth?
Según las descripciones básicas rtl8723bs, su Wi-Fi se conecta al sistema mediante SDIO, pero su Bluetooth se conecta a través de un UART, y esto es consistente con lo que veo en el árbol del Administrador de dispositivos en Windows en este sistema; el UART al que está conectado es uno de los procesadores Atom integrados en los "HS-UART" (8086:0F0A).
Además de los módulos predeterminados del kernel 5.10 de Edge, tengo el módulo de kernel adicional apropiado, con las características adicionales aparentemente relevantes activadas, construidas e instaladas:
CONFIG_SERIAL_DEV_BUS=m
CONFIG_BT_HCIUART_RTL=y
CONFIG_BT_HCIUART_3WIRE=y
CONFIG_SERIAL_DEV_CTRL_TTYPORT=y
Posteriormente, el arranque carga los módulos relevantes automáticamente:
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
Puedo ver el dmesgresultado que sería para los HS-UART relevantes:
[ 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
Pero esto no hace que el dispositivo Bluetooth esté disponible automáticamente; bluetoothctlno enumera ningún controlador y rfkillno muestra ninguno.
Encontré el repositorio de terceros (aparentemente más antiguo ~ era del kernel 4.x)https://github.com/lwfinger/rtl8723bs_bty el paso restante es lo que espero, hacer algún tipo de protocolo de enlace de inicialización con él directamente a través de los UART, y luego decirle a la pieza relevante de la infraestructura del controlador Bluetooth que se active, se conecte y maneje su Bluetooth, pero usando ese repositorio ./start_bt.sh, solo errores:
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
y no puedo inventar una línea de comando para que btattachfuncione mejor que eso.hciattachbluez-deprecated
Más investigación:
Veo que la enumeración de dispositivos basada en ACPI a continuación /sys/devicestiene el dispositivo Bluetooth como OBDA8723, debajo del UART interno del primer rastro de bahía 80860F0A:00.
El h5controlador ( bluetooth/hci_h5.c) proporciona una tabla ACPI con una entrada para OBDA8723y, a juzgar por el hecho de que el sistema decide automáticamente cargar el btrtlmódulo, espero que al menos esté llegando a donde necesita ir para que surta efecto.
Sin embargo, agregando algunos pr_info()mensajes adicionales hci_h5, puedo ver que si bien el controlador principal h5_init()se ejecuta cuando Bluetoothcarga inicialmente todos los controladores serdev, su h5_btrtl_setup(), al que se hace referencia en la estructura de punteros de función pasados con la tabla ACPI, nunca se ejecuta.
Oh, maldito:
Y, de hecho, serdevla función serdev_drv_probe()ni siquiera se ejecuta. ¿Por qué?
Según los informes sobre la solución de problemas similares, es necesario SERIAL_DEV_CTRL_TTYPORT. Ya había habilitado esto, pero:
De drivers/tty/serdev/Kconfig:
config SERIAL_DEV_CTRL_TTYPORT
[...]
depends on SERIAL_DEV_BUS != m
En otras palabras, construir un kernel SERIAL_DEV_CTRL_TTYPORTrequiere que SERIAL_DEV_BUSesté realmente integrado en el kernel ( =y), no solo habilitado como un módulo.
Respuesta1
Los dispositivos HS-UART que se pueden enumerar usando ACPI y que tienen controladores presentes se crearán automáticamente en un kernel 5.10 creado con CONFIG_SERIAL_DEV_CTRL_TTYPORT, y eso es suficiente para configurar este controlador Bluetooth automáticamente sin ningún paso de conexión adicional. No necesita ninguna utilidad adicional, como las que flotan en GitHub para versiones anteriores. Pero necesita tener la configuración del kernel requerida: CONFIG_SERIAL_DEV_CTRL_TTYPORTrequiere CONFIG_SERIAL_DEV_BUS=y, es decir, serdevintegrada en el kernel, no solo como un módulo.
Una vez que instalé un nuevo paquete de kernel creado con todos
CONFIG_SERIAL_DEV_BUS=y
CONFIG_BT_HCIUART_RTL=y
CONFIG_BT_HCIUART_3WIRE=y
CONFIG_SERIAL_DEV_CTRL_TTYPORT=y
el sistema detectó el controlador de inmediato:
[ 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
Estaba habilitado de forma predeterminada en rfkilly luego podía iniciar el bluetoothservicio proporcionado por bluezy usarlo bluetoothctlpara buscar y configurar dispositivos bluetooth.
Actualizar:
Tenga en cuenta que en kernels posteriores, el controlador bluetooth aparecerá inicialmente durante el arranque, como se indica en el dmesgresultado, pero luego desaparecerá, sin más resultados en dmesg, pero puede ver que sus dispositivos bluetooth y el controlador desaparecen bluetoothctlsi lo tiene abierto. :
[DEL] Device E8:06:88:xx:xx:xx rakslice’s keyboard
[DEL] Controller 08:D8:33:xx:xx:xx BlueZ 5.62 [default]
Esto parece ser una combinación de configuración predeterminada segura de activación de Bluetooth y funciones de ahorro de energía.
Si habilito explícitamente el poder del controlador a través de la /sys/devicesjerarquía, el controlador aparece una dmesgy bluetoothctlotra vez:
sudo bash -c 'echo on > /sys/devices/platform/80860F0A:00/serial0/serial0-0/power/control'
Sin embargo, todavía no funciona correctamente:
[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
Moví ese problema a una pregunta separada ya que el mensaje de error es único y es un problema que se puede resolver por sí solo: Cómo resolver los intentos de conexión de `bluez` que fallan con `br-connection-adapter-not-powered`
tl;dr: Después de editar /etc/bluetooth/main.confy configurar AutoEnable=trueen [Policy]y luego reiniciar bluez, el controlador volverá a aparecer dmesgsi estaba desconectado y permanecerá encendido.