Eu tenho Alpine Linux edge(futuro 3.15) x86 em um tablet HP Stream 7 5709 (tl; dr: Bay Trail, sistema em um chip Intel Atom Z3735G), que possui um rtl8723bsWi-Fi/Bluetooth integrado, que eu sou já estou usando para Wi-Fi e está funcionando bem.
sl7alp:~$ uname -a
Linux sl7alp 5.10.72-1-lts #2-Alpine SMP Sat, 16 Oct 2021 06:04:30 +0000 i686 Linux
Para o Wi-Fi, seu arquivo de firmware exato /lib/firmware/rtlwifi/rtl8723bs_nic.binestava faltando na distribuição, mas é o mesmo que a rtl8723buversão que está presente, então eu apenas criei um link simbólico para aquele e funcionou bem com o driver padrão, não havia mais nada necessário para isso.
Mas e o Bluetooth?
De acordo com as descrições básicas rtl8723bs, seu Wi-Fi se conecta ao sistema usando SDIO, mas seu Bluetooth se conecta através de um UART, e isso é consistente com o que vejo na árvore do Gerenciador de dispositivos no Windows neste sistema; o UART ao qual está conectado é um dos processadores Atom integrados "HS-UART" (8086: 0F0A).
Além dos módulos padrão do kernel 5.10 do Edge, tenho o módulo adicional do kernel apropriado, com os recursos adicionais aparentemente relevantes ativados, compilados e instalados:
CONFIG_SERIAL_DEV_BUS=m
CONFIG_BT_HCIUART_RTL=y
CONFIG_BT_HCIUART_3WIRE=y
CONFIG_SERIAL_DEV_CTRL_TTYPORT=y
Posteriormente, a inicialização carrega os módulos relevantes automaticamente:
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
Posso ver a dmesgsaída que seria para os HS-UARTs 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
Mas isso não disponibiliza automaticamente o dispositivo Bluetooth; bluetoothctlnão lista nenhum controlador e rfkillnão mostra nenhum.
Encontrei o repositório de terceiros (aparentemente mais antigo da era do kernel 4.x)https://github.com/lwfinger/rtl8723bs_bte sua etapa restante é o que eu espero, fazendo algum tipo de handshake de inicialização diretamente através dos UARTs e, em seguida, informando à parte relevante da infraestrutura do driver Bluetooth para ativar e conectar-se a ele e lidar com seu Bluetooth, mas usando esse repositório ./start_bt.sh, ele apenas erros:
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
e não consigo inventar uma linha de comando btattachou o vanilla hciattachque bluez-deprecatedfuncione melhor do que isso.
Mais investigação:
Vejo que a enumeração do dispositivo baseado em ACPI /sys/devicestem o dispositivo Bluetooth como OBDA8723, na primeira trilha do compartimento UART interno 80860F0A:00.
O h5driver ( bluetooth/hci_h5.c) fornece uma tabela ACPI com uma entrada para OBDA8723, e a julgar pelo fato de que o sistema decide automaticamente carregar o btrtlmódulo, espero que ele esteja pelo menos chegando onde precisa para entrar em vigor.
No entanto, espalhando alguns pr_info()s extras por aí hci_h5, posso ver que enquanto o driver main h5_init()é executado quando Bluetoothcarrega inicialmente todos os drivers serdev, seu h5_btrtl_setup(), ao qual é referenciado na estrutura dos ponteiros de função passados com a tabela ACPI, nunca é executado.
Oh droga:
E, de fato, serdeva função de serdev_drv_probe()nunca é executada. Por que?
De acordo com relatos de resolução de problemas semelhantes, é necessário SERIAL_DEV_CTRL_TTYPORT. Eu já tinha habilitado isso, mas:
De drivers/tty/serdev/Kconfig:
config SERIAL_DEV_CTRL_TTYPORT
[...]
depends on SERIAL_DEV_BUS != m
Em outras palavras, construir um kernel SERIAL_DEV_CTRL_TTYPORTrequer que SERIAL_DEV_BUSele esteja realmente integrado ao kernel ( =y), e não apenas habilitado como um módulo.
Responder1
Os dispositivos HS-UART que podem ser enumerados usando ACPI e que possuem drivers presentes serão instanciados automaticamente em um kernel 5.10 compilado com CONFIG_SERIAL_DEV_CTRL_TTYPORT, e isso é suficiente para configurar este controlador Bluetooth automaticamente sem qualquer etapa adicional de anexação. Você não precisa de nenhum utilitário adicional, como aqueles disponíveis no GitHub para versões mais antigas. Mas você precisa ter a configuração necessária do kernel -- CONFIG_SERIAL_DEV_CTRL_TTYPORTrequire CONFIG_SERIAL_DEV_BUS=y, ou seja, serdevembutida no kernel, não apenas construída como um módulo.
Depois de instalar um novo pacote de kernel construído com todos
CONFIG_SERIAL_DEV_BUS=y
CONFIG_BT_HCIUART_RTL=y
CONFIG_BT_HCIUART_3WIRE=y
CONFIG_SERIAL_DEV_CTRL_TTYPORT=y
o sistema detectou o controlador imediatamente:
[ 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
Ele foi habilitado por padrão em rfkille eu poderia então iniciar o bluetoothserviço fornecido por blueze usá-lo bluetoothctlpara localizar e configurar dispositivos bluetooth.
Atualizar:
Observe que em kernels posteriores o controlador bluetooth aparecerá inicialmente durante a inicialização, conforme observado na dmesgsaída, mas desaparecerá, sem mais saída dmesg, mas você poderá ver seus dispositivos bluetooth e o controlador desaparecendo bluetoothctlse estiver aberto :
[DEL] Device E8:06:88:xx:xx:xx rakslice’s keyboard
[DEL] Controller 08:D8:33:xx:xx:xx BlueZ 5.62 [default]
Esta parece ser uma combinação de configuração padrão segura de ativação de Bluetooth e recursos de economia de energia.
Se eu habilitar explicitamente o poder do controlador através da /sys/deviceshierarquia, o controlador aparecerá dmesgnovamente bluetoothctl:
sudo bash -c 'echo on > /sys/devices/platform/80860F0A:00/serial0/serial0-0/power/control'
No entanto, ainda não funciona corretamente:
[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
Mudei esse problema para uma pergunta separada, pois a mensagem de erro é única e é um bom problema solucionável por si só: Como resolver tentativas de conexão `bluez` falhando com `br-connection-adapter-not-powered`
dr: Após editar /etc/bluetooth/main.confe configurar AutoEnable=trueem [Policy]e, em seguida, reiniciar bluez, o controlador reaparecerá dmesgnovamente se estiver offline e permanecerá ligado.