Igor

If this worked for you, I propose to open a PR, so there is a GitHub record of your work. Add it here https://github.com/armbian/build/tree/main/patch/kernel/archive/sunxi-6.12 Here you also need to pay attention to add to series* files.

Not supported by forum software. Keeping Facebook and Google operational requires constant attention and adjustement, while others worked so far without troubles.

Added instructions for joining your home lab: https://docs.armbian.com/WifiPerformance/#adding-a-new-device

FYI. HDMI out is broken on those board at the moment. Try to access the board remotely. We don't have people to maintain those old boards.

True. Also on most computers we have eth0 Not just eth Devices naming is a cosmetic thing from the outside / user perspection, while it has consistency issue from the inside and currently breaks initial (default netplan) configuration. Our job is not to tell user how to configure his network, but that network devices gets up at first boot. Now they do. Job done.

I just found one weird setting on R6S. Can you provide what is in this file: cat /etc/udev/rules.d/70-persistent-net.rules Reference for what to do: https://github.com/armbian/build/pull/8325

From the picture - I can only guess that kernel package was somehow not upgraded properly as kernel image files are missing. Perhaps they were removed by accident or there was some disk / file system troubles involved. @Chris007 Try hints from here: https://docs.armbian.com/User-Guide_Troubleshooting/

To be more precise - parameters that are provided to that driver. If driver would be the problem, both NICs would be down. You need to find / create correct settings (device tree), based on schematics. This forum (search) can provide plenty of resources and hints how to do this. Someone from community (with the device so testing can be done) has to sacrifice afternoon or more to get this in operation.

With logs, we could see if this is NIC not recognized or network stack problem. Community supported target are often not having anyone behind https://docs.armbian.com/User-Guide_Board-Support-Rules/

It's a progress! This or similar problem was seen / reported on H3 too.

It is possible that broken patch removal is already a solution.

They will provide you new drivers only if you will pay them to do that for you. End users, including this project, can do nothing about - we have negative budget and can only do best-effort work to keep those drivers at least operational with recent kernels: https://github.com/armbian/build/tree/main/patch/misc while bulk of the patches goes directly to the Git of specific driver. What you are hoping exceeds ability of amateur maintainers, those few people that are actually looking into the code and fix bugs that are made by kernel API changes. HW vendor is usually long gone from there - their development capacity is also limited and they are focused into current products. FYI

A10 / A20 hdmi support was reported as broken and bug was recorded https://armbian.atlassian.net/browse/AR-2674 some time ago.

Here some troubles are expected ... Can you try manual steps to install docker by follow: https://github.com/armbian/configng/blob/main/tools/modules/software/module_docker.sh#L26-L56 installing packages, adding to group, adding docker bridge. This might reveal more. BTW. My F3 died - waiting for replacement.

Actually its the opposite so it must have been something else. Etcher is known to be broken for bigger images (desktops). There is some bug in the .xz decompression method used by Etcher. I am using only USB imager for at least a year and haven't run into any problems. At least not on this level.

Images were tested. Do you perhaps use Etcher for flashing? And try minimal image. That might even work with Etcher.

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.