Igor

https://github.com/armbian/build/blob/main/config/boards/bigtreetech-cb2.conf#L8 Nope. We don't support vendor kernel for other then 3588 and more recent. We don't maintain vendor kernel for this hardware (nor any other 3566 AFAIK), so it might be some work and its all on you. Mainline support is very mature, however I don't know about the status of specific features you are interested in. IMO its not worth going vendor route on this hw.

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.

DKMS compilation per board, examples: https://github.com/armbian/build/blob/main/config/boards/radxa-cubie-a5e.csc#L20-L22 https://github.com/armbian/build/blob/main/config/boards/orangepirv2.wip#L13-L17 https://github.com/armbian/build/blob/main/extensions/radxa-aic8800.sh https://github.com/armbian/build/blob/main/extensions/bcmdhd-spacemit.sh

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.

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

Armbian config is just a wrapper to system tools that are dealing with this. We only change hardware related packages, the rest is stock Debian / Ubuntu. Is this problem solved somehow in Ubuntu? Probably the core of issue is originating from here: https://www.iana.org/ "Time zone of Iceland in Africa?" https://lists.iana.org/hyperkitty/list/tz@iana.org/message/QKQ27H23CTLFGJAQXJ24IVLRLQXHRLUA/ Interesting problem ...

So we are perhaps looking at potential changes on SSH app / encrypting introduced in Debian Trixie? That affects certain clients. On Armbian side - we didn't change anything in this regard. Eventually we will get down to why this doesn't work. Software developers have to learn how to live with constant frustration. It never goes away ...

Problem must be affecting most if not all (Armbian Debian) users in order to be removed. We need to understand why you have problems and we / others don't. If there will be more reports on issues, we will look into and fix them. This is how it usually goes. And minimal CLI has different networking stack as server / desktop.

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.