Igor

Totally undestand, just I probably know less then you about those things ...  mpv is the king, I know that. But most people don't and they will keep asking why VLC, Totem or whatever player doesn't support accelerated video. Every SoC family has its own tricks to get this working ... 

On prebuild images we test video acceeleration within Chromium and it works. Both kernels, Ubuntu Noble / Resolute Gnome, same good or bad on all boards. Others userspace combo might not work and other/all video players we don't even try to cover. Our job is done, when at least one method works OOB.
 
 
It was integrated. This is not needed anymore. For overlay, I don't know. I think its still needed and it that case, its certanly present. On kernel, where this is needed.

Hello to regular contributors and everybody who are interested in this issue!
I am late to the thread, as I had to decommission my production setup based on Espressobin V5 before trying everything out. Finally I've completed Physical-to-Virtual migration using QEMU and made board available for this new experience.

@bschnei made a great job and his developments are community available. It was also worth for me making my findings accessible for general public thus improving Espressobin support.   

I forked @bschnei repo
https://github.com/bschnei/ebu-bootloader
to my Github
https://github.com/quiseleve/espressobin-bootloader 

and made several changes to build bootloaders for Espressobin V5 and V7.

Here are the final changes brought to @bschnei repo :
root@nanopi-r5s:/mnt/nvmep2/espressobin/ebu-bootloader# git remote add upstream https://github.com/bschnei/ebu-bootloader.git
root@nanopi-r5s:/mnt/nvmep2/espressobin/ebu-bootloader# git fetch upstream
From https://github.com/bschnei/ebu-bootloader
 * [new branch]      main       -> upstream/main
root@nanopi-r5s:/mnt/nvmep2/espressobin/ebu-bootloader# git diff --stat upstream/main...main
 .github/workflows/build.yml                   | 92 ++++++++++++++++++++++++++++++++++++++++++---------------------------------
 Makefile                                      |  2 ++
 patches/0001-fix-tfa-fip-build-behavior.patch | 36 +++++++++++++++++++++++++++++
 3 files changed, 90 insertions(+), 40 deletions(-)

This allowed building bootload firmware directly in Github's Workflow and trying them out over UART 1st before flashing it to onboard SPi.
./mox-imager -D /dev/ttyUSB0 -b 3000000 -E flash-image-v5_2GB.CPU_1000_DDR_800.bin

Although Workflow run builds both v5 and v7 variants, I tested 2Gb RAM v5 board, as my 1Gb v7 is currently in production, but there is a high confidence level, that v7 works as well.
DDR_TOPOLOGY variable used for my specific v5 motherboard :
Memory Type: DDR3
Total Capacity: 2 GB
Bus Width: 16-bit
Chip Selects (CS): 2 (Dual CS)

It is worth saying that I built initially the 1.2GHz bootloader, but it appeared worthless, as my physical silicon turned out to be limited to 1GHz only. I found it by retrieving a 32-bit hex string for v5 board :
=> md 0xd0012604 1
d0012604: 19896301                             .c..
=>
This hex string gives us the definitive answers we need.
In the Marvell Armada 3720 architecture, this specific register reads from the factory OTP (One-Time Programmable) fuses. The lower bits define the chip's official Speed Bin Index:
0 = 800 MHz Maximum
1 = 1000 MHz (1.0 GHz) Maximum
2 = 1200 MHz (1.2 GHz) Maximum
Because my board register ends in 01, my specific SoC is officially rated by the factory for a maximum clock speed of 1000 MHz (1.0 GHz).
This completely explains why the WTMI secure firmware threw the invalid voltage error when I forced a 1.2 GHz build. The chip physically lacks the factory-fused voltage calibration profile for the 1.2 GHz tier because it wasn't born as a 1.2 GHz chip.
Thus I decided changing the Build Target to 1.0 GHz.

More discussions could be found here as well :




I've also built Armbian-unofficial 26.5.2 sid image to assess overall compatibility.
Here is an excerpt from initial boot logs directly from the bootloader initiation :
TIM-1.0
mv_ddr-devel-g7bcb9dc DDR3 16b 2GB 2CS
WTMI-devel-18.12.1-f423ac6
WTMI: system early-init
SVC REV: 3, CPU VDD voltage: 1.155V
Setting clocks: CPU 1000 MHz, DDR 800 MHz
CZ.NIC's Armada 3720 Secure Firmware v2024.04.15 (Jul  9 2026 20:33:31)
Running on ESPRESSObin
NOTICE:  Booting Trusted Firmware
NOTICE:  BL1: v2.14.0(release):sandbox/v2.14
NOTICE:  BL1: Built : 20:33:33, Jul  9 2026
NOTICE:  BL1: Booting BL2
NOTICE:  BL2: v2.14.0(release):sandbox/v2.14
NOTICE:  BL2: Built : 20:33:35, Jul  9 2026
NOTICE:  BL1: Booting BL31
NOTICE:  BL31: v2.14.0(release):sandbox/v2.14
NOTICE:  BL31: Built : 20:33:36, Jul  9 2026

