Igor

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

Thanks Igor.
Just for reference, I also tried Armbian_community_26.2.0-trunk.332_Odroidhc4_forky_current_6.18.7_minimal.img
 apt update
 apt upgrade
 apt install linux-headers-current-meson64
 apt install zfsutils-linux zfs-initramfs zfs-dkms zfs-zed
 
Everything went fine and seams to working OK.
 
Chris

It is a AP-mode problem of the Realtek 8822CE chipset. Replaced the M2 card with Intel AX200 card and since then solid as a rock

I had to rebuild server and this was not fixed yet. Temporally location https://stpete-mirror.armbian.com/users.armbian.com/