Igor

Just FYI why images are delayed. GitHub, which we rely our build infrastructure on, is having many troubles and builds does not start due to out of (their) resources (probably). 30 out 30 tries, I am getting Error: Error 504: We couldn't respond to your request in time. Sorry about that. Please try resubmitting your request and contact us if the problem persists. Perhaps this is a limitation of free tier, dunno.

You can try on actual machine by editing device tree file. (/boot/dtb/rockchip/name.dtb probably rock5b something) https://chatgpt.com/share/684bbac2-2728-8005-bb50-a2751316ac2b If similar changes work - you need to reboot to apply changes - then report here.

Those builds are made by automation, once per week if nothing else goes wrong.

Perhaps same bits are missing in 5b device tree? https://github.com/armbian/build/blob/main/patch/kernel/archive/rockchip64-6.12/rk3588-1020-Add-HDMI-and-VOP2-to-Rock-5A.patch If you get it working, make a patch and push it here: https://github.com/armbian/build/tree/main/patch/kernel/archive/rockchip64-6.12

Unable to reproduce. Probably date and time is out of sync. Edit: aha, this is / was the problem: https://github.com/armbian/build/commit/aa5526a9189097b87ada0784cff61bda85e46609 Which means next week community build will have this auto-fixed.

Me too. I was not paying attention to this due to dealing with many non technical things in past few months and as already mentioned, those upgrades are not being tested on older boards. We simply don't have enough resources, test automation is limited - HDMI is not tested in any case. There is more or less just one main person doing general maintenance on Allwinner with occasional help of random people. 6.14 is already EOL and we just switched to 6.15 (EDGE branch), but we will probably stay on stable CURRENT branch with 6.12.y for awhile as its fairly stabilized in general across several platforms. IMO it is best to backport this patch for 6.12.y or fix whatever breaks this.

I have noticed regression on A20, probably also on A10 few weeks ago ... but so far we haven't been able to do anything - almost no active developer have those boards. ... and Welcome!

Welcome! This question is a bit off topic here as general Armbian updates are not part of HA extension. As this is community supported hardware, stable BSP upgrades - where OS version is stored - might not be generated, while kernel and everything else is getting upgrades. tl;dr; Don't worry about this. For board related topics proceed here https://forum.armbian.com/forum/173-allwinner-sunxi/

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.