Hello, I believe @m1zfs's work on the DKMS modules is available here: https://github.com/vitalijborissow/rk3568-npu-ODROID-M1 I have spent many hours trying to get the NPU working on my ODROID-M1 (8 GB) running Armbian 26.5.1 with current kernel 6.18.x as well as edge kernels 6.19 and 7.1. I also tried building the latest Armbian image from source (July 19 build including U-Boot 2026.07), but so far I have not been able to get the device tree / overlay and DKMS modules from the repository working on any of these combinations. The system always fails to boot. Fortunately, I can capture the boot process through the serial console and see where it fails. The log shows a kernel exception related to enabling the RK3568 NPU power domain: rockchip-pm-domain fdd90000.power-management:power-controller: failed to get ack on domain 'npu', val=0x1ee platform fde40000.npu: Adding to iommu group 3 Internal error: synchronous external abort ... Workqueue: pm genpd_power_off_work_fn ... rockchip_pd_power From the log it appears that the crash occurs before rknpu.ko is loaded. This makes me believe the issue is more likely related to the device tree, overlay, power-domain, regulator, or clock configuration rather than to the DKMS module itself. Has anyone seen a similar issue on recent Armbian kernels, or can suggest a direction for further troubleshooting? I am still willing to spend some time investigating this and would appreciate any ideas or hints.

OK great that you got it working now! 2GB RAM works fine for HA, at least when running Supervised. I am not sure if Armbian can improve more when Supervised, as this is not supported anymore from the providers/developers of Home Assistant. I think a reason people go from SBC to Intel NUC is because there are things like VMware that IT pros might know from their profession/company. And RPL very long by default had/advised to use 32-bit also on more capable devices like RPi4 with 2GB RAM or even more. And also running from SD-card, and those wear out under high load and many writes. The whole problem with 'traditional RPi' is that it is unusual 32-bit ARMv6 build and not the standard 32-bit ARMv7 which is the minimum for support from Debian and most other distros. And in addition, 32-bit builds do not support the standard Linux Kernel Virtual Machine HW, standard in all 64-bit capable CPU's. Intel/AMD CPU's have support for HW virtualization also for 32-bit and much more known and commercial (also closed-source) hypervisors like VMware are pushed a lot more then the standard Linux build-in QEMU/libvirtd/KVM. So with 64-bit Linux, especially also on ARM, you get it by 'apt install virt-manager' and then you can run other OSses/images at full HW speed and is separated from the host OS, e.g. Armbian. Because images, many files or bigger databases are a burden for simple SD-card. Also because multiple OSses at the same time, it easily needs more RAM than the usual 1GB on SBC's like RPI3. Via virt-manager GUI and also CLI tool virsh, you can then run the generic UEFI bootable HAOS. For long-term and decent 24/7 operation, you will need SSD for storage. RPi's don't have that, you need adapters and HATs etc. But many other SBC's do have, so if you have an unused NVME for example, it fits perfectly in RK388 boards like ROCK5B for example. It is 4-lane PCI-E v3, so similar speed as Intel miniPC's. And most important, lower power consumption for similar total system price, at least before the RAM+storage prices went sky high. I measured my NanoPi-R6C with Samsung 970 NVME and Armbian Trixie (6.1.115 kernel) and is about 1.5 Watt when idle or doing some light tasks like running simple initial HAOS as Virtual Machine. See also:

You are not the 1st to do this: Let me explain the problem first. The CPU itself, without any storage attached, has a built-in U-Boot. However, this U-Boot does not initialize video output, so you won't be able to see it on an HDMI screen. (The good news is that it usually initializes the serial port.) This U-Boot reads environmental data from a data blob on the MMC (usually within the first 10 MB of the disk). This environmental data tells the U-Boot the sequence of commands needed for the MMC/USB U-Boot to boot. Once the MMC/USB U-Boot boots, you get video output. The problem is that you deleted the data blob containing the environmental data from the MMC, so the CPU's U-Boot does nothing. It just loops, saying that it found no device to boot. If you have a serial adapter, it is possible to interact with this CPU U-Boot. Pressing Ctrl+C (in a terminal that does not intercept Ctrl+C—my advice is to use PuTTY, even on Linux) should stop whatever it is doing. By interacting with this CPU U-Boot, you can instruct it how to boot your MMC or USB U-Boot. However, you will have to do this manually every time you boot. To fix the issue, you need to restore that data blob containing the properties to its specific location on the MMC. I don't know where it starts or what format it uses, so I was unable to recreate one from scratch. My way of fixing this was to find a backup of the original MMC and restore the first GB. So, did you make a backup? If yes, you can restore it with some serial magic. If you did not make a backup, you can search for one or ask someone who has one. (check that this thread for the other guy's solution)

wifi works fine on our rock 5B+ board with the 6.18 Gnome build...

Yes. commit 6df6d0d607abfd59169a0ef2fddbed5fcd5b58f9 Author: EvilOlaf <werner@armbian.com> Date: Thu Feb 26 18:09:38 2026 +0000 rockchip64: 7.0: Rebase on top of main diff --git a/patch/kernel/archive/rockchip64-6.19/0000.patching_config.yaml b/patch/kernel/archive/rockchip64-7.0/0000.patching_config.yaml similarity index 100% rename from patch/kernel/archive/rockchip64-6.19/0000.patching_config.yaml rename to patch/kernel/archive/rockchip64-7.0/0000.patching_config.yaml diff --git a/patch/kernel/archive/rockchip64-6.19/add-board-helios64.patch b/patch/kernel/archive/rockchip64-7.0/add-board-helios64.patch similarity index 100% rename from patch/kernel/archive/rockchip64-6.19/add-board-helios64.patch rename to patch/kernel/archive/rockchip64-7.0/add-board-helios64.patch :