Werner

I'd probably start with comparion the device trees of both images and check for altered/removed nodes related to audio.

Check assets at community releases as csc hw is ususally not on mirrors but on GH: https://github.com/armbian/community/releases

Seems working nicely: https://paste.armbian.com/eniduhodih

elaborate

BOARD=uefi-x86

Could you file this as bug here: https://github.com/armbian/configng

May work once rockchip64 has been bumped to 6.15 https://gitlab.collabora.com/hardware-enablement/rockchip-3588/notes-for-rockchip-3588/-/blob/main/mainline-status.md

Use BRANCH=edge. This should give you 6.14

Install code { font-family: Consolas,"courier new"; color: crimson; background-color: rgba(0, 0, 0, 0.2); padding: 2px; font-size: 105%; } qemu-user-static package and retry

If the desired image combination is not available DIY. That's the build framework made for https://github.com/armbian/build/

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.