Igor

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/

Stick to this board: https://www.armbian.com/bananapicm4io/ So far we have a person behind and a tiny budget, so our personal finances are not blown in 100%. Behind Orangepi CM4 we have nothing except random community work and with this it is not possible to plan any actions.

Armbian recently merged and will be releasing (and backporting) a patched devicetree file for the Odroid C4 and HC4 that eliminates the second power-cycle "glitch" during boot.
Hopefully this will fix at least one issue people have been reporting, where some HDDs (or other devices) do not react well to rapid power double-tap during boot.
https://github.com/armbian/build/blob/main/patch/kernel/archive/meson64-6.19/board-odroid-sm1-regulators-boot-on.patch
 
It will also be released (and likely backported) upstream in next Linux kernel release and/or fixes.
 
Also, something else people have been reporting is the HC4 struggling to spin up two large HDDs at the same time.  If you have an HDD with a "Power Up In Standby" (PUIS) setting, such as the Seagate IronWolf, then you can configure all non-system (non-boot) drives in this manner, and then mount and access them sequentially after the system has booted.  Depending on how much power the HDDs use in regular operation, this might work to get both spun up and running.  Theoretically, you could also access just one drive at a time and then place it back in standby before using the other drive. YMMV.

They are not empty. You need to go one level deeper:
https://armbian.nardol.ovh/dl/tinkerboard/archive/
 
BTW, try https://github.com/armbian/imager It will be much easier.

In the past (2019)
there was no chance to use the A64-CPU Jide Remix Mini with armbian, because of a blocked -u-boot

But today I found a site (from February 2025 on github)
https://github.com/r4nd3l/revived_remix_mini_pc?tab=readme-ov-file
which can make the Closed Jide Remix Mini to boot from SDCard with a modified u-boot

There at the github page is a modified u-boot and a modified A64 armbian for the Jide Remix Mini.
Jide did leave us with a closed/blocked device  AT this time the 16GB emmc isnt useable, but using SDCard is a start for upcycling the Jide Remix Mini
 

We are slowly releasing v25.11 images and here I did some mess-up, fixed now. We don't offer Bookworm anymore, so Trixie it is. If you need to Bookworm for some reason, you can build on your own or use the one from archive: http://archive.armbian.com/

Attached torrent will download super fast.
Armbian_25.11.1_Helios64_trixie_current_6.12.58_minimal.img.xz.torrent

We only provide mainline based kernel, where video acceleration might not work. If you have a need for that, than use those hints:
 
add DT here:
https://github.com/armbian/linux-rockchip/blob/rk-6.1-rkr5.1/arch/arm64/boot/dts/rockchip/rk3568-odroid-m1.dts
enable vendor kernel 
https://github.com/armbian/build/blob/main/config/boards/odroidm1s.csc#L7
build with ENABLE_EXTENSIONS="v4l2loopback-dkms,mesa-vpu" and desktop will work faster, video acceleration will most likely just work OOB.

I guess this should do:

Hello, another Odroid M1S owner and user here. I tried the Ubuntu image because I was curious about video acceleration in particular. So I installed Kodi and played a few videos. There is no acceleration. This means that this image is not usable as a player. However, it will probably be usable as an SMB/NFS server (I'll try using it that way for a while).
A few comments:
- Gnome is relatively slower, but not unusably slow (I personally don't mind, because I don't intend to use the M1S as a desktop)
- Gnome sometimes has problems rendering windows, there are strange stripes, only in certain parts of the windows, and at times it is so annoying that it becomes unusable
- Personally, I would love it if someone experienced could take a working GPU driver and put it into this image. That would solve everything, and we could all use the M1S to our full satisfaction (however, it's probably not that easy, because otherwise the guys at Odroid would have already done it).
- I will add relevant links to a functional accelerated solution that makes the M1S a fully functional driver, but based on the very old and not very usable 5.10 kernel
- https://forum.odroid.com/viewtopic.php?f=217&t=47621 here is a functional Odroid based image solution for media player.
- By the way, I managed to upgrade the image mentioned here to Ubuntu 24.04, using the Kodi build for Odroid M2 ( https://forum.odroid.com/ viewtopic.php?f=235&t=49005 ), but I had to stay on kernel 5.10, and even this version works relatively well as a functional player with accelerated videos (the old kernel is a prerequisite)
 
I hope that I have contributed at least a little to making this Armbian image gradually become the standard for M1S, because this computer deserves it.
 
 

So, here's what I had to do to successfully build the image. First, I corrected my board file in the config/board/orangepizero3.csc directory. The processor value was incorrect, it was 616, so I set it to 618.
Menuconf suggested selecting a board with a 618 chip, but in the board file it was listed as family 616.
Later, I copied my board file to the userpatches directory and added the value CONFIG_DRM_PANEL_MIPI_DBI=m. Then I ran the image build script with the menuconf viewer. I was surprised that the CONFIG_DRM_PANEL_MIPI_DBI parameter already had the value "m"; previously, it was empty.
After all these manipulations, the build went smoothly. Thank you so much for your support.

I downloaded 'Armbian_25.11.2_Odroidc2_trixie_current_6.12.58_minimal.img.xz', flashed it to sdcard, and it booted fine.
 
As a sidenote unrelated to the issue at hand, my first try was with the sdcard on a device with emmc, and in this case the boot process stopped after block-local (?), and dropped to initramfs shell prompt.

I guess this should do:

I guess this should do:

This is confusing for me. What are you actually trying to achieve? What is on Renegade that is not on Rpi?

Yes. It is only enabled / working with 6.1 and desktop (Gnome) builds. For mainline based, perhaps 6.18.y ...

Lowest price is what makes it popular. But software is the biggest key of the package and there they are among the worst.
 
 
On this SoC, we will be cooperating with SoC maker's board directly - working with Orangepi is too damaging for us:
https://www.cnx-software.com/2025/04/27/muse-pi-pro-feature-packed-credit-card-sized-spacemit-m1-risc-v-sbc/
This will probably be done in a couple of weeks, so you can follow that and adjust accordingly.

Hello SteeMan,
Thanks for your answer
Its running now
And I will browse the getting started pages
To get this system running well
It seems faster
So i hope i can learn a lot at this forum
Greetings Herman

Also we fixed TUI / GUI way of setting UARTS, merged today:
 
https://github.com/armbian/configng/issues/360
https://github.com/armbian/configng/issues/344
fixed with 
https://github.com/armbian/configng/pull/393

Use the one that works / safe to ignore. I think one device is normal and the other for WiFi direct. 

@IgorI'm back from the brink. New job, new house build 3 hurricanes. I'm still working on my 1 acre lot to clean up the vines and stuff, but I'm starting to have more time for this kind of stuff. I need to get all my old boards up to date, hahaha