Igor

Double checked with fresh image Armbian imager -> Odroid -> XU4 -> Armbian Trixie minimal. Works as expected.

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.

If you want to add new board with its own device tree, this is a good example: https://github.com/armbian/build/pull/9423 Remember to add pictures - this way https://github.com/armbian/armbian.github.io/pull/236

Trouble with SSH client or failed SD card could explain this. We didn't change anything in this regard. SSH settings are Debian / Ubuntu defaults. We are not altering this. I tested latest image on XU4 and - it worked.

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

It is possible but I think it is currently broken / unfinished / does not work (properly) yet.

Actually not as I am human - I need time and focus to be able to understand what the code does. Same as everyone else. BASH is list of commands and if you are average tech person you can interpret those command, one after another to understand what is going on. AI can help. You can, but you can not expect that I will answer them. Perhaps someone else will, perhaps nobody. I show you how you can understand it without destroying my brain - I need to look into the code to answer questions ... Its Friday evening here and I already answered at maximum effort.

Radxa images comes with proprietary vendor kernel v5.15, which we won't integrate for this hardware - Armbian is only made with mainline derived v6.18.y / v6.19.y kernel, which is far from completion. Those SW stacks are fundamentally different. We can produce a Bullseye image, but with a kernel 6.18.y only ... which means identical hardware support as on Armbian Trixie. In general https://docs.armbian.com/User-Guide_FAQ/#why-things-stop-working

Its BASH, so its easy to interpret: https://github.com/armbian/build/blob/main/packages/bsp/common/usr/bin/armbian-install perhaps by AI: https://chat.z.ai/s/084a9535-9fd8-4078-ab9c-ad85254689cf Refactoring draft: https://github.com/armbian/configng/pull/384 Plan is to write this script from scratch ... but dunno when. This should work in all cases. I hope those tips helps.

Thank you. Basic functionality, few non critical bugs = release ready. Moving to main download location. Imager will have them after they are moved to primary download location. Test images are not there. We don't provide that. We will only provide images with mainline derived kernel which is hard to compare - its a very different SW stack - with Radxa vendor kernel. Basic (!) functions for headless usage are already working. The rest in next 6-12-> month.

Are those ok? https://fi.mirror.armbian.de/incoming/igorpecovnik/radxa-e25/archive/ One current, one vendor.

All are interesting. However, H3, H5 and H6 boards will receive additional fixing to DVFS during this week. After that, I will rebuild them, but those are all CSC, so there are additional tasks: We only generate and test boards with at least "standard support", where a known maintainer is around. If you (or someone else) step up as a maintainer: https://docs.armbian.com/User-Guide_Board-Support-Rules/ following by PR as such https://github.com/armbian/build/pull/8981 boards will automatically be added to automatically generated build lists https://github.armbian.com/release-targets/targets-release-standard-support.yaml and images can be (auto) generated: https://docs.armbian.com/Process_CI/#automation-for-developers-and-maintainers If you wanna cover those steps, report status at release periods, step up. In most cases, boards work but during those tests we usually always found something to fix. And boot loader compilation is checked this way - end user upgrades don't upgrade that by default so you could be running a board for years while freshly build images would have borked uboot ... Perfect - new use case: Armbian QA

Once board is tested, its moved to its final destination https://www.armbian.com/nanopi-m4-v2/ I tested it KDE was enabled "as is" / at last moment. I am not familiar with KDE much, so I don't know what to enable. I know that there could be issues between Neon and Ubuntu packages, so we kept this minimal. https://github.com/armbian/build/blob/main/config/desktop/noble/environments/kde-neon/config_base/packages Tested boards are moving to /dl Thank you for help.

Here, yes. Thank you! No, but we need to test images made for release. There is another last minute change https://github.com/armbian/build/commit/1890d7f6566a65202f73730b469d024c20f863b8 than can, in theory, make unbootable image. OK. Bugs will be present and we won't be fixing them at this stage. Here - if basic things works - that image boots, have connectivity and video output ... its ready to ship. All other things can be fixed with an update. If / when they are fixed.

What was already tested: UEFI x86 KDE Neon, Gnome, Ubuntu minimal MusePI Pro Xfce Odroid M1 KDE Neon Odroid N2 Xfce https://paste.armbian.com/oqegebaqey Orangepi 5 Nanopi M4V2 Odroid M2 Radxa E54 Rock 5C Orangepi 3LTS Odroid C4 Bananapi Rock 3A Orangepi PC2 Nanopi K1plus Khadas Edge 2 Bananapi F3 Nanopi M6 / R6S Rock 2F / 2A / 3A Rpi (all)