Werner

Not sure if it is possible to use a local kernel source directory. At least I don't know how to do that. Easiest is probably just to create a repo and define url and branch in board your custom board config.

openssh-server should be installed by default on all images/configurations.

Same answer as above. Without serial logs impossible to debug. It leaves to mention that this board is not officially supported but configuration has been provided by a community effort. Board status is unknown to the core Armbian team.

moved

Rufus was never tested nor recommended. https://docs.armbian.com/User-Guide_Getting-Started/#deploy-the-image

Hi Providing logs with PASTE_SERVER_HOST=paste.armbian.de armbianmonitor -u helps with troubleshooting and significantly raises chances that issue gets addressed.

Have you tried installing qemu-user-static package manually and retry?

Tried a few hours later? Alternativly you can choose a fixed mirror from here: https://docs.armbian.com/Mirrors/

I don't know particular about this board so I can only give generic clues and hints how to help us helping you. What kind of dependencies you mean? There is uboot only. For variables and boot script check the contents of /boot Power loss is not an issue. Most that can happen is corrupted rootfs.

There are for once some inconsistencies in terms of prefixes across various soc families and for the other configng isn't perfect (yet ). Feel free to share your issue at its repository: https://github.com/armbian/configng/

Try setting ZRAM_PERCENTAGE=50 where 50 would be half of available memory. Not sure if the builder picks this up. If it doesn't I'd go the customize-image.sh route and use this to modify the /etc/default/armbian-zram-config file just before assembly closure.

Hm if an image works but self-made won't either means something has been messed up which I doubt since it fails at uboot level. Or a change in the code broke it in the mean time. Also interesting that kernel building fails when RKNPU is a module rather than built-in. I guess that goes to poor implementation on Rockchip's side. Which exact pre-built image did you test that works well? This is quite old. We had a few version bumps in the mean time. More recent vendor kernels should already contain 0.9.8 What you could also try is to integrated the most recent patch series for mainline npu driver into edge kernel: https://patchwork.kernel.org/project/linux-rockchip/cover/20250519-6-10-rocket-v4-0-d6dff6b4c0ae@tomeuvizoso.net/

Yes, DB9 won't work. But if, as eselarm mentions, a proper chip is on board already a simple usb-a to usb-c or c-to-c cable should do. Check dmesg when connection to see what pops up.

These things can happen, yes. Sometimes old vendor-style uboot cannot process a modern mainline kernel and vice versa. Glad to hear it worked well this time.

No worries. Everyone here started small edge and vendor are Armbian terms for kernel branches just like current. You guessed correct, edge is bleeding edge and usually follows latest mainline kernel (6.14.y today). vendor is based on Rockchip BSP kernel which is 6.1.y at the moment. While a bit out of date most hw functions work here. current usually follows latest available LTS mainline kernel. As you're a beginner and most likely just want things to work I suggest to try a vendor kernel based image first.

Support for the rk3588 soc is quite rudimentary in this LTS kernel. Also most likely the opp nodes are missing just like most other hw features. I suggest to use either vendor or edge for now.

Cannot reproduce test@orangepi5-plus:~$ cat /sys/devices/system/cpu/cpufreq/policy0/scaling_available_frequencies 408000 600000 816000 1008000 1200000 1416000 1608000 1800000 test@orangepi5-plus:~$ cat /sys/devices/system/cpu/cpufreq/policy6/scaling_available_frequencies 408000 600000 816000 1008000 1200000 1416000 1608000 1800000 2016000 2208000 2256000 2304000 2352000 2400000

If a kernel package exists as artifact in oci cache it will be downloaded and used. Only if there is no artifact it will be built from scratch. After a new kernel version is released it may take a few days until oci catches up. However once locally built it will also be cached locally so it will be re-used if you start another build.

This is not uncommon. Very few boards have hdmi support at boot level since developing this feature is expensive and simply not worth since the console output is also available via debug serial console where adapters for those are dirt cheap. To get an idea what happens inside you have to grab these logs and provide them. https://debug.armbian.de

$ xz -t Armbian_25.2.1_Khadas-edge2_noble_vendor_6.1.99_gnome_desktop.oowow.img.xz $ echo $? 0 Check your download. Probably corrupted.

Some chips that support 1.5Mbaud and more: - FT232R - CH340G - CP2104

No logs - no issue. https://debug.armbian.de

I think it is this script: https://github.com/armbian/build/blob/main/packages/bsp/common/usr/lib/armbian/armbian-resize-filesystem There might be a switch or option to prevent resize, need to check documentation. Or do manually after expansion: https://unix.stackexchange.com/questions/656836/how-do-i-shrink-a-partition-right-after-shrinking-its-filesystem-with-resize2fs

Issues with the build framework, building Armbian to say, should be reported in the framework repository. https://github.com/armbian/build/ Make sure you include full logs. Use the curl command at the very and of the process or use SHARE_LOG=yes as build switch. Otherwise report might be rejected.

I guess the image with Gnome already built-in ships some extra package that makes this work or has some tweaks. Latter are obviously missing when installing from standard packages. You have to dive into the code where tweaks are applied and/or into package lists. https://github.com/armbian/build