Ich habe Alpine Linux edge(zukünftig 3.15) x86 auf einem HP Stream 7 5709-Tablet (tl;dr: Bay Trail, Intel Atom Z3735G System-on-a-Chip), das über integriertes rtl8723bsWLAN/Bluetooth verfügt, das ich bereits für WLAN verwende und das gut funktioniert.
sl7alp:~$ uname -a
Linux sl7alp 5.10.72-1-lts #2-Alpine SMP Sat, 16 Oct 2021 06:04:30 +0000 i686 Linux
Für das WLAN /lib/firmware/rtlwifi/rtl8723bs_nic.binfehlte die genaue Firmware-Datei in der Distribution, aber sie ist dieselbe wie die rtl8723buvorhandene Version, also habe ich einfach einen symbolischen Link dazu erstellt und mit dem Standardtreiber funktionierte es problemlos, mehr war dafür nicht nötig.
Aber wie steht es mit Bluetooth?
Den grundlegenden Beschreibungen von around zufolge rtl8723bsstellt seine WLAN-Verbindung zum System über SDIO her, seine Bluetooth-Verbindung erfolgt jedoch über einen UART, und das steht im Einklang mit dem, was ich im Geräte-Manager-Verzeichnis unter Windows auf diesem System sehe; der UART, mit dem es verbunden ist, ist einer der im Atom-Prozessor integrierten „HS-UARTs“ (8086:0F0A).
Neben den Standardmodulen des 5.10-Kernels von Edge habe ich das entsprechende zusätzliche Kernelmodul mit den scheinbar relevanten Zusatzfunktionen aktiviert, erstellt und installiert:
CONFIG_SERIAL_DEV_BUS=m
CONFIG_BT_HCIUART_RTL=y
CONFIG_BT_HCIUART_3WIRE=y
CONFIG_SERIAL_DEV_CTRL_TTYPORT=y
Anschließend werden beim Booten die entsprechenden Module automatisch geladen:
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
Ich kann die Ausgabe sehen dmesg, die für die relevanten HS-UARTs gelten würde:
[ 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
Das Bluetooth-Gerät wird dadurch allerdings nicht automatisch verfügbar gemacht, bluetoothctles werden keine Controller aufgelistet und rfkillauch keine angezeigt.
Ich fand das (scheinbar ältere ~ 4.x Kernel-Ära) Drittanbieter-Repositoryhttps://github.com/lwfinger/rtl8723bs_btund der verbleibende Schritt ist, was ich erwarte, nämlich eine Art Initialisierungs-Handshake direkt über die UARTs durchzuführen und dann dem entsprechenden Teil der Bluetooth-Treiberinfrastruktur mitzuteilen, dass er aktiviert werden und sich damit verbinden und Bluetooth handhaben soll. Bei Verwendung dieses Repos kommt ./start_bt.shes jedoch einfach zu einem Fehler:
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
und ich kann weder eine Befehlszeile dafür zusammenstellen, btattachnoch funktioniert die Vanilla-Version hciattachbesser bluez-deprecatedals das.
Weitere Untersuchungen:
Ich sehe, dass in der ACPI-basierten Geräteaufzählung /sys/devicesdas Bluetooth-Gerät OBDA8723unter dem ersten Bay Trail Internal UART aufgeführt ist 80860F0A:00.
Der h5Treiber ( bluetooth/hci_h5.c) stellt eine ACPI-Tabelle mit einem Eintrag für bereit OBDA8723, und angesichts der Tatsache, dass das System automatisch entscheidet, das btrtlModul zu laden, gehe ich davon aus, dass es zumindest soweit ist, dass es wirksam wird.
Wenn ich jedoch ein paar zusätzliche pr_info()s herumstreue hci_h5, kann ich sehen, dass zwar der Haupttreiber h5_init()beim Bluetoothersten Laden aller Serdev-Treiber ausgeführt wird, sein jedoch h5_btrtl_setup()nie ausgeführt wird, auf den in der Struktur der Funktionszeiger verwiesen wird, die mit der ACPI-Tabelle übergeben werden.
Oh verdammt:
Und tatsächlich wird serdevdie Funktion serdev_drv_probe()nie ausgeführt. Warum?
Berichten über die Lösung ähnlicher Probleme zufolge ist dafür SERIAL_DEV_CTRL_TTYPORT. Ich hatte dies bereits aktiviert, aber:
Aus drivers/tty/serdev/Kconfig:
config SERIAL_DEV_CTRL_TTYPORT
[...]
depends on SERIAL_DEV_BUS != m
Mit anderen Worten: Zum Erstellen eines Kernels mit SERIAL_DEV_CTRL_TTYPORTist erforderlich, dass SERIAL_DEV_BUSes tatsächlich in den Kernel integriert ist ( =y) und nicht nur als Modul aktiviert wird.
Antwort1
Die HS-UART-Geräte, die mit ACPI aufgelistet werden können und über vorhandene Treiber verfügen, werden automatisch in einem mit erstellten 5.10-Kernel instanziiert CONFIG_SERIAL_DEV_CTRL_TTYPORT, und das reicht aus, um diesen Bluetooth-Controller automatisch ohne zusätzlichen Verbindungsschritt einzurichten. Sie benötigen keine zusätzlichen Dienstprogramme wie die, die für ältere Versionen auf GitHub verfügbar sind. Sie benötigen jedoch die erforderliche Kernelkonfiguration – CONFIG_SERIAL_DEV_CTRL_TTYPORTerfordert CONFIG_SERIAL_DEV_BUS=y, d. h. serdevin den Kernel integriert, nicht nur als Modul erstellt.
Nachdem ich ein neues Kernel-Paket installiert hatte, das alle
CONFIG_SERIAL_DEV_BUS=y
CONFIG_BT_HCIUART_RTL=y
CONFIG_BT_HCIUART_3WIRE=y
CONFIG_SERIAL_DEV_CTRL_TTYPORT=y
das System hat den Controller sofort erkannt:
[ 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
In war es standardmäßig aktiviert rfkillund ich konnte dann den bluetoothvon bereitgestellten Dienst starten bluezund verwenden, bluetoothctlum Bluetooth-Geräte zu suchen und einzurichten.
Aktualisieren:
Beachten Sie, dass in späteren Kerneln der Bluetooth-Controller beim Booten zunächst angezeigt wird, wie in der dmesgAusgabe angegeben, dann aber verschwindet, ohne dass in eine weitere Ausgabe erfolgt dmesg. Sie können jedoch sehen, wie Ihre Bluetooth-Geräte und der Controller in verschwinden, bluetoothctlwenn Sie es geöffnet haben:
[DEL] Device E8:06:88:xx:xx:xx rakslice’s keyboard
[DEL] Controller 08:D8:33:xx:xx:xx BlueZ 5.62 [default]
Dies scheint eine Kombination aus sicherer Standardkonfiguration der Bluetooth-Aktivierung und Energiesparfunktionen zu sein.
Wenn ich die Stromversorgung des Controllers über die /sys/devicesHierarchie explizit aktiviere, erscheint der Controller immer dmesgwieder bluetoothctl:
sudo bash -c 'echo on > /sys/devices/platform/80860F0A:00/serial0/serial0-0/power/control'
Allerdings funktioniert es immer noch nicht richtig:
[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
Ich habe dieses Problem in eine separate Frage verschoben, da die Fehlermeldung eindeutig ist und das Problem allein gut lösbar ist: So lösen Sie fehlgeschlagene „Bluez“-Verbindungsversuche mit „br-connection-adapter-not-powered“
tl;dr: Nach dem Bearbeiten /etc/bluetooth/main.confund Einstellen AutoEnable=trueunter [Policy]und dem anschließenden Neustart bluezwird der Controller dmesgwieder in angezeigt, wenn er offline war, und bleibt eingeschaltet.