I have an H50-labeled tv box with a different board (T98-3318-V2.3) but with exactly the same problem - no HDMI even though all the software debug traces show that everything video-related gets called and works. I first tried to make it work 5 years ago and failed and a few months ago I revisited it just to see if I can make it work now in the age of AI. I made a really deep dive into reverse engineering it. I rooted the original Android firmware and dumped anything I could, extracted and analyzed with Ghidra the vendor u-boot and kernel (wasn't particularly helpful) and finally managed to execute the u-boot binary in Renode by emulating a lot of hardware stuff with code or by simply replacing functions with successful returns all the way to the point of u-boot displaying the splash screen and with various hooks and warnings about peripheral accesses I collected a comprehensive trace of everything that u-boot was doing, and in that trace, the AI noticed a certain GPIO access and suggested replacing this vcc-host-vbus { compatible = "regulator-fixed"; enable-active-high; gpio = <0x74 0x00 0x00>; pinctrl-names = "default"; pinctrl-0 = <0x76>; regulator-name = "vcc_host_vbus"; regulator-always-on; regulator-min-microvolt = <0x4c4b40>; regulator-max-microvolt = <0x4c4b40>; vin-supply = <0x77>; phandle = <0x100>; }; with this vcc-display-en { compatible = "regulator-fixed"; gpio = <0x74 0x00 0x01>; pinctrl-names = "default"; pinctrl-0 = <0x76>; regulator-name = "vcc_display_en"; regulator-always-on; regulator-boot-on; regulator-min-microvolt = <0x4c4b40>; regulator-max-microvolt = <0x4c4b40>; vin-supply = <0x77>; phandle = <0x100>; }; in the standard rk3318-box.dts which made HDMI work.

Even more confusing the file on the disk, written with armbian-imager is a text file, looks like an apt sources file: > file /mnt/boot/vmlinux-6.18.21-edge-mvebu64 /mnt/boot/vmlinux-6.18.21-edge-mvebu64: ASCII text, with very long lines (1483) > head /mnt/boot/vmlinux-6.18.21-edge-mvebu64 com/daniel-casanueva/haskell/graphviz Description-md5: bd02d2c14f791ffca367313e1957b329 Ghc-Package: graphviz-2999.20.2.0-JKUYtUkvYwE3GbOspxTTfB Section: haskell Priority: optional Filename: pool/main/h/haskell-graphviz/libghc-graphviz-dev_2999.20.2.0-1+b1_arm64.deb Size: 3696512 MD5sum: 36c93a1f30f0234eadffbf9ae0d2336b SHA256: 5b95053c25c02020e9eca717df070591259432e5c125435f5514761417bc8879 The built file looks fine: 1348921 717100 -rw-rw-r-- 1 root root 734305912 Apr 7 17:45 ./cache/sources/linux-kernel-worktree/6.18__mvebu64__arm64/vmlinux.o > file ./cache/sources/linux-kernel-worktree/6.18__mvebu64__arm64/vmlinux.o ./cache/sources/linux-kernel-worktree/6.18__mvebu64__arm64/vmlinux.o: ELF 64-bit LSB relocatable, ARM aarch64, version 1 (SYSV), with debug_info, not stripped

When trying to rebuild the kernel, the image is not taking the updated kernel image: ./compile.sh BOARD=espressobin CLEAN_LEVEL=make-kernel RELEASE=trixie ..... -rwxrwxr-x 1 root root 296665952 Apr 7 16:47 vmlinux.unstripped -rw-rw-r-- 1 root root 220926 Apr 7 16:47 modules.builtin.modinfo -rw-rw-r-- 1 root root 16667 Apr 7 16:47 modules.builtin -rwxrwxr-x 1 root root 296215160 Apr 7 16:47 vmlinux drwxrwxr-x 23 root root 12288 Apr 7 16:47 kernel/ drwxrwxr-x 79 root root 12288 Apr 7 16:47 fs/ drwxrwxr-x 5 root root 36864 Apr 7 16:47 crypto/ drwxrwxr-x 22 root root 20480 Apr 7 16:47 lib/ drwxrwxr-x 27 root root 4096 Apr 7 16:47 sound/ drwxrwxr-x 23 root root 12288 Apr 7 16:47 scripts/ $ armbian-imager # installed the new image... 16:55:21 ● custom_image: Check decompression for /srv/development/espressobin-ultra/armbian-build/build/output/images/Armbian-unofficial_26.05.0-trunk_Espressobin_trixie_edge_6.18.21.img: false 16:55:21 ● operations: Starting flash: /srv/development/espressobin-ultra/armbian-build/build/output/images/Armbian-unofficial_26.05.0-trunk_Espressobin_trixie_edge_6.18.21.img -> /dev/sdb (verify: true) 16:55:21 ● flash::linux::writer: Starting flash: /srv/development/espressobin-ultra/armbian-build/build/output/images/Armbian-unofficial_26.05.0-trunk_Espressobin_trixie_edge_6.18.21.img -> /dev/sdb 16:55:21 ● flash::linux::writer: Image size: 2252341248 bytes (2.10 GB) 16:55:21 ● flash::linux::writer: Unmounting device partitions... 16:55:21 ● flash::linux::writer: Writing image... 16:55:27 ● flash::linux::writer: Write complete: 2148.0 MB in 5.4s (avg 398.9 MB/s) 16:55:27 ● flash::linux::writer: Starting verification... 16:55:27 ● flash::verify: Starting verification of 2252341248 bytes (2.10 GB) 16:55:32 ● flash::verify: Verify complete: 2148.0 MB in 4.9s (avg 441.9 MB/s) 16:55:32 ● flash::linux::writer: Flash complete! 16:55:32 ● operations: Flash completed successfully 16:55:32 ● custom_image: Deleting decompressed custom image: /srv/development/espressobin-ultra/armbian-build/build/output/images/Armbian-unofficial_26.05.0-trunk_Espressobin_trixie_edge_6.18.21.img 16:55:32 ● custom_image: Attempted to delete file outside custom-decompress cache: /srv/development/espressobin-ultra/armbian-build/build/output/images/Armbian-unofficial_26.05.0-trunk_Espressobin_trixie_edge_6.18.21.img $ sudo mount /dev/sdb1 /mnt/ $> ls -ltr /mnt/boot/vmlinux-6.18.21-edge-mvebu64 -rw-r--r-- 1 root root 36108800 Apr 3 18:36 /mnt/boot/vmlinux-6.18.21-edge-mvebu64 When booting: [ 0.000000] Booting Linux on physical CPU 0x0000000000 [0x410fd034] [ 0.000000] Linux version 6.18.21-edge-mvebu64 (build@armbian) (aarch64-linux-gnu-gcc (Debian 14.2.0-19) 14.2.0, GNU ld (GNU Binutils for Debian) 2.44) #1 SMP PREEMPT Thu Apr 2 07:23:33 EDT 2026 [ 0.000000] KASLR enabled

If you want snapshots, you can also do it on filesystem level. Look at Btrfs and snapper. While testing HA 2 years ago, I also took the Intel VM image and made it work in a libvirt VM on an Atom J1900 board. Default size was 32G I think, way too big IMO. So I also took a clone of an existing Debian aarch64 VM (runs on RK3588 or BCM2711) and installed HA in there with supervisor method. I use Btrfs as filesystem, so do not take snapshot of VM image, but just Btrfs snapshot of the rootfs in that VM with HA. Also use Zstd compression, so much smaller than that 32G. But as a matter of fact, HA has good internal backup-restore, so that is also very useful, especially moving between Intel HA en Arm HA.

Dear eselarm, thank you for clarification! Really sad that there's no proper arm support yet. VM is really handy using snapshots.