More attempts: As suggested by DeepSeek (ChatGPT was less helpful), I also tried changing the bluetooth service script to ExecStart=/usr/libexec/bluetooth/bluetoothd --noplugin=a2dp --noplugin=avrcp --noplugin=player and then restarting systemd itself and the bluetooth service, but no luck. I tried adding monitor.bluez.properties = { bluez5.roles = [ ] } to /usr/share/pipewire/pipewire.conf and restarting wireplumber, but no luck. I tried menu advertise uuids 0x1200 0x1800 0x1801 0x180a in bluetoothctl, to disable advertising the audio profiles, but no luck. But when in bluetoothctl, it really shows the audio connection being made when the phone connects.

When I change the country and keyboard settings with armbian-config, the keyboard change from qwerty to azerty but after a reboot, the keyboard is qwerty again. The country code stay correct as set in the config.

Hi there, Ok, after some walking back and forth, typos, reboots, rewriting entire images, multiple armbianEnv.txt files, looking into U-Boot sources, googling (of course) I managed to find some things and got U-Boot on my Helios64 to boot properly again. In short, the aarch64 requirements to the linux kernel, the way U-Boot sometimes will move the loaded kernel image in memory might overwrite the starting point of the inital ramdisk. The load addresses for kernel and initial ramdisk are mostly hardcoded in U-Boot but can be overridden by armbianEnv.txt or the bootscript. As Helios64 uses Rockchip rk3399 from the aarch64 family, the attached boot.scr might also work for you. This bootscript will only work on aarch64 systems, as it assumes the kernel is uncompressed! If you test this, make sure to make a backup of your existing boot.scr or read up on how to regenerate the boot.scr from your boot.cmd. Make sure you have serial console available Copy the attached bootscript to /boot Add verbosity=1 (if not already there) to your armbianEnv.txt Reboot Would be great that if you test, to share the serial console output here to see it it also works for you. I will also test and verify on one of my Nanopi R2Ss somewhere today or tomorrow. Will put all the details into a pull request. Groetjes, Update: Removed boot.scr as testing on Nanopi R2S showed some misbehavior.

I don't know your plans for how things are supposed to proceed. But if you plan to continue using my firmware build, I would suggest transferring it to the SPI flash, provided you are not wanted to use any other firmware in there. - This relieves you from having to pay attention to restoring my firmware build when changing an image. - You have two firmware versions available to you, between which you can switch with the SPI-MMC boot switch. - Even without the eMMC module, you can boot an OS from another connected storage device. - The U-Boot console is also available with an HDMI monitor and a USB keyboard and can be used for analysis in the event of startup problems. Of course, it is also used to select various boot options if autoboot is interrupted.

Thank you that worked. Awesome, what a pitty that the plain armbian image doesn't work. Maybe this is something for a developer but not sure how to reach them.