Werner

Armbian does not accept new boards for official support unless there is funding involved. However anyone from the community can step up and add it as community-supported.

Providing logs with armbianmonitor -u helps with troubleshooting and significantly raises chances that issue gets addressed.

Very good. First make sure you are actually having the 5B and not the 5 model. The reason I'm asking is in the logs is always model 5 and not 5B as supposed to. Did you adjust the dtb to use 5b one just like mentioned at the download page?

Hm that should not be a BIG issue since H2+ and H3 are quite similar, just a few features were stripped IIRC. I don't know for their images but I assume there is something similar like Armbian has. Edit /boot/armbianEnv.txt and set verbosity to 7 to increase the output of the kernel while it is starting. So you may know why it is stuck. Overall I'd recommend to try some older images like https://fi.mirror.armbian.de/archive/nanopiduo/archive/ or https://fi.mirror.armbian.de/oldarchive/nanopiduo/archive/ and then bump kernel step by step via armbian-config to know where it starts failing.

There is usually only one or two images built per board. That's enough to make sure it compiles properly. All other combinations can be made DIY with the framework, check documentation. Continous Integration https://en.wikipedia.org/wiki/Continuous_integration

Our CI produces automated builds which are published here: https://github.com/armbian/community/releases If a build fails we will notice and fix if it doesn't much effort. Otherwise it's demoted to EOS and autobuilds disabled.

Yes, csc boards are not actively monitored. Build test only.

moved

Alright, let's give a real quick overview where the code for A20 comes from. Let's focus on current. First stop. Board config: https://github.com/armbian/build/blob/main/config/boards/bananapipro.csc -> BOARDFAMILY="sun7i" Next stop. Family config: https://github.com/armbian/build/blob/main/config/sources/families/sun7i.conf -> No sources defined. However there are includes. Next stop. Includes: https://github.com/armbian/build/blob/main/config/sources/families/include/sunxi_common.inc -> No kernel source URL defined. Therefore kernel comes from mainline (kernel.org to say). However a version is tagged: v6.12.43 So we know: Linux source comes from unmodified mainline and the version is 6.12.43 Next stop. Patches: https://github.com/armbian/build/tree/main/patch/kernel/archive/sunxi-6.12 -> vendor family = sunxi, kernel major.minor is 6.12 All these patches are applied on top of the kernel source from kernel.org. And yes, that's a lot. I think sunxi is the worst family regarding number of additional patches to make stuff work. Next component is u-boot. https://github.com/armbian/build/blob/main/config/sources/families/include/sunxi_common.inc -> BOOTBRANCH:-"tag:v2024.01" so uboot is tagged to this version. So we know: U-Boot source comes from unmodified mainline and the version is v2024.01. And BOOTPATCHDIR="${BOOTPATCHDIR:-"u-boot-sunxi"}" which means here we find the patchset put on top of that version. Let's check. https://github.com/armbian/build/tree/main/patch/u-boot/u-boot-sunxi -> folders starting with board_ are applied only if the target board is being built. All remaining paches are always applied. There are more definitions of stuff appling for multiple families, whole architectures or even all boards regardless of architecture but in this case they are not important. Just including for the sake of completion/information: https://github.com/armbian/build/blob/main/config/sources/armhf.conf https://github.com/armbian/build/blob/main/config/sources/common.conf Good luck.

What's wrong with just using the curl command? It will upload the logs to one of our paste servers and it will be nicely formatted and colorful. Way easier to read.

Excerpts are often useless. Provide full logs using the curl command from the end of each run. If the used hardware isn't very powerful, yes, can be.

Kobol went out of business years ago. I don't think you will be able to find replacement parts.

Forum moderatores are there to provide guidance in discussion and take action if things get out of control. Having a wide varity of knowledge in various areas is desireable but not mandatory. As for myself I did not know about that either.

moved to userspace

RPi added some checks in their initramfs post-update script which causes this, found here: /etc/initramfs/post-update.d/z50-raspi-firmware: case $flavour in v8|v8-rt|2712|v6|v7|v7l) ;; *) echo "ERROR: Unsupported initramfs version ($initrd_version)" exit 0 ;; esac However there is also another fine in this folder which was added years ago: https://github.com/armbian/build/pull/6039/files#diff-02b9b6fbb77fcab23278cd4a148b3f2c91d2c1361d05f33a21bdab19182caf21R139-R153 That seems to handle initramfs creation properly. So the error message is purely cosmetical. That would give trouble when updating rpi packages from upstream since there would be changes detected. Better solution might be to add a hint to our code stating that the ERROR can be ignored as long as overall initramfs generation was successful.