Generic aarch64 or x86 image has all needed support for most comon virtual environments. On a side we provide cloud images, optimized to run inside KVM / QEMU virtualized environment - super lean kernel. https://armbian.com/boards/uefi-arm64 https://armbian.com/boards/uefi-x86 Look for cloud kernel images. Here it can only be a problem if host (Orangepi) supports qemu or not. I don't run it here but I am sure it works well. There won't be any difference. Armbian is more polished in general. Securing support for virtual targets is relatively easy compared to any custom hardware. And this was done long time ago. We use Armbian UEFI and QCOW2 virtual images for automated testing, but of course we target KVM / Quemu not Virtualbox. Which anyway can run normal image. Our runners and cloud services mainly run Armbian Noble cloud. Our website (dual core x86 vps): www:/boot:% du -h vmlinuz-6.18.10-cloud-x86 15M vmlinuz-6.18.10-cloud-x86

Running VirtualBox on Armbian is generally not a good fit for what you’re trying to do. Armbian is primarily designed for ARM-based single-board computers, and VirtualBox is built with x86 hosts in mind and relies on kernel modules that are not well-supported (or sometimes not available at all) on ARM kernels like the one in your chosen Armbian image. Even if you manage to install the package, it’s very likely you’ll run into missing kernel module issues or lack of hardware virtualization support, especially on boards like the Orange Pi 5 Plus. If your goal is to run Home Assistant without containers, a more reliable approach would be to either run Home Assistant OS directly on supported hardware, or use a lightweight hypervisor that works well on ARM (such as KVM/QEMU, if your board and kernel support it). Alternatively, if you specifically want VirtualBox, you’ll have a much smoother experience running it on a standard x86 Debian/Ubuntu system rather than Armbian.

After that kernel boots normally and UART stops printing logs. Kernel, btw v6.18, can see and enumerate NMVe SSD, and mount root. $ lspci 0004:40:00.0 PCI bridge: Rockchip Electronics Co., Ltd RK3588 (rev 01) 0004:41:00.0 Non-Volatile memory controller: MAXIO Technology (Hangzhou) Ltd. NVMe SSD Controller MAP1202 (DRAM-less) (rev 01) $ ls /dev/nvme* /dev/nvme0 /dev/nvme0n1 /dev/nvme0n1p1 /dev/nvme0n1p2 Not sure what firmware you are referring to. I have u-boot-rockchip-spi.bin flashed to SPI flash by armbian-config, while boot dir (including kernel, dtb, etc.) stays in SD card to workaround booting issue and whole rootfs at NVMe SSD. I still think this U-boot NVMe related issue. Apparently NVMe support in U-Boot is enabled but "nvme scan" failed enumeration.

@Dalibor Pospíšil I haven't tested if the pcie works, maybe others did? But it's a bsp driver so it should. If that works, and if the SATA device has a driver in Linux 6.18, simply enable it in menuconfig and you should be good to go. EDIT: Right, I don't have A7A so I didn't really touch the dts for A7A, there might be a little works needed for it to boot.

@alexc What about SATA support? The a7a board has m.2 pcie where the PentaHAT can be attached (I tested it with a custom sunxi kernel).