Igor

When you cloned our repo, you got 10 years of specific work on common work and that was contributed by 500+ people. Most of people are resolving their specific problems, yes, but we all try to do it the way that is reusable, that person behind has less work. We also got a lot of things prepared. Doing things universal should always be considered. Also because you might get help from someone. Which has absolutely same problems, but is having hardware from another vendor. In our world, SoC defines how things work, not the one that put SoC on PCB and name / sell it. This means that most of the drivers are the same, especially this area is shared - low level communication protocols such as GPIO, I2C, SPI. This is always shared among boards with the same SoC. This goes further. It is shared among same families and we also already have some common generic top level API / libraries that can be used. https://docs.kernel.org/driver-api/gpio/consumer.html (but here my understanding ends, I am not updated with the state of this) Yes, it has no point poking into. WiringPi library is a dead project for many years and its no point dealing with this. What vendors do here is, trying to be "as Rpi as possible", so they are doing their quick and dirty assemblies of that, always with partial functionality and absolute absence of maintenance. Their goal is to sell, regardless what is the quality of software. Is that your goal? I doubt. I am not an expert in this field, so those are general tips, but there are people on and around this forum that knows this stuff well, as they developed those libraries. I am just giving you some ideas / tips. Decision what you will do with your time is yours. Another one that came into my mind, while replying: https://github.com/eclipse/mraa

@going Probably @wwortel means to develop a minimal boot image which would download and dd image to eMMC. I agree that would be nice to have, but develop that requires time / resources we don't have. If you look into the script that installs OS to eMMC (and other media) its pretty complex and hard to maintain https://github.com/armbian/build/blob/main/packages/bsp/common/usr/bin/armbian-install Not to mention that people doesn't pile up to help us around that. There is / always was just a few people that sacrifices their precious family time to provide you current experience. Where we can always find something to fix and improve.

New version (v24.11) with even more targets has been released. Home assistant takes few minutes and might require reboot at first install or there will be some errors related to privileges. This gets away after waiting few minutes and reboot. Testing was done on Odroid M1. Latest: https://github.com/armbian/distribution/releases/tag/24.11.1 Previous: https://github.com/armbian/distribution/releases/tag/24.8.4

We are cleaning those builds as they have very little value. But you were lucky: https://github.com/armbian/community/releases/tag/24.11.0-trunk.351

Take a look at universal projects that are made far better, and are universal by design. https://forum.armbian.com/forum/40-reviews-tutorials-hardware-hacks/ (pinned topics)

They are not needed. We use flash media friendly and more advanced ZSWAP solution by default. https://www.google.com/search?q=zswap If you don't want to have this, you can of course disable this feature in /etc/defaults/ (will be soon added to armbian-config) and add swap file. But that is not recommended.

Try here: https://rsync.armbian.com/oldarchive/ We can't possibly maintain this further, sorry.

Running Debian bullseye? This is EOL. Edit: Aha, yes, that's it. https://unix.stackexchange.com/questions/669004/zst-compression-not-supported-by-apt-dpkg

Yes, we should probably add REPLACE: neofetch to the control file. Well, there are several reasons for this: - we are patching neofetch on our own to add Armbian branding. As Neofetch is not maintained anymore, we can't add Armbian normal / official ways by opening a PR at their GH - we would like to switch to fastfetch but this has to be resolved first https://armbian.atlassian.net/browse/AR-2336 (we have extreme lack of hands since ever as we focus into kernel space hard problems, so there is no way to proceed on this) - during the switch to new generation of armbian-config there are many things to tackle and this (known problem) simply live somewhere in backlog This is how this transition is made and we could probably remove this double packaging to make it easier. We already pack it at Armbian config repo https://github.com/armbian/configng https://github.com/armbian/build/blob/main/lib/functions/compilation/packages/armbian-config-deb.sh

Test most recent builds: (still in testing) https://rsync.armbian.com/incoming/schwar3kat/rock-5c/archive/

I think it is better to expand script to support those scenarios. https://github.com/armbian/build/blob/main/packages/bsp/common/usr/sbin/armbian-install Worse case, write things here: https://docs.armbian.com/User-Guide_Getting-Started/#how-to-install

Headers are released via repository and that is done when images are tested. In about a week.

Great job! Interested for integration into main config tool? https://github.com/armbian/configng Now this tools is properly made. https://docs.armbian.com/User-Guide_Armbian-Software/#adding-example

Can be found in https://github.com/armbian/community

REQUIRES Armbian 24.11 (currently availability is limited to rolling release or self build image) Armbian config is a configuration utility for customising and automating tasks within Armbian environments. These scripts help streamline setup processes for various configurations and use cases. It helps end-user to setup their network, ssh, configure hardware features and provides simple install and uninstall methods for your software packages. armbian-config Documentation: Adding a new feature or software install title User guides: system features software installer Please open bug reports or feature requests directly on GitHub: https://github.com/armbian/configng * valid for new version of tool that comes from Armbian v24.11 onwards