U-Boot 2026.04-dirty (Jul 09 2026 - 20:32:03 +0000)
DRAM:  2 GiB
Core:  48 devices, 24 uclasses, devicetree: separate
WDT:   Not starting watchdog@8300
Comphy chip #0:
Comphy-0: USB3_HOST0    5 Gbps    
Comphy-1: PEX0          5 Gbps    
Comphy-2: SATA0         6 Gbps    
SATA link 0 timeout.
AHCI 0001.0300 32 slots 1 ports 6 Gbps 0x1 impl SATA mode
flags: ncq led only pmp fbss pio slum part sxs 
PCIe: Link down
MMC:   sdhci@d0000: 0, sdhci@d8000: 1
Loading Environment from SPIFlash... SF: Detected w25q32dw with page size 256 Bytes, erase size 4 KiB, total 4 MiB
OK
Model: Globalscale Marvell ESPRESSOBin Board
Net:   eth0: ethernet@30000
Hit any key to stop autoboot: 0
MMC Device 1 not found
no mmc device at slot 1
switch to partitions #0, OK
mmc0 is current device
Scanning mmc 0:1...
Found U-Boot script /boot/boot.scr
1664 bytes read in 25 ms (64.5 KiB/s)
## Executing script at 06d00000
144 bytes read in 19 ms (6.8 KiB/s)
28134196 bytes read in 1702 ms (15.8 MiB/s)
Wrong Image Type for bootm command
ERROR -91: can't get kernel image!
37059072 bytes read in 2231 ms (15.8 MiB/s)
18537158 bytes read in 1121 ms (15.8 MiB/s)
12062 bytes read in 35 ms (335.9 KiB/s)
## Loading init Ramdisk from Legacy Image at 0a000000 ...
   Image Name:   uInitrd
   Image Type:   AArch64 Linux RAMDisk Image (gzip compressed)
   Data Size:    18537094 Bytes = 17.7 MiB
   Load Address: 00000000
   Entry Point:  00000000
   Verifying Checksum ... OK
## Flattened Device Tree blob at 06f00000
   Booting using the fdt blob at 0x6f00000
Working FDT set to 6f00000
   Loading Ramdisk to 7d940000, end 7eaeda86 ... OK
   Loading Device Tree to 000000007d93a000, end 000000007d93ff1d ... OK
Working FDT set to 7d93a000
Starting kernel ...
Loading, please wait...
Starting systemd-udevd version 261.1-2
Begin: Loading essential drivers ... done.
Begin: Running /scripts/init-premount ... done.
Begin: Mounting root file system ... Begin: Running /scripts/local-top ... done.
Begin: Running /scripts/local-premount ... Scanning for Btrfs filesystems
done.
Begin: Will now check root file system ... fsck from util-linux 2.42.2
[/sbin/fsck.ext4 (1) -- /dev/mmcblk0p1] fsck.ext4 -a -C0 /dev/mmcblk0p1 
armbi_root: clean, 28918/949664 files, 425190/3849216 blocks
done.
done.
Begin: Running /scripts/local-bottom ... done.
Begin: Running /scripts/init-bottom ... done.
Welcome to Armbian-unofficial 26.5.2 sid!
[  OK  ] Created slice system-getty.slice - Slice /system/getty.
[  OK  ] Created slice system-modprobe.slice - Slice /system/modprobe.
[  OK  ] Created slice system-serial\x2dgetty.slice - Slice /system/serial-getty.
[  OK  ] Created slice user.slice - User and Session Slice.
[  OK  ] Started systemd-ask-password-console.path - Dispatch Password Requests to Console Directory Watch.
[  OK  ] Started systemd-ask-password-wall.path - Forward Password Requests to Wall Directory Watch.
[  OK  ] Set up automount proc-sys-fs-binfmt_misc.automount - Arbitrary Executable File Formats File System Automount Point.
         Expecting device dev-ttyMV0.device - /dev/ttyMV0...
