Important project changes, both technical and not.
Highlights
- important (non-technical) project changes
- hundreds of kernel and user space related bug fixes
- added rolling Debian (sid) based releases
- added generic stable and rolling UEFI
arm64&x86images - added Raspberry Pi images
- upcoming Ubuntu 22.04 LTS images are ready
- new Extensions build framework
- extensive build automation (CI/CD) improvements
We will get into more detail on those technical bullet points, a little further down. However first there are some non-technical — but arguably more important — topics that the team feels we need to address.
Non-technical
Update on Call for Help
Back in October, we announced that Armbian needs your help.
Response overall has been positive. We have by now updated and made public the (previously internal) new list of Board Maintainers.
We would like to extend our sincere appreciation to all the people who have stepped up to contribute their valuable time, energy, and other resources to the project. It really does mean a lot to us and it’s things like that which really keep us going through all the other challenges.
However, as you can see there are still quite a lot of blanks in the above linked table. And there remain several open positions left to fill, as well.
Therefore we feel that this has been a good start, however we also believe we still have much further to go before our project can really become truly sustainable on a longer term basis. We have some further ideas along those lines, which we would like to develop in the next few sections.
BSP, blobs, ‘vendor’ kernels and bootloaders
Advanced users and developers already know about these, but we want to give a brief refresher, for the benefit of end users and others who may not, and also to give some context for what will follow.
Historically, in many cases board manufacturers have been ‘maintaining’ (in parallel) some heavily patched Linux kernel which have diverged so far from mainline as to be considered an entirely different operating system. That mess, is what some refer to as a Board Support Package (BSP), ‘legacy’ kernel, or ‘vendor’ bootloader.
Those sources get ‘thrown over the wall’ upon release, very often never to be touched again. They are full of proprietary code (binary blobs), dirty hacks, ancient kernels, and all manner of other garbage that will never see the light of day in mainline Linux. All of which is very similar to the situation on Android, if you know anything about that.
In fact, if not for projects like Armbian, our SBCs would likewise become throwaway devices, too — just like your Android — in pretty short order. That is, if you ever even got them to work in the first place.
Why Armbian?
Why use Armbian, instead of some other distro, or the vendor’s BSP?
Armbian is ‘mainline first’
Armbian is part of a larger group of develpers and projects who take a ‘mainline first’ approach, as we feel this is the only sane way to try and maintain things long term.
But this approach takes work. And not just upon release of any particular SBC. The Linux kernel (and other parts) are under continuous development, and so things that already worked perfectly fine before can and do break going forward. And those need to be fixed, too. It never ‘ends.’
Now multiply that work times the over 100 boards we support, and suddenly we are talking about a tremendous amount of effort!
Armbian unifies fragmented development efforts
SBC and kernel developers are a rare and valuable resource. Therefore Armbian’s perspective has always been to try and unify these scarce resources as much as possible.
Before Armbian, kernels, build tools, boot loaders, patches, etc. were scattered all around the Internet, in various repos, forum posts, etc (and to some extent, this is still true today). We have worked long and hard to unify all of these disparate efforts into a single, coherent build framework in order to arrive at a consistent experience across a wide variety of boards.
If you are a developer, maintaining some of your own build tools, or patches, we invite you to join us! Please seriously consider whether it is better to maintain those efforts separately and on your own. We invite you to stop by any of our communications channels or repos and say hello! We would love to have you.
Armbian stays close to upstream
Armbian is essentially, ‘Debian (or Ubuntu) for SBCs.’ We are mainly concerned with low level things like boot loaders and kernels, where we are actually far ahead of upstream (at least on SBCs). Other than that however, we are using almost completely vanilla upstream package repos.
User Expectations
Hardware vendors these days are shipping new hardware faster then they are able to update their own websites. Their customers, commonly our users, are adding pressure on Armbian to have software support on ‘day one.’ Because of this expectation, we often find ourselves in a difficult position.
It is very important to Armbian to build a healthy relationship with both the vendors and our users. That said, we are unfortunately more and more finding that because of decreased vendor support, increased complexity, and lack of maintainers we are not currently able to meet user expectations for all of the boards we support on a regular basis.
Expect (some?) breakage
Our ‘mainline first’ focus means that, sometimes, things break. Even things that worked perfectly fine before.
No one likes when things break. But we want to put things in context, in the hopes that end users may become more aware of the broader picture. We think that pursuing mainline support is worth the tradeoff, and we hope that you will agree and support us in this effort.
Because we are a small team, it can take us some time to fix breakage. But you might be able to help us.
How can you help?
We are a true community project. There is no company, business model, hardware sales, etc. behind Armbian. It’s just us. You and me. Us.
There are many ways to get involved, besides development. You can build and test new versions, confirm and report bugs, contribute to documentation, help other users on our forums, or in our IRC and Matrix channels.
In addition to the above, users can also help by voting with their wallets. There are currently some ‘Project friends’ listed at the bottom of our home page. Going forward, we want to start making certain information (like relative vendor support levels) even more clear and readily available to end users, as a part of our longer term survival strategy. Stay tuned!
New Board Support Rules
As a first concrete step towards alleviating some of our above mentioned growing pains, we have created new Board Support Rules which are the basic guidelines Armbian will start to follow when deciding which vendors to work with and the hardware Armbian will support. Even the most productive vendor relationships however still incur a workload for us, which leads us to the next point.
Re-defining Vendor Relationships
And finally, last, but certainly not least…
As a growing organization we realize we may not have spent adequate time with board manufacturers to clarify our expectations and needs. This has lead to inconsistent monetary and skilled support from some vendors, over time. By now this is unfortunately having a detrimental effect on our ‘day to day’ operation in the resources that are available to continue to address the ever growing list of issues for each board, regardless of vendor. We have realized we will need to address these shortcomings by working with vendors to rebuild and strengthen our relationships, that we may both enjoy mutual success.
In some cases, vendors we have worked with in the past have only made one-off or limited contributions while expecting a life-time of support for their boards. Again, we realize this may partially be our fault for not being more up front about what we need to be able to sustain Armbian. However we also feel a bit like like some vendors have taken advantage in this regard.
To help reset expectations going forward, we plan to pursue a multi-part approach to this problem. The first part will be using the communication channels available to us (this release announcement, our highly trafficked download page, etc.) to begin a campaign aimed at increasing public awareness of which vendors are working with us and which are not.
Eventually, vendors who do not work with us to provide continued support (monetary or development assistance) for their hardware may find that their hardware loses support, becomes downgraded to the community support tier, or in the absolute worst cases may be removed from our system.
We don’t really want any of those things to happen, so please, our communication channels are open. At the same time, things cannot continue as they have been, which is totally unsustainable in the long term.
Technical updates
UEFI
This release is the first to include UEFI support, for both arm64 and x86, using the grub bootloader from Debian/Ubuntu. It does not carry DTB’s, but instead relies on vendor-provided UEFI firmware working.
The arm64 version has been confirmed working on a few UEFI boards and servers. Some SBC vendors offer UEFI emulation for their vendor firmware as well, so that might be a nice alternative for mainline u-boot challenged boards.
The x86 version is mostly aimed at developers and our own CI systems; it is known to run on Intel Macs (although they don’t implement the full UEFI spec, it does work). Most x86 SBCs and laptops/desktops should also work. dkms support is a work in progress.
Both UEFI builds offer desktop editions, too. It is very early days for UEFI support still, so if you own an UEFI capable board, please do try it out and let us know how it goes!
Raspberry Pi
This release marks a change in our long-standing policy towards RPi. We have started to provide 64-bit RaspberryPi builds, using RPi Foundation kernels, versions 5.15.y and 5.16.y. Initially, our support is based on the work already done by Ubuntu. We’re not producing our own bootloader nor firmware (yet) and we’re using Debian’s flash-kernel tool. Any of this might change in future releases as we explore the options.
The rpi4b board build has been reported working on model 3b and other 64-bit capable boards, too. Check the available DTBs. Compute Modules, et al, should also work.
Even though people are reporting success, the rpi4b board is still marked wip in Armbian, as this is a brand new platform for us.
We really hope the Raspberry Pi community gets involved! Armbian on RPi is only possible due to the most excellent mainlining efforts by that community (in fact, currently we’re building the kernel from raspberrypi/linux repo directly for our convenience — however using mainline Linux is also possible using the build system).
ODROID-N2(+) u-boot moved to mainline
In this release N2(+) has been moved to mainline u-boot.
- N.B.: Take care when upgrading from vendor
u-boot!
This marks the start of a long path to mainline stability. In this release, meson64 family current kernel is being kept at Linux 5.10, and that is the recommended kernel for the N2(+). We will focus on mainline 5.15+ for the next release, which will also remove the vendor/legacy kernel (from HardKernel) completely.
Extensions Framework
We are introducing a framework which allows users to extend the build system independently from the core code base.
The framework works based on function naming conventions and has more than twenty different hooks available.
As part of the framework we provide some official extensions. Users can also create their own extension in userpatches/extensions.
For more information, you can read the extensions documentation.
Build Automation Improvements
We have been improving our build automation with extensive use of Github actions that are driving our internally maintained build hardware with around 500 fast x86, 40 arm64 vCPU cores, and 1 terabyte of memory.
While to some this may sound like a lot, our build jobs are quite extensive. We still need hours to build all the various kernels manually or at upstream change, as well as a small selection of rolling release images. Once built, the software is also deployed to real hardware and run through a battery of basic smoke tests.
Improvements in this CI pipeline have significanlty reduced the efforts needed for R&D, around kernel space, and all the way up to desktop development.
Future
We are looking forward to continue expanding our team and improving our organisation structure.
We have known for some time that eventually a proper legal entity of some sort will need to be formed, and as the project continues to grow we have begun to investigate this much more seriously.
We also want to continue to improve the central point of our project – the build framework. In particular:
- error handling
- logging
- git management
- cache usage
- source code formatting
- building and packaging
Our main OS configuration tool, armbian-config, is undergoing ongoing refactoring which is due to complete in early 2023.
A minor bugfix release is also already in the works.
Credits
This release represents the hard work of exceptional individuals who have contributed their time and expertise. Many thanks to (in alphabetical order): @150balbes, @adeepn, @AristoChen, @Azq2, @belegdol, @catalinii, @EvilOlaf, @Haraade, @Haraade, @heisath, @henkiejan1, @iamdrq, @iav, @Icenowy, @igorpecovnik, @JpegXguy, @juanesf, @JMCC, @juri_, @krachlatte, @kprasadvnsi, @lanefu, @lededev, @LucasM, @NicoD, @paolosabatino, @piter75, @RadxaYuntian, @redchenjs, @RichNeese, @rpardini, @sirnewton01, @schwar3kat, @teknoid, @The-going, @Tonymac32, @TRS-80, @Uglymotha, @yang
Special thanks to all users that support us and to vendors @orangepi, @friendlyelec, @khadas and @olimex that understand the importance of our work and support the project with donations of cash, hardware, and expertise.
Detailed lists
Bugs fixed
AR-1101 DRM patch is failing on Rockchip
AR-1079 Ubuntu archive redirector is not providing best service
AR-1077 Fix RPi4 userland audio
AR-1069 First login doesn’t pick up correct shell
AR-1065 Twitter forum registration is not working
AR-1063 X86 desktop images are not enabled in CI
AR-1062 When selecting repository install u-boot might not be flashed
AR-1055 Aptly repository seems to be out of business
AR-1048 Rpi kernel image is not updated on upgrade
AR-1043 linux-firmware repository change branch from “master” to “main”
AR-973 Helios64 boot building is failing after update to 2021.10
AR-871 Debian SID broken wallpaper
Stories finished
AR-1074 Switch all CURRENT to 5.15.y and EDGE to 5.16.y
AR-1009 Armbian Framework extensions and UEFI support
Tasks closed
AR-1100 Support for Orange Pi R1 Plus LTS, Drivers for YT8531 and other Motorcomm chips. Linux-5.10y and Linux-5.15y.
AR-1084 Enable 3D support on Debian desktop
AR-1078 Add additional forum plugins and adjust settings
AR-1068 Add gnome-system-monitor to Focal and Jammy
AR-1049 Add ZFS that supports kernel 5.15.y
AR-1044 Improve Raspberry Pi support
AR-1041 JetHome: fix brcm (AP6255) firmware links
AR-1040 Refactor armbian-bsp-cli package creation
AR-931 Using Docker image for building kernels
AR-893 Cleanup rockchip64 u-boot scenarios
AR-757 Adding Raspberry Pi
AR-586 Implement fan controller for Nanopi M2V2