Igor

It is working for us. In case you have further questions make sure to get item on your right. Next year we will hire some people that you will be able to hire for individual support. We can't fix your system or help you more.

My estimation is based on general knowledge and experiences. For proper research I have no time. And you can do that as well. Ask people that are already working on - we are working with different hardware, which have only general similarities.

"Focal" has almost no value or relationship with stability of the system. It has to be some other difference. Since you have provided no logs, can't tell. Especially we need to see which u-boot you are using on one, which on another.

This usually works on official Armbian builds. On not official Armbian, who knows. TV boxes Armbian are community work / mainly just hacked together. Your topic was moved to the TV boxes club, where is the place to ask such questions.

Thank Jernej. Fixed, but I also can't test. https://github.com/armbian/build/commit/f83100f9af5f5b8ef5a0b083e39c382763e2e86f

There is nothing wrong on our side - we just don't build and publish our package upgrades for Stretch repository anymore. (automatically) Only for those marked as supported: https://github.com/armbian/build/tree/master/config/distributions Support from Debian ended 01 Jan 2020 and I assume kernel upgrades, which are anyway coming from us, are at Stretch going to die June 2022 (this info is extracted from quick search on the net, so its not official)

I trade my skills for help on tasks that doesn't require so much skills, but they still require time and attention. https://forum.armbian.com/forum/54-help-wanted/ Currently working on sunxi bump to 5.13.y but since I am on vacations, my wife can interrupt this violently If time permits, I'll try to fix this, but can't promise.

Probably you need to expand screen resolutions within display driver, yes. I would assume there is no support for such size so parameters won't do any help.

Another option is to boot images from archive.

As from today any testing on nightly (and RC when they will be ready) images helps on nailing down bugs. Our automatic testing procedures are happy, but they are not yet on the level we could fully trust them. We still need to see some random manual installations and this can only be done together Checking if we have done it well.

Important and critical problems, which have much higher priority, can be sometimes solved fast. If you have already spent weeks to understand what the problem is. Most likely, since it still needs testing.

Regression in u-boot. Will be fixed in sources when this https://github.com/armbian/build/pull/3036 is merged. Images and updates are going to be updated soon. If you need faster.

Expensive bare-metal approach? IMO hardest part is to support already moving initiative with a few of additional Hector Martin clones . Provide that team whatever they need and trust they will deliver ... Since a full dedication is needed to get somewhere, you need to find a way to feed this team for a year, perhaps two. I think currently only Hector have a pay. And count that they might miserably fail as well. Its a long term project and having "Armbian representative" in that project as an observer is already valuable, so early implementation can happen. Once developed far enough. Currently, AFAIK, it is not developed enough to be useful. But I don't have much time to pay attention. That job has to be done by someone else.

There are many reasons why people produce open source software. Master skills, knowing people, serving people yes, but you risk being eaten alive for peoples egoistic and business goals. Users are welcome to use our software but "no support" is a default answer. Going out from this zone is disrespecting from the users side. You got free software, but if you want attention, well ... in our case, I have an universal answer, there were 1000 people before you asking for attention / help. I would like to help, but it will be some time to wait. Since you don't pay for support, we can't expand and since we can't expand you need to wait years to get attention. Cruel, yes. But in most cases you will understand what you are asking for. People that sales hardware will always say the opposite, just to support sales ... There will be bugs, yes. All Linux distributions distribute a package of application and drivers that are a work of lets say 5.000 people. Or ten times more. It doesn't matter. When you approach to us and demands that we fix a bug for you (which usually nobody else will) especially in a software we have nothing with ... why on earth a bug you found in software package number 12496 is our problem to fix? There is no way to respect a user when approaching that way and educating users (explaining this in proper way) is expensive long term never ending job - when I hear "I am new to Linux" I stop reading - I am too old for this. Again on our costs (only what we like to do is not considered as a cost) since it happens that users doesn't pay for education. Why should they? They even refuse that need, since they think they are the smartest people on earth since they know how to use Linux. Even on some weird ARM single board computer ... In our world we have a lot of pleads like: hey, video acceleration in Chromium is not working, display driver via usbc is not working, board stuck on reboot (Odroid boards for example and 100% Hardkernel problem to fix which they ignore since its expensive to fix and it happens they mitigate this in their cheap dirty firmware). "Can you please fix it". A week later, more anger demand please fix it! Is it point to explain that person, that fixing that will take months if not years and cost lets say 20.000, 500.000 EUR or more and which is the reasons we will not even start. I am long enough in this world to understand how much something costs, so I don't allow that users will lead us into their small world. Big projects are never covered by amateurs, professions if there is enough of resources and if there is business case to cover. Not always is (in Linux rare is), while people / users have big eyes / demands / ideas. Just not providing any cash. Economic relations are always in actions - it is a difference when users ask politely and with respect, but the problem is that a lot of users think it is our duty to serve them and invest our money to fix software they use. Why don't you just fix it? Its open source, provide a fix. In most cases costs for fixing are too big. Also for those big groups you have in mind. They don't even come close to this world if there is a bag of cash on the table. Bugs on all Linux distributions can easily be opened for years before anything happens. I know our product is not perfect, but product you are referencing is not even close. Vendors software support is without exceptions full of quick dirty and non standard solutions. Ofc they will make everything for you to persuade you to believe into something different. Armbian is community projects and have broader support. Developers you see around are also maintainers and those are doing the visible job very little will. Developing is fun, while this is also hard but boring job. Vendor usually forward what it comes with the SoC and are dealing with everything so they look big (Ubuntu, Debian, Android, Librelec, ...). In Hardkernel's case, they used to stick to junk private firmware (on C2 probably still) while everything else is a forward what community projects are producing. In most cases vendor support is not on very good level. Similar other projects are one or two persons in size. From the surface, everything looks the same. Maybe in a few years you will learn enough to see the difference? Perhaps not.

