** Description changed:
+ Impact:
+
+ Upon boot, no hci device is available to userspace, thus bluetooth
+ communication is not possible.
+
+ Defect analysis:
+
+ The root of the problem lies in these two patches:
+
+ $ git log --online drivers/bluetooth/btqcomsmd.c
+
+ ...
+ 766154b Bluetooth: btqcomsmd: retrieve BD address from DT property
+ 6e51811 Bluetooth: btqcomsmd: Add support for BD address setup
+ ...
+
+ Qualcomm engineer found that btqcomsmd had no BD address burned in (nor
+ via ROM, neither internally) and it was always coming up with the same
+ address, probably derived from manufacturer ID and / or chip ID.
+
+ To fix this, they pushed the burden of generating a unique per-board BD
+ address to the Qualcomm bootloader and make it pass down via DTB to the
+ live kernel - and if no address was present in the DTB, the hci was left
+ unconfigured.
+
+ Fix:
+
+ So *technically* speaking, the kernel is correct in this case, it's our
+ dragonboard image (e.g. Ubuntu Core) that doesn't extract the generated
+ BD address from the Qualcomm bootloader and pass it down to the kernel.
+
+ On the other hand, having Bluetooth working out of the box (even with a
+ dummy address), is a nice feature to have, so i slightly modified
+ Qualcomm's code introduced in the two above patches, and made the lack
+ of DB address in DTB non fatal:
+
+ if DTB_has_BD_address()
+ read_BD_addr_and_apply_it()
+ else
+ default_back_to_dummy_addr()
+ end if
+
+ And surrounded the modification in #ifdef...#endif brackets to keep it
+ local.
+
+ How to test:
+
+ By default, on a patched kernel, the hci device will have a default
+ address:
+
+ ubuntu@dragon410c:~$ hcitool dev
+ Devices:
+ hci0 00:00:00:00:5A:AD
+
+ the address " 00:00:00:00:5A:AD" might vary per board, but will be
+ consistent after every reboot.
+
+ The other option is to specify a custom address via dtb, e.g. using uboot to
manipulate the dtb - we assume the dtb ws loaded in memory at ${fdt_addr}:
+
+ dragonboard410c => fdt addr ${fdt_addr}
+
+ dragonboard410c => fdt print /soc/wcnss/smd-edge/wcnss/bt/
+ bt {
+ compatible = "qcom,wcnss-bt";
+ };
+
+ dragonboard410c => fdt resize
+
+ dragonboard410c => fdt set /soc/wcnss/smd-edge/wcnss/bt/ local-bd-
+ address [ 55 44 33 22 11 00 ]
+
+ dragonboard410c => fdt print /soc/wcnss/smd-edge/wcnss/bt/
+ bt {
+ local-bd-address = [55 44 33 22 11 00];
+ compatible = "qcom,wcnss-bt";
+ };
+
+ then proceed with the rest of the boot process and check hci:
+
+ $ hcitool dev
+ Devices:
+ hci0 00:11:22:33:44:55
+
+ In both cases, blueooth work afterward, and can be used to communicate
+ with other devices:
+
+ ubuntu@dragon410c:~$ hcitool scan
+ Scanning ...
+ C0:BD:54:12:4E:D1 My dummy device
+
+
+ Regression potential:
+
+ None, the fix is surronded with #ifdef...#endif thus it doesn't exist
+ outside of it.
+
+ --
+
+
Using the core18 image from
http://cdimage.ubuntu.com/ubuntu-core/18/stable/current/
Kernel snap: 4.15.0-39.42 (72)
rfkill shows there is an hci0 device:
$ rfkill list
0: hci0: Bluetooth
- Soft blocked: no
- Hard blocked: no
+ Soft blocked: no
+ Hard blocked: no
1: phy0: Wireless LAN
- Soft blocked: no
- Hard blocked: no
+ Soft blocked: no
+ Hard blocked: no
But bluetoothctl does not detect any controller:
$ sudo bluetoothctl
08:58 Agent registered
08:58 [bluetooth]# list
[...no output...]
If you revert to the 4.4 kernel [4.4.0-1106.111 (76)] it works:
$ sudo bluetoothctl
[NEW] Controller 00:00:00:00:5A:AD BlueZ 5.47 [default]
Agent registered
[bluetooth]# list
Controller 00:00:00:00:5A:AD BlueZ 5.47 [default]
[bluetooth]# show
Controller 00:00:00:00:5A:AD
- Name: BlueZ 5.47
- Alias: BlueZ 5.47
- Class: 0x00000000
- Powered: no
- Discoverable: no
- Pairable: yes
- UUID: Generic Attribute Profile (00001801-0000-1000-8000-00805f9b34fb)
- UUID: A/V Remote Control (0000110e-0000-1000-8000-00805f9b34fb)
- UUID: OBEX File Transfer (00001106-0000-1000-8000-00805f9b34fb)
- UUID: Generic Access Profile (00001800-0000-1000-8000-00805f9b34fb)
- UUID: OBEX Object Push (00001105-0000-1000-8000-00805f9b34fb)
- UUID: PnP Information (00001200-0000-1000-8000-00805f9b34fb)
- UUID: A/V Remote Control Target (0000110c-0000-1000-8000-00805f9b34fb)
- UUID: IrMC Sync (00001104-0000-1000-8000-00805f9b34fb)
- UUID: Vendor specific (00005005-0000-1000-8000-0002ee000001)
- UUID: Message Notification Se.. (00001133-0000-1000-8000-00805f9b34fb)
- UUID: Phonebook Access Server (0000112f-0000-1000-8000-00805f9b34fb)
- UUID: Message Access Server (00001132-0000-1000-8000-00805f9b34fb)
- Modalias: usb:v1D6Bp0246d052F
- Discovering: no
+ Name: BlueZ 5.47
+ Alias: BlueZ 5.47
+ Class: 0x00000000
+ Powered: no
+ Discoverable: no
+ Pairable: yes
+ UUID: Generic Attribute Profile (00001801-0000-1000-8000-00805f9b34fb)
+ UUID: A/V Remote Control (0000110e-0000-1000-8000-00805f9b34fb)
+ UUID: OBEX File Transfer (00001106-0000-1000-8000-00805f9b34fb)
+ UUID: Generic Access Profile (00001800-0000-1000-8000-00805f9b34fb)
+ UUID: OBEX Object Push (00001105-0000-1000-8000-00805f9b34fb)
+ UUID: PnP Information (00001200-0000-1000-8000-00805f9b34fb)
+ UUID: A/V Remote Control Target (0000110c-0000-1000-8000-00805f9b34fb)
+ UUID: IrMC Sync (00001104-0000-1000-8000-00805f9b34fb)
+ UUID: Vendor specific (00005005-0000-1000-8000-0002ee000001)
+ UUID: Message Notification Se.. (00001133-0000-1000-8000-00805f9b34fb)
+ UUID: Phonebook Access Server (0000112f-0000-1000-8000-00805f9b34fb)
+ UUID: Message Access Server (00001132-0000-1000-8000-00805f9b34fb)
+ Modalias: usb:v1D6Bp0246d052F
+ Discovering: no
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1810797
Title:
bluetooth controller not detected with 4.15 kernel
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux-snapdragon/+bug/1810797/+subscriptions
--
ubuntu-bugs mailing list
[email protected]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
