Bluetooth doesn't work on OPI3 LTS

[stijn-devriendt]

Hi,

The image built by current mainline doesn't include hciattach_opi: During build it shows:

install: cannot stat '/home/sde/projects/orangepi-build/external/packages/blobs/bt/hciattach/hciattach_opi_arm64_current': No such file or directory

It looks like this patch (ef22bd4b078388eab200a68384a6dff8d959dcb0) did not include the same change for the OPI3 hardware: https://github.com/orangepi-xunlong/orangepi-build/blob/main/external/config/sources/families/sun50iw6.conf

There's also the issue that the 'addr_mgt' kernel module is not yet available in the 5.10 kernel. This makes the hciattach_opi tool segfault when trying to read the mac address.

Regards, Stijn

[orangepi-xunlong]

Hello,

It's fixed, you can update the orangepi-build and test it again. Thank you!

[stijn-devriendt]

Thank you for your quick turnaround. I've rebuilt the RFS and the mentioned issues are fixed.

Unfortunately, there remains a problem that bluetooth low-energy doesn't appear to function properly. When a scan is started, no BLE devices are found:

> sudo apt-get install -y bluez
> bluetoothctl
# menu scan
# transport le
# back
# scan on

does not detect BLE devices. However:

hcitool lescan

does detect them.

Evidence points towards a bug in the driver, since bluez uses the MGMT protocol to start a scan while hcitool uses raw HCI commands. It looks like the translation from mgmt protocol to hci in the kernel (driver) is broken for LE scanning.

[stijn-devriendt]

I think I found the root cause for the BLE problem. I decided to follow the lead of https://github.com/orangepi-xunlong/linux-orangepi/blob/orange-pi-5.10/net/bluetooth/hci_core.c#L927 and find out what caused the error.

Using 'btmon', I triggered the __hci_init trace by restarting bluetoothd. This gave the following output:

< HCI Command: Write Default Link Policy Settings (0x02|0x000f) plen 2                                                                                                                 #1 [hci0] 17.827640
        Link policy: 0x000d
          Enable Role Switch
          Enable Sniff Mode
          Enable Park State
> HCI Event: Command Complete (0x0e) plen 4                                                                                                                                            #2 [hci0] 17.832228
      Write Default Link Policy Settings (0x02|0x000f) ncmd 1
        Status: Invalid HCI Command Parameters (0x12)

This limits the problem to this function at https://github.com/linux-sunxi/linux-sunxi/blob/sunxi-next/net/bluetooth/hci_core.c#L379

Then, using hcitool (hcitool cmd 0x02 0x000f 0x0d 0x00), I tried various values to see which of the flags caused the issue and it appears that the one that causes it is the 'Park State'. The Bluetooth specification v5.3 doesn't list Park State anymore, so I believe it may have been removed at some point. The working command is thus: hcitool cmd 0x02 0x000f 0x05 0x00

Apparently, the kernel knows when it can enable the Park State by checking the features:

orangepi:~# hciconfig hci0 features
hci0:	Type: Primary  Bus: UART
	BD Address: 12:CF:07:B7:87:3F  ACL MTU: 1021:8  SCO MTU: 240:3
	Features page 0: 0xbf 0xff 0x8d 0xfe 0xdb 0x3d 0x7b 0xc7
		<3-slot packets> <5-slot packets> <encryption> <slot offset> 
		<timing accuracy> <role switch> <sniff mode> <park state>    <<<<<<<<-------------------
		<RSSI> <channel quality> <SCO link> <HV2 packets> 
		<HV3 packets> <u-law log> <A-law log> <CVSD> <power control> 
		<transparent SCO> <broadcast encrypt> <EDR ACL 2 Mbps> 
		<EDR ACL 3 Mbps> <enhanced iscan> <interlaced iscan> 
		<interlaced pscan> <inquiry with RSSI> <extended SCO> 
		<EV4 packets> <EV5 packets> <AFH cap. slave> 
		<AFH class. slave> <LE support> <3-slot EDR ACL> 
		<5-slot EDR ACL> <pause encryption> <AFH cap. master> 
		<AFH class. master> <EDR eSCO 2 Mbps> <extended inquiry> 
		<LE and BR/EDR> <simple pairing> <encapsulated PDU> 
		<err. data report> <non-flush flag> <LSTO> <inquiry TX power> 
		<EPC> <no. 62> <extended features> 
	Features page 1: 0x0b 0x00 0x00 0x00 0x00 0x00 0x00 0x00
	Features page 2: 0x31 0x0b 0x00 0x00 0x00 0x00 0x00 0x00

Here, you can see that the device advertises support for the park state (see emphasis)

If possible, I think the best approach would be to release new firmware that does not advertise support for Park State.