Armbian is a build system first, cheap ARM hardware enabling second, OS 3rd. We construct user land from Ubuntu and Debian packages since early days, could be said from the day 0. We always provided both because of things as such - bugs and to not deal with user land - let user choose what he needs / prefers. We - those few people - that are investing our resources into common software development, can't afford to fix (all) bugs that showed up. That is not possible by greater Debian community or open source community software in general. Certainly not by corporate Linux flushed with resources such as Cannonical, RedHat, ... even they could do a lot more. We are using carefully selected packages. Cancer, which you are afraid from, is removed in the process - but surely it could return for short time. My x86 workstation is running Linux Mint, which is also assembled from Ubuntu packages, using their repositories. My personal and also very much Armbian philosophy is - get from Ubuntu what is good / was improved, leave everything else and make a new, better OS. In our case, this is even more extreme, since most of the hardware we deal with, doesn't even boot Ubuntu and we maintain our own kernels. The most expensive part of the OS. Maintenance responsibility and costs. We are trying to keep things minimal (we only need one image with latest kernel, user land is less of importance) & manageable, low entropy ... and IHMO we are already failing. I work 6-10h on this project every day and there is not much to notice. Contrary. It looks like we are not doing anything, not answering on bugs, not answering on problems, not porting hardware, I don't answer on personal request ... People, everyday Linux user, usually have absolutely no clue whatsoever how much work is needed to fix a bug, to develop this and that feature, enable some hardware ... to keep a project as ours operational, that moves on.

I am sure HW sellers demo OS level creations are full of bugs, but perhaps not this one. Thank you for your support. Use Ubuntu based Armbian since it seems bug is only on Debian derived builds. https://docs.armbian.com/#what-is-armbian

Find out which driver is needed and has to be enabled in: https://github.com/armbian/build/blob/master/config/kernel/linux-rockchip64-current.config https://github.com/armbian/build/blob/master/config/kernel/linux-rockchip64-edge.config We have enabled a lot of things, but not everything ...

In open source world we usually just compile program for certain architecture. Check with your software provider if / where sources are available and compile for aarch64.

First try latest edge build. Our test board is just fine: ___ ____ _ ____ _____ / _ \| _ \(_) _ |___ \| ____| | | | | |_) | |_| |_ __) | _| | |_| | __/| |_ _| / __/| |___ \___/|_| |_| |_| |_____|_____| Welcome to Armbian 21.08.0-trunk.32 Focal with bleeding edge Linux 5.12.15-sunxi No end-user support: untested automated build System load: 2% Up time: 1 day 18:21 Memory usage: 4% of 1.97G IP: 10.0.30.112 CPU temp: 86°C Usage of /: 9% of 15G [ General system configuration (beta): armbian-config ] Last login: Sat Jul 17 00:42:50 2021 from 10.0.10.8 root@orangepiplus2e:~# cat /sys/class/thermal/thermal_zone0/temp 79189 ... but since you said you tried 5.12.y and all others is seems something we can't help much. Custom mitigation to ignore sensor values?

Another bump of forum software to v4.6.4. What's new: https://invisioncommunity.com/release-notes/

Perhaps too much current went via power delivery chip? I assume you had no cooling provided for any elements on board and summer is hot? SoC powers off if temperature reaches critical levels, for AXP chip I am not so sure about. So it has some protection ... but not all chips have same temperature resistance or act of powering off doesn't work properly when powered via OTG port? Get a schematics and try to reason. Powerbanks usually don't provide random output also Armbian have no tendency to fry chips

There are more ways: 1. Wait for our next release, when images are rebuild, tested and fixed for other possible problems https://docs.armbian.com/Process_Release-Model/ 2. Easy DIY - build your custom image by using our build tools. Workaround is already applied there https://github.com/armbian/build 3. Harder DIY Clone boot loader, find instructions for changing it and apply to the image from download section / your not very well working system on your SD card. We also provide nightly images, but u-boot is not rebuilt each time - we use the one we have build before. A task is open on this topic, just time to code and test that needs to happen.

Another try. Hopefully it will last forever and after.

It was fixed for a day or two but it broke again. This means quick fix doesn't work well, while serious and expensive time slot to tear down this complicated mechanism can't be allocated just like that. If you want that things works smoothly, you should not leave also costs of maintenance on our shoulders. We already blow too much on R&D and are crying for help, repository management tool authors as well, ... Even this is unrelated to the problem from the topic - your hardware (Rock64 due to quality issues) and software (Armbian Bionic is old LTS) and the way it was build (user-built / support is only for digitally signed releases) is not eligible for support we / armbian maintainers pay for you. We can't cover. No ETA. It is urgent matter and will be fixed accordingly. With another quick fix, I am on vacations.

This problem should be resolved. CDN needs several hours ... so perhaps not right now.