Igor

That is sadly far from reality. I can name two copycat projects that are getting from us everything and in 10 years they together made <5 fixes to common problem (less then 1 vs. 1000). Open source is a very dirty place for people that contribute. What is being worked together is within our team and few external projects that have healthy and fair attitude. Those conditions has to be met: https://docs.armbian.com/User-Guide_Board-Support-Rules/#standard-support If everything is met, which is already a miracle, there is a "must be beneficial to the Armbian project". This term helps us fighting hardware vendors abuses - this vendor owe us substantiation amount for contracted services. We can't allow to fool us at any condition. Which are in general often damaging for open source, our and similar projects. But you usually can't understand from consumer perspective, if you don't look ... why would you? You just want that everything works. Finding serious and dedicated maintainers for vendors that have abuse in the name is just impossible. I can see you are a good guy, but x % of our "customers" are total morons, few percent are total abusers and are making everything to profit from our work, contributing nothing. And by the end of the day, most people see us as guilty because shit hardware doesn't work perfectly ... as everyone (or most of people) expects. Orangepi won't add "Sponsored by Armbian" or "we are stealing software support from Armbian / open source community" to their web page, so this is the only way to tell you Don't buy from them anymore any we will be friends. They are damaging to us. And to you. Donations never went over 0.5% of costs. I am in this for 10 years. Being super polite and friendly or being an ass. Makes no difference. It is devastating for open source developers. We need to bring 99.5% to satisfy you.

Yesterday bugfix release of rockchip64-current should address this problem. In stable channel, beta is anyway having latest.

Make them build & boot able within the build framework https://github.com/armbian/build When you confirms, open a PR https://github.com/armbian/build/pulls and change config file from .eos to .csc and automation will become to produce images.

I am sure you can find a kernel in Armbian repository, modern enough, to cover your needs. If this is not good enough, fix the bug, hire someone to fix the bug. Perhaps you will then understand how crazy your expectations are? Support is emotional and financial nightmare, which we have no way to cover for every hw that comes from greedy hw vendor that sets you expectations and leave this place. It can always be brought back by filling roles (not just maintainer but all). We struggle to maintain Allwinner kernel and tooling that allows re-building images at any moment, with modern user-land. We don't sell anything, we rely on your (non existing) donations. Which cover 0.5% of the costs. The rest we need to cover - tell me how? For you and dirty open source copycat projects, that never contribute any fixes to common problems. Vendor in question have no interest that this old board still works. You need to buy a new one ... and new one. I would very much like to help, but am already full time volunteer with a way too small crew of great people facing insane big bug / maintenance issues. Keeping such information accurate and usable is again - expensive, logistical nightmare. If there is nobody that have spare time and is willing to do this for free, this can't exists. Remember that with what we provide now, we already struggle big time and for 99% of costs we need to cover them with 3rd party work.

Search for board_name variable in boot.ini and try to change that.

That is almost a binary copy(cat) of Armbian, assembled in different time. They (he) don't credit where they get close to 100% of the value that makes those boards run. I am sure you can find Armbian, perhaps previous build, where this problem is not present. We developed and maintain all those features, while project you are recommending is yet another reason that kills motivation of open source developers. People you need most. Diepti is a person that downloads Armbian and sells it under his brand name to make some profits, while we are project asking you to donate, so we can get at least 0.5% of our costs covered. Code you are using was developed by us, bugs are usually the same. And there are so many bugs in common code, where Dietpi does not contribute, that is impossible to follow. He didn't fix this, we broke this recently and he didn't copypasted those bugs from us yet. We do this https://docs.armbian.com/Release_Changelog/#v24111-2024-11-28 every 4 months. In past 10 years, we would hardly find records in any logs from their side. Please don't recommend such projects here even if it (randomly) works for you. If you don't support our work, for your and copycats behalf, at least do that. Solution to a problem can be found on forums as you are not the only one. With a bit more patience.

Try playing with overlays. It must be some that enables this. armbian-config -> system -> kernel -> Manage device tree overlays

This is my script: #!/bin/bash task(){ gp=$1 [[ ! -d /sys/class/gpio/gpio${gp} ]] && echo ${gp} > /sys/class/gpio/export echo "out" > /sys/class/gpio/gpio${gp}/direction echo "0" > /sys/class/gpio/gpio${gp}/value sleep 10 echo "1" > /sys/class/gpio/gpio${gp}/value } for doing this: https://www.youtube.com/watch?v=HxZ_FD5b5QQ on a very similar board: Linux nanopim1 5.15.93-sunxi installed nothing extra.

Disable suspend. Some (most) boards are not capable to get back.

Our sadness is in different dimension as we are wasting our private time to support your hobby mixed with business in exchange for mixture of bad. SW maintenance is never complete due to extreme complexity and constant (mainline Linux) changes. Supporting another hardware is a question of tens of hundreds of thousands of USD, not something we could finance out of what we get from users that will later just make more support expenses - most of questions is impossible to answer without deep and time expensive dive-in. This is custom hardware Linux world where manufacturers have little interest, especially this manufacturer, that you run anything else then what they provide (locked down). Mainlining of this SoC is often done without any documentation, assistance or support of manufacturer and hw dealers. I hope those links will provide you some guidance. Can't help more then this. Or to tell how big is the difference between sm8250, which this is for, and sm8550. Usually not much.

Impossible. This might help you: https://github.com/amazingfate/armbian-xiaomi-elish/wiki/Flashing-Guide

