Werner

Feel free to pr any missing overlay here: https://github.com/armbian/linux-rockchip

moved to csc https://docs.armbian.com/User-Guide_FAQ/#why-no-universal-image tl;dr: You are using the wrong image. Get/build one for your board

current isn't ideal for any rk3588 hw anyway due to lack of hw features mainlined for now. edge or vendor working best.

Yes. This is an example of a rk3588 based board of mine: overlay_prefix=rockchip-rk3588 overlays=panthor-gpu opp-oc-24ghz The overlay names come from /boot/dtb/*/ find an overlay matching your soc and needs and enable by putting its name to overlays=. Then reboot. Having a serial console to read uboot logs can show if it has been loaded properly or in case it did not why.

Overlays can be added manually as well. Check /boot/armbianEnv.txt

Expected. current had a bare minimum of hdmi support before it became recent LTS kernel. Therefore no fixes will hit there until rollover to next LTS. Needs to be enabled. Either enable panthor overlay (the mainline panthor driver was backported to vendor kernel but is disabled by default) and install more recent mesa packages (depends on userspace). Or install proprietary mali blobs. Having or building an image with mesa-vpu extension enabled handles that for you. There is no automatic method of installing afterwards yet. https://github.com/armbian/apa/issues/20

moved

tag adjusted

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

Radxa Zero has a different soc: https://radxa.com/products/zeros/zero/ Double-check what hw you actually have

The easiest route is to simply flash it to a microsd card and boot from it. Once booted issue "armbian-install" to move the OS and boot loader to eMMC. eMMC should be accessible directly if tools like rkdeveltool or whatever that is called is used. Never used that personally, seems tricky to use. Prefer first path.

Not having correct uboot on spi can often lead to such issues. Also sometimes vendor kernel does not like mainline uboot and vice versa. This is why vendor kernel based images usually are shipped with vendor uboot which is version 2017.09 I think. Anyway glad you figured it out

I'll fix that soon Edit:done

moved since neither a review nor a tutorial. I made a writeup just a few days ago how to get an idea about how Armbian puts its kernel and uboot sources together with an example for a different board:

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.