Arch Linux ARMをChromebookC201にインストールしています。Bluetoothを正常に動作させようとしていますが、どこに問題があるのかわかりません。
dmesg
の出力は、システムがオンボードBluetoothコントローラーを正常に検出して初期化していることを示しているようです。
$ 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
私が見る限り、Bluetoothに必要なカーネルモジュールも起動時にロードされているようです。
$ lsmod | grep ^b
bnep 20480 2
btsdio 16384 0
bluetooth 352256 9 btsdio,bnep
/sys/class/bluetooth
には次のものがあります。
$ ls /sys/class/bluetooth
hci0
つまり、ある種のBluetoothデバイスが存在するように見えます。
bluez
およびbluez-utils
パッケージをインストールし、bluetoothdを有効にしました。これは、実行中であることを確認しました。
$ 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
また、Bluetoothコントローラーがrfkillによってブロックされていないことも確認しました。
$ rfkill list
0: phy0: Wireless LAN
Soft blocked: no
Hard blocked: no
1: hci0: Bluetooth
Soft blocked: no
Hard blocked: no
ただし、bluetoothctl
(またはblueman
)を実行しようとすると、Bluetoothアダプターが見つかりません。
$ bluetoothctl
Agent registered
[bluetooth]# list
[bluetooth]#
他に試すことは考えられません。足りないものはありますか?
編集:
与えられた唯一の答えは問題を解決しませんでした、そして、賞金からいくらかの追加の可視性を得たにもかかわらず、この質問への応答はほとんどなかったようです。それでは、そこにあるはずのすべてが正しく配置されているように見えると推測する必要がありますか?それは、おそらくbluezまたはカーネルモジュールでバグである可能性が高いことを示していますか?
Bluezバージョンが5.50-6より前の場合、既知の問題: https://bugs.archlinux.org/task/61386
5.50-6は、偶然にも(Intel)Chromebookで動作しています。
C201で検出されたSDIO接続のBluetoothモジュールはおとりです。 C201でbtsdio
ドライバーを使用しないでください。実際、カーネルに登録されている機能不全のホストコントローラーに対処する必要がないように、C201でこのモジュールを完全に無効にするかブラックリストに登録することをお勧めします。
C201のBCM4354BluetoothモジュールはUART経由で接続され、hci-uart
およびbtbcm
ドライバーを使用してアクセスできます。 hci-uart
ドライバー(CONFIG_BT_HCIUART_BCM=y
)でbroadcomサポートが有効になっていることを確認してください。これらのドライバーは、デバイスをBluetoothサブシステムに接続するために追加の起動手順を必要とします。たとえば、実行できます
# 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
次に、デバイスが登録されていることを確認します。このモジュールを動作させるには、独自のファームウェアが必要です。プレインストールされたOSイメージからファイルBCM4354_003.001.012.0358.0746.hcd
を取得し、カーネルがそれを見つけるために/lib/firmware/brcm/BCM4354.hcd
に保存しました。
さらに詳しく調べてみると、btattachのbaudrateオプションは実際には何もしていないようです。そのため、Bluetoothコントローラーが115kbaudで接続されてしまい、少し時間がかかります。適切な方法は、コントローラーをデバイスツリーに追加することのようです。そこで、Linux 5.2のデバイスツリーソースに次のパッチを適用しました。3Mbaudというはるかに使いやすい速度で動作しています(ボーナスとして、btattachを実行しなくなり、起動時にすべてが自動的に登録されます)。
Serdevデバイスツリー機能を機能させるには、CONFIG_SERIAL_DEV_CTRL_TTYPORT=y
を有効にする必要があります。
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 {