Upon updating to 9.2.2 on one of my S905X’s (version with 3GB ram, and I have 2 more that are identical I haven’t tested) blue tooth didn’t work. It turned on, but no devices showed up. Reverting to 9.2.1 solved the problem. I didn’t get a chance to look into it much (dmesg, etc) as I quickly reverted it due to needing the box to be in service but I can check it out again later tonight. If anyone has any suggestion on how to debug, bluetooth commands to run over ssh, etc let me know.
Just tested again. Bluetooth is on, but bluetooth under CoreElec configuration tool says ‘no adapter found’. Dmesg shows BCM_BT going on, and then ~1 second later going off. Toggling blue tooth on and off does nothing. Here is the relevant part of dmesg: https://pastebin.com/yygVRd3U
Reverting to 9.2.1 fixes the issue.
@anon88919003 Any thoughts on the bluetooth problem I posted earlier? W/ 9.2.2 it says ‘no adapter found’. Rolling back to 9.2.1 works fine. The dmesg (which I posted) shows BT going on, and then being turned off 1 second later.
Think you’re seeing the same as me. I’m seeing BT radios turn off.
Going to guess you have RTL8723BS as well?
udevadm info /sys/bus/sdio/devices/sdio* will give you the relevant info.
@juggie impossible to say without knowing exactly which adaptor is in your device.
There was a lot of changes surround the Wifi and BT drivers but this was mainly around newer devices, I was aware prior to the release that RTL8723BS adaptors wasn’t working anymore on older devices but that it is working on newer devices.
Hey @anon88919003 thanks for the quick reply.
I was able to confirm from sdio that it is indeed a RTL8723BS. It’s a S905x with 3gb of ram, not old but certainly also not new. I’m not sure if the Wi-Fi was working as I use ethernet.
Is there anything that can be done to get these working again? Should I expect this to also be broken in 4.9 kernel (-ng releases) as well? I have not tested a funhouse build as I was waiting for the s905x support to be a bit more official.
Thanks again for your support.
@juggie wifi should work just fine, there is multiple versions of the RTL8723B chip and the firmware that we updated was to get newer devices working.
I could probably create something to get BT working again for you.
I doubt S905X support will be added to our 4.9 releases as there is simply too many issues with it and most of the devs are focused on newer SoC’s.
Hey @anon88919003,
Could something be added to decide which BT firmware is used? Either by a manual switch or using PCI IDs to determine which ones need newest BT firmware. Or if that’s too much effort can you point me in the direction of the file with the firmware and I’ll just overwrite it with the 9.2.1 version.
In the meantime I guess it’s time to start shopping for some new boxes!
@juggie it’s more complex than that, in 9.2.1 we was using a binary to inject firmware into the rtl8723bs that was only compatible with that chip, since then we have switched to a newer version that supports injecting firmware into multiple chips ie rtl8723bs/rtl8822bs/rtl8822cs.
The new injection binary doesn’t work with the older rtl8723bs chip though, either code is missing or something else, I didn’t spend a great deal of time looking at it because I don’t actually physically have a device with that chip to actually work from and everything was done remotely with the help of @lbernstone, @JohnBoyz and @bam, the goal was to get S905X2 and S905X3 based boxes working which they now all do.
Unfortunately I was made aware that S905X wasn’t working in nightlies any longer and I did try numerous firmwares and none of them worked with the new injection binary…not even the old firmware.
It is possible to use the old loader along with the old firmware and create a system.d service to get it working though.
@anon88919003 would access to a s905x box with this bt help? I have a 3rd one I’m not using as it has broken ethernet. I could throw it up on a empty VLAN with outbound Internet blocked for you to poke at the BT loader. Up to you just a thought. If there’s anything I can run or do to help let me know. Do we have the source for both firmware loaders?
@anon88919003 Anything I can do to assist?
Same here.
udevadm info /sys/bus/sdio/devices/sdio*
P: /devices/d0070000.sdio/mmc_host/sdio/sdio:0001/sdio:0001:1
L: 0
E: DEVPATH=/devices/d0070000.sdio/mmc_host/sdio/sdio:0001/sdio:0001:1
E: DRIVER=rtl8723bs
E: SDIO_CLASS=07
E: SDIO_ID=024C:B723
E: MODALIAS=sdio:c07v024CdB723
E: SUBSYSTEM=sdio
E: USEC_INITIALIZED=13492164
E: SYSTEMD_WANTS=rtkbt-firmware-aml.service
E: TAGS=:systemd:
Bluetooth device disappeared 
There was such kernel module discharge policy in the release info?
My system autoupgraded. Any suitable way to revert to 9.2.1 without re-installing and reconfiguring everything?
Thanks
From https://github.com/CoreELEC/CoreELEC/releases/
Changes since 9.2.1:
* Added support for Khadas VIM3L
* Added support for Odroid C4
<--snips-->
* Added Bluetooth support for RTL8822CS
* Updated Bluetooth firmware for RTL8723BS
In my mind "updated" means "improved" too.I’ve had the same issue and downgraded successfully to 9.2.1 yesterday. You just have to copy 9.2.1 gzipped image to STORAGE/Update folder on the device and do a reboot. It’s a good idea to do a backup just to be safe.
@juggie as explained in my previous post there is no scenario in this to make everybody happy.
I could revert the changes just for the older devices but then I know of at least 1 user who will lose Bluetooth as a result of this.
@anon88919003 You mentioned using the old firmware with a systemd service, would you be able to document that hack here? I’ve got no problem with systemd, but I don’t know where the the loader and firmware are without some digging.
All this said a regression in a minor update is not awesome. Is there anyway we could dynamically chose on boot between new/old loader at boot?
Firstly you would have to mask the existing service with systemctl mask rtkbt-firmware-aml
Then you need the following files from 9.2.1
/usr/bin/rtk_hciattach
/lib/firmware/rtl_bt/rtl8723b_fw
/lib/firmware/rtl_bt/rtl8723b_config
You would need to modify autostart.sh to copy the firmware to the directory as it will be erased on each reboot.
The binary could be run from any directory and the command to initiate it could also be placed into autostart.sh rather than starting it via systemd to make things easier.
rtk_hciattach -n -s 115200 /dev/ttyS1 rtk_h5 2000000
@anon88919003 looks easy enough. I’ll take a closer look and dig through the new service and related scripts. With the information you provided it feels like we should be able to ship openelec with both loaders, both firmwares and have the service chose the right thing to do.
just do the following, systemctl mask rtkbt-firmware-aml
mkdir /storage/rtl8723bs
copy the files to that dir
edit /storage/.config/autostart.sh and add
mkdir -p /lib/firmware/rtl_bt
cp /storage/rtl8723bs/rtl8723bs* /lib/firmware/rtl_bt
/storage/rtl8723bs/rtk_hciattach -n -s 115200 /dev/ttyS1 rtk_h5 2000000 &
and reboot and it should work then
it’s not possible to use both because there is no way to tell the working chip apart from the non working one, RTL8723BS works on S905X2 and newer chips with the new loader, it just doesn’t work on the older one.
@roy5k
Thanks. I’ll try downgrading and then disabling.