Igor

Yes, that is the main idea, but sometimes things slipped trough. Images were tested (we aim to have two people on one platinum target to be able to provide better service, but perfection is still not possible), but here we ran into weird problem that CI compilation silently broke on u-boot recompilation, while local build works. We have a problem with build framework / compiler internals, unrelated to this specific hardware and problem only manifest on some u-boot variants. Right now, I don't have a clear picture, but we are working on it. This was introduced while moving framework to Noble, which is mandatory for some targets and there are some Python libraries troubles ... which are sometimes used for u-boot / ATF compile. Its a mess. Software maintenance within such extreme complexity is job that is never done. Generally speaking.

Yeah, it was reported at GH too: https://github.com/armbian/build/issues/8227 Probably related: https://github.com/armbian/build/issues/8269 No solution yet.

We do have 3A https://fi.mirror.armbian.de/incoming/igorpecovnik/rock-3a/archive/ (need report if this latest build works) and build config for 3C but not 3B. Does it make sense to make for 3C too or 3A can cover them all. I don't have any of those, so I can't check.

He probably meant upstream driver version v5.7.9_35795.20191128 https://github.com/jwrdegoede/rtl8189ES_linux/blob/rtl8189fs/include/rtw_version.h and by looking into Makefile it feels as we are in 2010

Welcome to submit PR here: https://github.com/armbian/build/tree/main/config/kernel Best to all those configs:

I think this is handled with overlay "audio" "analogue" or something similar. https://docs.armbian.com/User-Guide_Armbian-Config/System/#device-tree-overlays

No and we can't get new one as it doesn't exists. Common practice is that vendor drops driver sources to the wild and never look back. All costs of maintenance are on few people in and around this community and similar (volunteer based) projects that deals with Linux wireless. This chip is probably only used by few (Orangepi) single board computers and perhaps some Android tablets, TV boxes. Which are not in our focus anyway. There is some community efforts to bring such drivers to mainline code, but I doubt this chip will ever find a way there - and this doesn't mean that it will work better. Check here https://github.com/torvalds/linux/tree/master/drivers/net/wireless/realtek if there is any sign of it.

This method will keep working for years and I will try to fix problems as long as they won't take too much time. Most of Armbian images doesn't have boot partition as it is not needed. Most of boards does not support boot from flash drive, but from SD card. I have absolutely no clue. There is a whole section of Armbian community forums that are dealing with the complexity of booting weird TV box hardware. I suggest you to start here: https://forum.armbian.com/forum/189-faq/ It is enough that board uses different memory modules and device won't give any sign of life. When you manage to boot Armbian Bookworm with help from TV box section, use armbian-config.

Well, for Home Assistant, Armbian / Debian Bookworm image is required. That we usually provide for all variants, supported and not supported. Since this hardware is not actively maintained, we don't know if there are any hardware level issues related to this board. Here you are on your own, hope for / wish you luck. Usually things works ... Next step is this: https://docs.armbian.com/User-Guide_Armbian-Software/HomeAutomation/#home-assistant It will provide the same result as image with pre-loaded Home Assistant.

Welcome to Armbian forums. Most of general questions are answered in: https://docs.armbian.com/ https://docs.armbian.com/User-Guide_Board-Support-Rules/ Remove those you will get answers there ...

I would suggest you to download clean Debian minimal image and proceed this way: https://docs.armbian.com/User-Guide_Armbian-Software/HomeAutomation/#home-assistant EVCC can be installed this way - official Docker container: https://docs.armbian.com/User-Guide_Armbian-Software/HomeAutomation/#evcc How to deal with EVCC from HA, no idea. This is application level knowledge and I am just an average user of HA. I assume addon will want to connect to the service which runs on some IP address and some port. IMO this part is similar as official HAOS image. Current application images are not yet rebuild with latest stable base, so until then its better going clean Debain + armbian-config way.

I see. This package is done bad in first place. No wonder they decide to simply drop everything ... Most of people anyway use embedded HAOS. Then we should not adding updated packages to the repository anymore.

Thank you for reporting. If current images have troubles, you can try to use previous ones. There is a link on the download pages or you can find them this way. https://forum.armbian.com/topic/52406-helios-64-fails-to-boot-since-upgrading-to-bookworm/#comment-219614 Which works best for your case, you will need to find on your own. We don't store this information / forum search might help. Similar goes with 3rd party images - most are Armbian based and none is in perfect state, things break apart all the time. By providing logs (if possible) someone might give you hints to workaround the problem, without hardly. As I understand from your report - image boots, but USB port doesn't work to enter password? And also network is down, so you can't login remote. I haven't tested HC4 on last builds, but C4 works just fine. In any case, fixing the problem can take some time - Hardkernel never supported our work, so we don't have active maintainer at stand by. It depends on volunteers that read this forum. When they notice and found time to look into this.

What do you mean by that? Images that are currently available are still from 25.2 ... new will be created soon. But you can anyway update them standard way: apt update + apt upgrade.

Also try to fix serial console, using different cable, different terminal application, ... doing this blindly ain't best practice.