[  OK  ] Reached target imports.target - Image Downloads.
[  OK  ] Reached target remote-fs.target - Remote File Systems.
[  OK  ] Reached target slices.target - Slice Units.
[  OK  ] Reached target swap.target - Swaps.
[  OK  ] Listening on syslog.socket - Syslog Socket.
[  OK  ] Listening on systemd-ask-password.socket - Query the User Interactively for a Password.
[  OK  ] Listening on systemd-creds.socket - Credential Encryption/Decryption.
[  OK  ] Listening on systemd-factory-reset.socket - Factory Reset Management.
[  OK  ] Listening on systemd-hostnamed.socket - Hostname Service Socket.
-- Boot 3e598d120dc346829e12f836344429a1 --
Jul 11 00:11:05 espressobin kernel: Booting Linux on physical CPU 0x0000000000 [0x410fd034]
Jul 11 00:11:05 espressobin kernel: Linux version 6.12.95-current-mvebu64 (build@armbian) (aarch64-linux-gnu-gcc (Ubuntu 13.3.0>
Jul 11 00:11:05 espressobin kernel: 5:185m5:185mKASLR disabled due to lack of seed
Jul 11 00:11:05 espressobin kernel: Machine model: Globalscale Marvell ESPRESSOBin Board
Jul 11 00:11:05 espressobin kernel: efi: UEFI not found.
..
Jul 11 00:11:05 espressobin kernel: armada_37xx_wdt d0008300.watchdog: Initial timeout 120 sec
Jul 11 00:11:05 espressobin kernel: advk-pcie d0070000.pcie: host bridge /soc/pcie@d0070000 ranges:
Jul 11 00:11:05 espressobin kernel: advk-pcie d0070000.pcie:      MEM 0x00e8000000..0x00efefffff -> 0x00e8000000
Jul 11 00:11:05 espressobin kernel: advk-pcie d0070000.pcie:       IO 0x00efff0000..0x00efffffff -> 0x0000000000
Jul 11 00:11:05 espressobin kernel: advk-pcie d0070000.pcie: issuing PERST via reset GPIO for 10ms
Jul 11 00:11:05 espressobin kernel: mvneta d0030000.ethernet end0: renamed from eth0
....


This bootloader seems to deliver many if not all of its promises to name few of them:
cpu  frequency scaling is operational :

root@espressobin:~# cpupower frequency-info
analyzing CPU 1:
  driver: cpufreq-dt
  CPUs which run at the same hardware frequency: 0 1
  CPUs which need to have their frequency coordinated by software: 0 1
  maximum transition latency: 1000 us
  hardware limits: 200 MHz - 1000 MHz
  available frequency steps:  200 MHz, 250 MHz, 500 MHz, 1000 MHz
  available cpufreq governors: conservative ondemand userspace powersave performance schedutil
  current policy: frequency should be within 200 MHz and 1000 MHz.
                  The governor "ondemand" may decide which speed to use
                  within this range.
  current CPU frequency: 250 MHz (asserted by call to kernel)
 
  
Entropy and random number generation (RNG) issue seems to have been resolved
as bschnei's ebu-bootloader fork explicitly includes patches to fix this.
The ebu-bootloader patches bypass the OS entirely and tackle the problem before Linux even starts.
When Linux kernel boots, it immediately detects this perfect cryptographic seed provided by U-Boot and uses it to instantly initialize the OS-level Cryptographic Random Number Generator (CRNG).

Here are my kernel ring buffer timestamps:
root@espressobin:~# dmesg | grep -E "crng|random"
[   11.785705] systemd[1]: Starting systemd-random-seed.service - Load/Save OS Random Seed...
[   13.071384] random: crng init done
[   13.398576] systemd[1]: Finished systemd-random-seed.service - Load/Save OS Random Seed.

The bootloader and kernel working together fixed the entropy pool in exactly 13.07 seconds from the moment the Linux kernel started executing.
Because crng init done happened before the systemd service even finished writing to the disk, it proves the kernel didn't just rely on slow user-space disk jitter. The hardware security engine initialized almost immediately.
Because the ebu-bootloader fork compiled correctly patches, the underlying Trusted Firmware-A (TF-A) and the secure processor (WTMI-devel), the hardware crypto mailboxes are wide open and working perfectly the moment Linux asks for them.
You don't even need haveged or any software workarounds. Your hardware is resolving its own entropy natively in just over a second from user-space initialization!
 
U-Boot UEFI Support is out of the box as well. I am booting seemlessly both legacy OS (from my old production setup) as well as a new OS build which I used for this testbed
root@espressobin:~# cat /etc/debian_version 
forky/sid
root@espressobin:~# uname -a
Linux espressobinv5 6.12.95-current-mvebu64 #1 SMP PREEMPT Sat Jul  4 11:43:36 UTC 2026 aarch64 GNU/Linux

Rock-5c vendor builds are good.  Current is good except for audio: 
Armbian_26.5.1_Rock-5c_resolute_vendor_6.1.115_gnome_desktop
Boot from SD card - okay
Connect via ssh - okay
Ethernet iperf3 - okay
USB2 ports - okay
USB3 ports - okay
Reboot - okay
Shutdown - okay
HDMI video - okay
HDMI audio - okay
Headphone jack audio - okay
 
Armbian_26.5.1_Rock-5c_resolute_vendor_6.1.115_minimal
Boot from SD card - okay
Connect via ssh - okay
Ethernet iperf3 - okay
USB2 ports - okay
USB3 ports - okay
Reboot - okay
Shutdown - okay
HDMI video - okay

Armbian_26.5.1_Rock-5c_resolute_current_6.18.33_gnome_desktop
Boot from SD card - okay
Connect via ssh - okay
Ethernet iperf3 - okay
USB2 ports - okay
USB3 ports - okay
Reboot - okay
Shutdown - okay
HDMI video - okay
HDMI audio - FAILED
Headphone jack audio - FAILED
Bluetooth audio - FAILED

Board: Orangepi3-lts
Images:
* Armbian_26.5.1_Orangepi3-lts_trixie_current_6.18.33_minimal.img.xz
Passed tests:
* SHA-256  passed
All below testing done via wired and wireless console connection(headless)
* initial setup passed
* create main user passed
* update/upgrade check as root passed
* log in as created user pass
* update/upgrade check as the created user passed

Result: All tested images do exist, are verified, and work properly

NanoPi M5 test report for 26.5.1 vendor images
 
Board: NanoPi M5
Boot media: SD card
Kernel branch tested: vendor 6.1.115
Test scope: quick first-boot / first-login / desktop smoke test only. I mainly tested the vendor kernel images because my intended use case requires vendor kernel support, especially for NPU-related use later.
 
1. Image: `Armbian_26.5.1_Nanopi-m5_resolute_vendor_6.1.115_gnome_desktop.img.xz`
 
Result: OK
 
What worked:
 
* Booted from SD card successfully.
* Armbian initial configuration completed successfully.
* After initial configuration, the GNOME desktop started normally.
* I was able to enter the desktop and open a few basic applications.
 
Notes:
 
* I did not do a full hardware validation in this round.
* I did not collect serial logs because the image reached the desktop successfully.
 
2. Image: `Armbian_26.5.1_Nanopi-m5_resolute_vendor_6.1.115_kde-plasma_desktop.img.xz`
 
Result: FAILED
 
What worked:
 
* Booted from SD card successfully.
* Armbian initial configuration started normally.
 
What did not work:
 
* The system got stuck at the Armbian first-login / initialization screen when it was supposed to start the desktop.
* It did not proceed to a usable KDE Plasma desktop.
 
Notes:
 
* I only did a basic desktop startup test.
* I have not collected serial logs yet, but I can retest and provide logs if needed.
 
3. Image: `Armbian_26.5.1_Nanopi-m5_trixie_vendor_6.1.115_minimal.img.xz`
 
Result: CLI OK, XFCE installation failed
 
What worked:
 
* Booted from SD card successfully.
* Armbian initial configuration completed successfully.
* Login to the terminal worked normally.
* Basic CLI usage appeared normal.
 
What did not work:
 
* I tried installing XFCE through `armbian-config`, using the XFCE mid option.
* The desktop package dependencies appeared to download successfully.
* After that, the screen switched to a black screen with a blinking terminal cursor in the top-left corner.
* I waited for about 10 minutes, but it stayed stuck there and did not continue to a usable desktop.
 
Notes:
 
* The base minimal image itself seemed to work correctly from the terminal.
* The issue happened during or after the XFCE installation/startup process via `armbian-config`.
* I have not collected detailed logs yet, but I can retest and provide logs if needed.
 
Summary:
 
* `resolute_vendor_6.1.115_gnome_desktop`: boots from SD card and reaches GNOME desktop successfully.
* `resolute_vendor_6.1.115_kde-plasma_desktop`: boots from SD card, but gets stuck at the Armbian first-login / initialization screen and does not reach KDE Plasma.
* `trixie_vendor_6.1.115_minimal`: boots from SD card and CLI works, but installing XFCE mid through `armbian-config` gets stuck on a black screen with a blinking cursor.

https://github.com/armbian/build/pull/9901

Board: Orangepione
 
Testing results for the three available images.  Should there be more images available?
 
Armbian_26.5.1_Orangepione_resolute_current_6.18.33_minimal.img
Tested working:
Boot from SD card with uboot and then to a USB SSD.
Reboot
Connect via ssh
iperf3 after installing iperf3
gpio after installing gpiod
HDMI video
HDMI audio after installing mpg123
Used usb keyboard/mouse to test HDMI.
 
Note that resolute now uses gpiod for gpio instead of sys. Gpiod had to be installed whereas trixie minimal comes with gpiod installed.
 
Armbian_2Armbian_26.5.1_Orangepione_trixie_current_6.18.33_minimal.img
Tested working:
Boot from SD card with uboot and then to a USB SSD.
Reboot
Connect via ssh
iperf3 after installing iperf3
gpio
HDMI video
HDMI audio after installing mpg123
Used usb keyboard/mouse to test HDMI.
 
Armbian_26.5.1_Orangepione_resolute_current_6.18.33_xfce_desktop.img
Tested working:
Boot from SD card with uboot and then to a USB SSD.
Reboot
On HDMI connecter screen with usb keyboard/mouse
Using terminal emulatori tested perf3 and gpio
HDMI audio with vlc media player.
 
Not working:
Ran chromium to get to Armbian download page but took over a minute for each page to load and then the system crashed.
With only 512MB RAM this system is under powered for general purpose desktop use.
ubuntu_resolute_minimal.txt debian_trixie_minimal.txt ubuntu_resolute_xfce.txt

Board: MKS-Klipad50
Images:
* Armbian_26.5.1_Mksklipad50_resolute_current_6.18.33_minimal.img.xz
* Armbian_26.5.1_Mksklipad50_trixie_current_6.18.33_minimal.img.xz
Passed tests:
* gpg and sha checksum files
* boot from emmc, leds, display, touch, usb, internal wifi
* initial setup, uboot-console, reboot
Result: All expected images do exist, verify and work properly.
 
Sidenote: The Klipper ecosystem does not yet run on Ubuntu-Resolute (Python-3.14 incompatibility), but that shouldn't be a stopper for the release.

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 think it must just work.
 

There won't be any difference compared to standard Debian / Ubuntu. Armbian is more polished in general, comes with several important improvements.

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 to drive our infrastructur and also 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 + 17M for modules (normal image has 150-200M for modules, for things you never need in virtualized environment)
 
 

Yep, that's the best path for this use case.

On vendor kernel you need to enable overlay https://github.com/armbian/build/blob/main/extensions/mesa-vpu.sh#L18-L28
 
 
mainline based gnome desktop + apt install kodi (just tested 4k/H264 video works without any problems)

Thanks for the info to try other options  🙂
Thanks for the tip, I'll try other options 🙂 It worked for: odroid-c4 ... basically, the settings are the same as for the OrangePI3LTS, I'm talking about connecting cables to a 40x2 / 20x2 LCD.
The diagram for the BananapiM2pro is as follows:

My Winstar 40x2 OLED LCD compatible with drivers: hd44780 / driver: WS0010 is detected in the system as: 3f
..................................
sudo i2cdetect -y 0
[sudo] kris: 
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
00:                         -- -- -- -- -- -- -- -- 
10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 3f 
40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
70: -- -- -- -- -- -- -- --        
  ..................................
You can also enter the appropriate values yourself in the file:
   sudo nano /boot/armbianEnv.txt
verbosity=1
console=both
overlay_prefix=meson
fdtfile=amlogic/meson-sm1-bananapi-m2-pro.dtb
rootdev=UUID=a4fb8074-c453-45da-ab31-4d61dca46cfa
rootfstype=ext4
overlays=sm1-odroid-c4-i2c0 sm1-odroid-c4-i2c1
usbstoragequirks=0x2537:0x1066:u,0x2537:0x1068:u
 

 
regards
 
 

I have to be upfront: I'm not a developer. I'm an ops/observability engineer who knows how to use software to get things done. I know a bit of Go — not much — and I have no formal background in software design. What I do know is what I need, and what was missing. So I built it. Take the code with that in mind.
 
The problem
 
I run a Kobol Helios64 as my home NAS — a five-bay ARM board that's been sitting in a sweet spot between "serious hardware" and "abandoned by its software ecosystem." I tried the usual NAS UIs. They were either too heavy, too opinionated about owning the underlying OS, or simply unmaintained. None of them gave me a clean window into my ZFS pools without dragging in a container runtime, a Node.js server, or a Python daemon alongside them.
I wanted something simple: observe and manage my storage from a browser, on a machine that stays close to a vanilla Armbian or FreeBSD install. No agents, no frameworks, no surprises.
 
What I built
 
dumpstore — a lightweight ZFS management UI written in Go. link: https://github.com/langerma/dumpstore
 
It's a single compiled binary with a bunge of html/js/css/ansible playbooks. No database. No Node. No container runtime.
 
Ansible handles writes (dataset creation, snapshots, user/group management, ACLs)
 
Current features:
Pool overview — health, usage, vdev tree, fragmentation Live I/O statistics per pool (SSE-pushed, no polling) S.M.A.R.T. data per disk — temperature, power-on hours, reallocated sectors Dataset browser — collapsible tree, compression, quota, mountpoint Dataset create / edit / delete Snapshot management — list, create (recursive), delete User & group management — create, edit, delete; system users protected ACL management — POSIX and NFSv4, recursive apply supported Prometheus /metrics endpoint (because of course) Runs on Linux (systemd) and FreeBSD (rc.d) Builds with make build && sudo make install — that's it  
What it is not: a full TrueNAS replacement.
 
SMB/NFS share management, a file browser, and ZFS send/receive are on the roadmap — but I'm building deliberately, one thing at a time.
 
Why Armbian specifically
The Helios64 is the reason this exists. If you're running Armbian on a Helios64, an older ARM server, or any ZFS box where you care about what's actually installed — this was built for you.
 
Feedback welcome
Since I'm not a developer by trade, I'm sure there are things I've done in a way that makes experienced Go or software folks cringe.
Issues, PRs, and honest feedback are very welcome.
 
The code is small enough to be auditable — main.go plus a handful of internal packages.
 
Markus Langer
 
 
 

Try to build from this PR:
 
https://github.com/armbian/build/pull/9381
 
- use CURRENT branch
- enable additional DEBUT if it doesn't proceed
- leave u-boot as is or try with most recent

At this point, the most realistic path is to use hardware that is already officially supported. Bringing up new hardware or maintaining outdated vendor kernels requires significant engineering time and resources. Board enablement is not a small task. It involves ongoing maintenance, testing, integration work, and long-term support. This represents real cost for the project while public project funding is not even on the level to cover response of such ideas. If you are expecting someone will just emerge and spent months of his private time in exchange for: constant insults, hate and complete absence of financial coverage for the time spent (things are never in perfect state to satisfy over-spoiled customers of someone else) ... adjust expectations.
 
We encourage users to choose hardware wisely - that already has active support and to contribute back to the project when possible. That is the only way we can avoid overextending limited resources, burnouts, collapse.

Vendor kernel will stay for awhile (this year for sure) as mainline is not on this level yet.
 
 
This part might not be part of the release - you can grab it from nightly release - but most likely it won't have any affect to this topic.

It really is as simple as possible on Armbian.
Pretty good documentation too, I posted it before, but here you go again: https://docs.armbian.com/
 
All you have to do is to login as root from an ssh client following standards.
I do not have access to a windows installation where I can confirm if what you say is true, that the ssh client does not let you login with "ssh root@xxx.xxx.xxx.xxx", so maybe you are correct, but it sounds very unlikely to me.
But what I can guarantee is using an ssh client from another unix system will definitely let you connect.
 
So use a mac or a linux computer to access.
Or install wsl on windows and do it from there.
https://learn.microsoft.com/en-us/windows/wsl/install
 
Edit:
I actually forgot, but I had putty installed on my system. I used it to check colors in a script I maintain and it exists in the extras repo on arch.
Downloaded latest minimal image for rpi (so not same hardware as you) and...

 

 

 
No settings changed in putty, just a standard root@192.168.99.60 that I added into the "Host Name (or IP address)" field and clicked "open".
 
Name            : putty
Version         : 0.83-1
 
So I don't know what to tell you...

... problem is elsewhere. This is running:
 
sudo dpkg-reconfigure tzdata  
in CLI (Armbian Noble), choosing region Atlantic, then:
 

One option is to start a crowdfunding campaign. You can review how previous campaigns were structured here: https://forum.armbian.com/crowdfunding/
 
As a rough estimate, bringing a new board or image to a sustainable level typically requires around $5,000 just to cover the initial development effort - when dealing with something simple. Running a campaign also gives a clear picture of how challenging it is to secure funding for this type of work.
 
However, initial development is only part of the cost. To avoid creating another long-term maintenance burden (a “support black hole”), an additional $5,000–$10,000 is usually needed to cover ongoing maintenance, updates, CI resources, testing, and long-term support.
 
It’s also important to emphasize a general principle: you should ideally choose hardware that is already officially supported, rather than expecting support to be built around hardware after purchase. Supporting embedded devices sustainably requires planning, funding, and long-term commitment — it doesn’t happen automatically.
 
In short - it’s possible, but it requires realistic budgeting and shared responsibility.

Auto generated images:
 
https://dl.armbian.com/nightly/orangepirv2/Forky_current_minimal
https://dl.armbian.com/nightly/orangepirv2/Noble_current_xfce
 

Board: MKS-Klipad50
Images:
* Armbian_26.2.1_Mksklipad50_noble_current_6.18.8_minimal.img.xz
* Armbian_26.2.1_Mksklipad50_trixie_current_6.18.8_minimal.img.xz
Passed tests:
* gpg and sha checksum files
* boot from emmc, leds, display, touch, usb, internal wifi
* initial setup, uboot-console, full klipper/klipperscreen install, reboot
Result: All expected images do exist, verify and work properly.

We are opening public testing for upcoming Armbian images. The goal is to verify that the right images are built and that basic functionality works before boards are moved to the main download pages.
You don’t need to be a developer. Simple testing and short reports are enough.
1. Download testing images
Testing images are available here: https://fi.mirror.armbian.de/incoming/igorpecovnik/  Pick the image matching your board and choose desktop if applicable. 

Once image is confirmed working, the board will be:
Moved to the main download pages Added to Armbian Imager 2. Check that expected images exist
Before testing, please verify that:
Your board is listed The expected image variants exist If an image (variant) seems to be missing:
Check the release target definitions:
https://github.com/armbian/armbian.github.io/tree/main/release-targets If the image should exist, check build logs to see if it failed:
https://github.com/armbian/os/actions/runs/21642728389 If you are unsure, report it anyway.
3. Flash and boot
Flash the image using Armbian Imager: https://imager.armbian.com
Boot the board and check whether it reaches:
Login prompt (CLI images) Desktop (Desktop images) If the board does not boot, serial output or photos help.
4. What to test
Please focus on basic functionality:
Boot reliability and reboot Networking (Ethernet, Wi-Fi, Bluetooth) Display and GPU, if applicable Installer and first-boot experience Advanced features can wait. Stability comes first.
5. UEFI ARM64 images
If your board might support UEFI on ARM64, please test those images on them. Working UEFI images allow us to reuse targets and reduce the number of generated images.
Reference:
https://github.com/armbian/armbian.github.io/blob/main/release-targets/reusable.yml
6. Community-supported boards
Some boards are currently released as community-supported: https://github.com/armbian/community/releases 
We want to promote suitable boards to standard support which brings more image variants and much faster download. This requires:
Confirmation that basic functionality works Send a PR to change status from .csc to .conf A community member willing to step up as maintainer If you rely on such a board and want it promoted, this is the time to help.
7. Reporting (here in this topic!)
When reporting test results, please include:
Board model Image name and variant What works and what does not Logs or serial output if available Even short reports like “Board X, image Y, boots and networking works” are useful.
Thanks to everyone helping with testing. Early feedback directly improves the release quality!

We are opening public testing for upcoming Armbian images. The goal is to verify that the right images are built and that basic functionality works before boards are moved to the main download pages.
You don’t need to be a developer. Simple testing and short reports are enough.
1. Download testing images
Testing images are available here: https://fi.mirror.armbian.de/incoming/igorpecovnik/  Pick the image matching your board and choose desktop if applicable. 

Once image is confirmed working, the board will be:
Moved to the main download pages Added to Armbian Imager 2. Check that expected images exist
Before testing, please verify that:
Your board is listed The expected image variants exist If an image (variant) seems to be missing:
Check the release target definitions:
https://github.com/armbian/armbian.github.io/tree/main/release-targets If the image should exist, check build logs to see if it failed:
https://github.com/armbian/os/actions/runs/21642728389 If you are unsure, report it anyway.
3. Flash and boot
Flash the image using Armbian Imager: https://imager.armbian.com
Boot the board and check whether it reaches:
Login prompt (CLI images) Desktop (Desktop images) If the board does not boot, serial output or photos help.
4. What to test
Please focus on basic functionality:
Boot reliability and reboot Networking (Ethernet, Wi-Fi, Bluetooth) Display and GPU, if applicable Installer and first-boot experience Advanced features can wait. Stability comes first.
5. UEFI ARM64 images
If your board might support UEFI on ARM64, please test those images on them. Working UEFI images allow us to reuse targets and reduce the number of generated images.
Reference:
https://github.com/armbian/armbian.github.io/blob/main/release-targets/reusable.yml
6. Community-supported boards
Some boards are currently released as community-supported: https://github.com/armbian/community/releases 
We want to promote suitable boards to standard support which brings more image variants and much faster download. This requires:
Confirmation that basic functionality works Send a PR to change status from .csc to .conf A community member willing to step up as maintainer If you rely on such a board and want it promoted, this is the time to help.
7. Reporting (here in this topic!)
When reporting test results, please include:
Board model Image name and variant What works and what does not Logs or serial output if available Even short reports like “Board X, image Y, boots and networking works” are useful.
Thanks to everyone helping with testing. Early feedback directly improves the release quality!

Inspired by the incredible work @jock and @ilmich have done to make the RK322x platform stable on mainline Linux, I decided to tackle the application side of things. My goal was to turn these "e-waste" TV boxes into fully functional, low-latency Android Auto head units for our cars.
 
This fork of OpenAuto is built as one of my "Is it possible to turn this into that?" projects. It turned out to be one heck of a nightmare to pull off, but at the same time a lot of fun because I can see the potential of these TV Boxes as something you can actually put in your car and turn into a usable head unit!



 

 
System Requirements
Target Device: RK322x TV Box (e.g., MXQ Pro 4K). OS: Armbian Bookworm or Trixie (Kernel 6.1+ recommended). RAM: 1GB recommended. FFMPEG Installed: This build requires a specific build of ffmpeg that can be found here.  
Release: v2.0.0-alpha
This release represents a major architectural overhaul. I have removed heavy dependencies (PulseAudio, QtAudio, GStreamer) in favor of a lean, direct-to-hardware pipeline using RtAudio (ALSA) and FFmpeg v4l2_request.
 
Download:
https://github.com/Harleythetech/openauto-rk3229-armbian/releases
 
Technical Details
Video Engine: Switched from GStreamer to a custom FFmpeg + V4L2-Request backend. Leverages the v4l2drmprime patch set for Zero-Copy rendering. Enables full hardware H.264 decoding on Rockchip stateless decoders. Result: Stable 1080p 60fps stream on a 1GB RAM device. Audio Overhaul: Replaced PulseAudio and QtAudio with RtAudio. This creates a direct, low-latency path to the ALSA hardware driver. Display: Targets linuxfb (Framebuffer) by default instead (eglfs and ffmpeg have issues when you run them together due to DRM master lock)  
Configuration
This release requires a specific ALSA configuration to allow audio mixing (dmix) without PulseAudio. Create/Edit /etc/asound.conf:
 
pcm.!default { type asym playback.pcm "dmix_hdmi" capture.pcm "plug_null" } ctl.!default { type hw card 0 } pcm.plug_null { type plug slave.pcm "null" } pcm.dmix_hdmi { type dmix ipc_key 1024 ipc_perm 0666 slave { pcm { type hw card 0 device 0 } format S16_LE rate 48000 channels 2 period_size 512 buffer_size 4096 } bindings { 0 0 1 1 } }  
Known Issues
Invisible Cursor: The mouse cursor works but is currently invisible when the FFmpeg video backend is active (rendering layer order issue). Backend Fallback: In rare edge cases where DRM initialization fails, the app may incorrectly default to Qt software output. Probably more, i haven't tested it that much  
 
Development Status: Active & Seeking Contributors Currently, I am the sole maintainer focusing on the RK322x platform (specifically the RK3229).
I am actively looking for developers interested in expanding support to other devices (such as RK3328, RK3399, or Allwinner H3/H6). If you have experience with C++, Qt, or V4L2/DRM and want to help turn these TV boxes into capable head units, contributions are highly welcome!
 
Repository: https://github.com/Harleythetech/openauto-rk3229-armbian
 
 
Credits:
@jock and @ilmich for ffmpeg patches and the csc-armbian-for-rk322x-tv-box-boards opencardev for openauto and aasdk

Rpi support for whatever of their devices is mainly on the level of RaspberryPi OS. We use their kernels sources as base, add some additional things and release timing is different - not much difference. If they added new device, it should just work. 
 
If anyone wants to improve support or fix WiFi -> https://github.com/armbian/build/pulls