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.
I’ve reverted the changes so our next build will not have this issue for you, no date on when that will be right now though.
Thanks @anon88919003
I was able to retrieve the files you suggested from the CoreElec 9.2.1 disk image I used to dd my SD card.
Mounted first partition with 512x8192 offset.
# losetup -o 4194304 /dev/loop5
# mount /dev/loop5 /tmp/vdisk
The I copied “/tmp/vdisk/IMAGE” file outside the directory
# cp /tmp/vdisk/IMAGE /tmp/
Unmounted disk iimage and released loop5
# umount /tmp/vdisk
# losetup -d /dev/loop5
# umount /tmp/vdisk
Then unsquashed the filesystem IMAGE
# cd /tmp/ && unsquash IMAGE
I obtained a new dir /tmp/squashfs-root
The files you I looked for are in
/tmp/squashfs-root/usr/bin/rtk_hciattach
/tmp/squashfs-root/usr/lib/kernel-overlays/base/lib/firmware/rtl_bt/rtl8723b_fw
/tmp/squashfs-root/usr/lib/kernel-overlays/base/lib/firmware/rtl8723b_config
The path is different than yours because in my case Im looking into the pre-boot system files.
So, as patch until next release, what about if I include that files in the squashed filesystem of 9.2.2 instead copying at boot?
Of course also masking 9.2.2 rtkbt-firmware-aml startup script and adding /bin/rtk_hciattach execution at startup …
Apologies if I got the paths wrong, you could certainly do this as a workaround if you have the knowledge.
A lot of work for an ageing system. 
@anon88919003 sounds good. Will it make it into the nightlies?
And yes I guess it is a bit of effort but s905x with 3gb ram is still perfect for Kodi no issues at all.
I’m not opposed to upgrading though but in this case I think it’s a fixable issue. Can you link the PR that reverts the change?
I haven’t had a chance to look yet busy ‘working’ at home during a pandemic with a kid running around but I’m sure it’s possible to make the build support both methods and choose at boot up which loader/firmware to use. If you link the PR or I track it down on GitHub I’ll have a look.
The changes are already live in our GitHub, I have reverted the driver changes just for older devices without affecting newer ones.
@adamg Uh? Did you already done the job?
But how it is possible to patch an already upgraded 9.2.2 system from github?
Maybe I’m good to un-squash and re-squash filesystem, but I’m a disaster in pull’n’roll projects from GitHub 
Can someone help me with a little step-by-step how-to?
@juggie are you able to setup remote access to one of your devices so I can see if this still an issue or not and try to fix it if it is.
The latest nightly.
@anon88919003 k will do that tomorrow (Tuesday) on a spare box. I’ll pm you when done. I presume you don’t need outbound internet access and being able to ssh in and scp files will be all you require?
Well I will need to be able to pull changed files in.
About | FAQ | Terms of Service | Privacy Policy | Legal Notice