If there is a bug: https://github.com/armbian/configng/pull/298 then there must be a feature Perhaps there is still /boot/boot.ini ?... search in there.

Reading the A20 SoC documentation? tl;dr; That is not possible on this hardware as boot from NAND is not supported on modern U-boot / Linux.

I am trying to integrate this into the armbian-config to make this easier. Anyone gut lucky with this method?

Manufacturers can not provide dedicated end users support and especially not for something complex such as Linux (kernel). Neither we can, the quantity is too big. We try the best with this forum - the only support that is possible to provide. We also don't respond on technical support emails which are coming to Armbian emails round the clock. Answering of such emails would eat whole day, every day, 365 days per year. This is how community cope with errors ... 😃 plus publicly on this forum and elsewhere. We are just a small group that generate a financial and emotional loss by helping everyone. We have limits and I am sure they have limits too. Now you just need to find a person that is willing to fix problems you will report. Project sadly does not offer that, except if you take that persons utility bills. Until then, those are positions that project needs and afford to have: https://forum.armbian.com/staffapplications/ It is better, but ... most of community are consumers with too big expectations and are not going further then testing (which helps close to nothing as there are thousands of problems already recorded waiting for someone). Very little people are crazy enough to spent time for fixing common problems. (low level) SW maintenance is hard work. This is how SW community maintenance looks like. Most people, those who are willing to contribute, only has time to address minor problems, big remains. We, as a project, went further, while funding is far behind. https://docs.armbian.com/Process_Contribute/

They are back, but no warranty that images works as someone from community added them to the build system. Which are making them automatically ... and automation needs costly and constant maintenance for which we have very limited resources.

tl;dr; Custom hardware world is fundamentally different then standard desktop amd64 PC. HW designers stream toward uniqueness in order to stand out from another one, which cause after market software support, where vendor in question is not involved at all, nightmare. You will always be happy with a new toy they produced "and works fine" and unhappy with the only existing community aftermarket software support, which is abused by HW dealers and their customers. Demo software support is designed to give a feeling that what you purchased works well - and they focus into their special hw functions only with some old kernel. And this will only work if you don't change much. You want more recent Linux? Sure. But costs of that are insane ... and you (all customers / community together) are not willing to cover not even a percentage of that. But still you want & expect insane expensive firmware operations every day

Since you tried both. Any improvement over Armbian?

For this, use those instructions: https://docs.armbian.com/User-Guide_Autoconfig/

Yes. Rolling updates gets updates all the time. Here: https://github.com/armbian/os/actions/workflows/repository-update.yml you can see when beta repository is updated. If nothing breaks, every day, sometimes more then once per day, when the code changes. We can not distinguish if fixes are for certain board as they (32b Allwinner in this case) share kernel. tl;dr; There is nothing to worry about. You can also disable https://docs.armbian.com/User-Guide_Armbian-Config/System/#disable-armbian-kernel-upgrades this and only keep upgrading user-space packages or switch to stable repository https://docs.armbian.com/User-Guide_Armbian-Config/System/#switch-system-to-stable-packages-repository Sadly I can't tell you if this will make any change to this particular hardware, but you won't be bothered for upgrade until next point release. We keep those boards on rolling because we have no resources / funding to tag them officially stable.

Of course, once someone donates time to complete this https://github.com/armbian/build/issues/7656

Thank you, appreciated! It is based on Armbian kernel (usually binary) which is a big difference. All our kernels are patched and most of kernels are based on mainline. Some are patched heavily, some less. Stabilization of kernel stack is the biggest expense we have. Credits for our work are everything in this line of work and when someone takes them, it can't be worse. Explaining and fighting for our intellectual property is yet another stupid (common) loss. Mainline kernel is pretty raw which is causing constant troubles, which "based on Armbian, while telling everyone that they are based on Debian and mainline kernel" never have so they can focus on sales (of our work). I understand. This was not directed to you. "talk is cheap" while keeping things operation is something entirely different. Like I mentioned, software support is constant struggle and there is no way to address problems in real time, when people show up on this forum with it (and via emails that are constantly hitting our mall boxes). There are way too many of them and there is very very little support from general public, and there are people that, could help but changing wallpapers and taking credits is more profitable. Going for bleeding edge kernel is not a good solution as it always bring other problems - other features - we don't know - are certainly broken. What we generally do is - completing features on latest LTS kernel, which is 6.12.y, but to which we just switched few weeks ago and is expected to be stable-ish in about 4-6 months. Best kernel, in general, not just for this hardware, is (Armbian, mainline based) is still 6.6.y. Another way - If you seek for quick solution - we keep all older images in the archive: https://rsync.armbian.com/archive/ https://rsync.armbian.com/oldarchive/ Running older (kernel) builds is not what you / we would want, but there are no better options. Constantly changing mainline support is fragile and it will take months to nail things down. If you can help, welcome!

We mainly use Ubuntu Jammy / noble, native or virtualized. All those variants are automatically tested all the time, unlike Windows WSL. I don't know what it the status, but people reported some problems recently. VirtualBox (or similar) and Ubuntu Jammy / Noble is the safest way. Team behind is not professional, so I can't say when this will be fixed. But we are working on.

We have archives of old images https://archive.armbian.com/odroidc2/archive https://rsync.armbian.com/oldarchive/odroidc2/archive/ , but we don't have information which image is good in this function. This is on you to find out.