This kernel does not come from radxa but from Rockchip themselves as BSP. However we put lots of work on top of that:https://github.com/armbian/linux-rockchip
This will basically be a thing until mainline catches up. Though there will be a few years to go in that matter.
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
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.
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.
Hi
Providing logs with
PASTE_SERVER_HOST=paste.armbian.de armbianmonitor -u
helps with troubleshooting and significantly raises chances that issue gets addressed.
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.