Igor

I assume you achieved this performance on cca. 20 x more expensive Intel based hardware? First lets rule out user space. Try Armbian x86 https://www.armbian.com/uefi-x86/ on that. None of this was ever officially supported. And those are 3-4 years builds from 3rd party repository. Armbian makes tools for making custom OS and this was made by "someone" from a vendor kernel that is deprecated in years. I can only give you general advice. - develop image around modern kernel ( config exists but it might not work https://github.com/armbian/build/blob/main/config/boards/sunvell-r69.tvb and https://github.com/armbian/build/blob/main/config/boards/rk322x-box.tvb) - use hardware that is capable of achieving this Good luck.

Official FW is old and re-branded version of Armbian. Without any updates and maintenance for years. Official FW: https://github.com/orangepi-xunlong/orangepi-build/tree/next/scripts Armbian in 2022: https://github.com/armbian/build/tree/v22.08/lib We provide archive for (almost) all previously stabilized images: https://archive.armbian.com/orangepi3-lts/archive/ which are in better shape, but update might break them, so freezing of kernel is required.

Release is not a warranty that all bugs get fixed. That process takes several years and new bugs are keep getting introduced ... proper maitainances keeps this low. Here https://github.com/armbian/linux-rockchip/commits/rk-6.1-rkr4.1/ you can monitor what is getting merged. Rolling update just ships this few hours after merge is made in automatic way.

Please test with both kernels, 6.12.y and stock 6.1.y and then propose changes: https://github.com/armbian/build/blob/main/config/boards/nanopi-r6s.conf#L30-L34

Debian on PC and Debian on SBC is quite different. Userspace, the less relevant part of OS, is coming from there, yes. Ubuntu userspace is, on the other hand, more polished, usually with more updated versions of user space librarires. In tl;dr; its better choice. In the process of OS assembly, we remove Canonical stuff, which means our Ubuntu is more or less the same as Debian, just more polished. Kernel is responsible for most of the troubles people report on this forum / have with those boards. And that has little in common with Debian and Ubuntu. Their kernels mainly don't even boot. And when they do, people would only have significantly more troubles in the area of interacting with hardware - low level instability such as you experience. Then mainline based kernel should be what you are looking after. I have two such machines (Rock 5b), with SSD drives, running GitHub runners. We assemble images on them. They are in production for about a year, running some old test version of mainline kernel (Linux 6.7.0-rc1-edge-rockchip-rk3588) https://paste.armbian.com/fibacokoji

This is the script we ship by default with this hardware. And IIRC it use to work as expected: - spin up at boot is by a purpose, like a check that dan is in operation - when temp goes up, it should spin up It is possible that something isn't working right anymore. Perhaps try to ping author: https://github.com/armbian/build/blob/main/packages/bsp/nanopim4/nanopim4-pwm-fan.sh#L6-L7

Many bugs remain unresolved for years and we, by any means, are unable to have complete bug-fix overview in such a complex world. We can only try to keep some tracking: https://armbian.atlassian.net/jira/software/c/projects/AR/boards/1/backlog https://github.com/armbian/build/issues and resolve when possible.

He supports "everyting", while a team of 50 people, is unable. Who do you think is cheating here? https://docs.armbian.com/#comparison This is how he supports it: He download everything that is valuable from us https://docs.armbian.com/Release_Changelog/#v24111-2024-11-281000 while fixes that somehow finds the way there, they never gets here. Talking about years of work, not this particular fix. We take support serious as we can't steal the bulk of work from someone to mitigate all sorts of troubles related to hard work (burnout, lack of food, etc.), while when you just for fun sale someone else work, this is not a problem. https://docs.armbian.com/User-Guide_Board-Support-Rules/ A small team can only support few boards, the rest is "community supported". By you. Or by nobody. tl;dr; If you add a fix to Armbian, he gets it, we get it. If you sent a fix to him, we don't get it. Image for Odroid C1 is identical to ours with your fix. He doesn't add any fixes to it, besides what you provided. But its "supported" by dietpi Actually all important fixes in this platform was done by us https://github.com/armbian/build/commits/main/patch/kernel/archive/meson-6.1 which means we provide bug fixes even we don't declare hardware as supported. All fixes that gets to Armbian are integrated at once and update is auto generated within few hours, images once per week. https://github.com/armbian/community This is exactly the same support level as other distros, including Dietpi.

Try to rework the script: https://github.com/armbian/build/blob/main/packages/bsp/nanopim4/nanopim4-pwm-fan.sh#L316 Perhaps expand it to support selecting CPU / hard drive ?

If you didn't fix PCI driver, it must have the same isssues. But its good to know / sad to hear, upgrade doesn't fix this. Again you want to beat our recommendations This is (close to) embedded Linux. You have to use, what we tell you to use. Or learn the hard way ... Debian is in worse condition (only on this platform) and there is nothing we can do about. Except removing it. Chromium is broken for few weeks and it will remain broken until Debian fix it ... while Chromium for Armbian Ubuntu is compiled and provided by us. And it works. Workaround is installing previous version, but you will anyway lack video aceeleration. But it won't crash. Remember to include right extensions: ENABLE_EXTENSIONS: "v4l2loopback-dkms,mesa-vpu" or experience will be bad.

There are some troubles, some caused by us, some by 3rd party. Improved mechanism is about to be merged https://github.com/armbian/configng/pull/308

Providing a tool means nothing, What about the most important part, organising and leading? - regularly promoting that we have this and how this operate - establish and maintaining a team of people that will do that. developers don't have time for this and will mainly not cooperate - you need to talk with those people on regular basis - you need to contact them 3 weeks before you need feedback, and a week before to remind them what you are looking for - you need to thank them for helping you - this should not be 1 out of 100 projects you are running, but a project you do in your free time. ... and on and on. This is not technical problem, its organisational one.

There is, but one need to follow forums and GitHub issues to catch everything. If we (which includes everyone) would like to keep download pages updated with this, we will need to do something about. I already do more what is possible. It is complex to assemble and forward right bits of information at right time to right people that needs that information. Bugs are constantly changing information, so we are looking at serious work, nothing what we can finance. Also some bugs are fixed fast and if we already have no resources for fixing bugs, how we could possible have for a complex info system? :) One alternative is official news channel. Currently we have three people working on preparing weekly newsletter. If they didn't catch this on their own, its not published. And last one mention some other problems for example https://www.armbian.com/newsflash/armbian-weekly-highlights-5/ There are many bugs in open source software that are pinned on us and we also produce a lot of code. This one is ours, yes, but its also free software, best effort and what comes with it. WIP https://github.com/armbian/build/pull/7542 More are waiting for good Samaritans: https://github.com/armbian/build/issues Anyone can establish this. I tried that in several ways, but except few people that did testing there was no help in the most problematic part - organizing and leading this operation.

I am afraid this is current state of Rockchip vendor kernel. PCI support works, but its unstable. Just FYI - we needed years to stabilise PCI on previous RK3399 SoC. Situation there was just worse - we were contracted by one of the vendors to do this, so we invested more efforts, but they "forgot to pay" for services even they were backed by contract ... damages to our work helping you is done also by purpose. Workarounds is - cold reboot few times, trying to use some older kernels, where PCI is stable, but there are other problems. Waiting, supporting our work is solution, but that both is hard, when everyone expects software support perfection - that everything just work

Minimum of this is that testing is done at major kernel bumps. We are switching to K6.12 with CURRENT branch, which is main objective and where things will break down for sure. This has to be tested and fixed (if possible) in / by the next release month (2/2025). Them we will stay on that kernel for some time and little will break at 5 and 11 / 2025. We would like to have "supported" boards at least tested. If images are broken, telling that we know that and we know someone is working on it, also works. Perhaps someone else will show up and help around this ... Its more like a grey zone as this is for most of the people a hobby. Yes, better.

Nice to see that you managed to put our build framework into good use! Build configuration can be .conf, if you plan to keep it maintained here, else it can be .csc (community configuration). ! tl;dr; version of support policy can be found here https://docs.armbian.com/User-Guide_Board-Support-Rules/ Code wise, not an issue, all of it, until it met common coding standards (quick check = it does) and that it doesn't break anything else (which I also believe it won't). Remaining problem is the instructions part ... We currently don't have any, not right, not wrong place in the documentation to keep that kind of things well organised. A comment with URL in board config file can do for now. Most of contributions to Armbian are done in similar way.

Also try some older builds. We have one of this board in the automated test system and it works fine. https://armbian.atomonetworks.com/archive/bananapim2ultra/archive/

No But I have advised someone, that wanted to complete this ("over the weekend"), correct path: https://forum.armbian.com/topic/38443-no-gpio-on-bpi-m4-zero/#comment-206453 https://forum.armbian.com/topic/47139-banana-pi-armbian-buildsystem-development-team Its a lot of work to develop such system. At least with current team - which is already busy over the top. Once this is developed, integration and maintenance is again above our resources. But if someone will start this, we will support this however we can.

@Maurycy Developers says "it should be fixed with latest kernel". I assume you have ran apt update and apt upgrade to get to the very latest version, more recent then shipped with image?

Scroll down to the bottom of the page https://www.armbian.com/radxa-rock-5-itx/

I think the only kernel that will be good is previous version of 6.1.x, probably v24.8.something ... I don't have this information / hardware to provide exact information. But it is this way: armbian-config -> alternative kernels Or previous image from the archive.

Regressions in software development are totally normal and expected. You need to understand that even we declare something supported that it only means high level of software maturity and has a named maintainer https://docs.armbian.com/#what-is-supported and those are targets where we don't produce extreme damages to our personal finances. Since we create a value for you and its free for you, our loss is inevitable. Supported means, problem will be addressed, while on non supported targets, bugs or even total collapse of support, won't be addressed. Our assets are limited and we can not grow them with public support. I will be be honest with you. Perfect functioning at all time, that is not possible, no matter what we do. I mean in theory, if we throw into the project 50 x more and generate 100 x bigger loss, perhaps. But that is stupid, insane and pointless. And this should be your job, not ours. When we fix this for you, something else on some other hardware will break. And here we go again And this is the case here. Functionality works, but its unstable. After several reboots, cold start, it will come up. I know this is not right or expected, but this is how it works at the moment. If current kernel shows instability in a segment that is important to you, switch to the one that works. I do the same on my x86 mainstream hardware Linux desktop workstation. I have a bigger problem then you. Ubuntu kernel broke my network device (which is not nearly some cheap one), so if I upgrade, my network is gone ... I have to workaround by connecting to wireless and install older kernel version (or gamble with trunk build where my graphics card or Bluetooth will broke) where my network card works. This is fixable, but I don't have a day / week / money to fix this. This is Linux and this is how things are. Are people that work for free to blame for this? Use previous kernel. We made this choice very simple. And at least cheer us.

This forum has very little to do with openwrt - try here https://forum.openwrt.org/

The problem behind their promotion statement is that its a scam. Dietpi is bloated with proprietary scripts and they are removing packages that are dependencies for everything ... so it makes no sense at the end, just first installation of anything takes longer. But they can claim images has few MB less ... which is "better" and most of end users have no ability / interest to understand they have been conned. https://docs.armbian.com/#comparison Damages they create to open source, by playing dirty, that is beyond commenting. This should also work OOB then https://www.armbian.com/uefi-riscv64/ and you don't need to remove anything (from minimal Bookworm OS image, which is significantly lighter then Dietpi). If you / anyone can confirm they are working well, we can move this to Supported section.

Its a feature We decide to leave this utility on development branch (there is separate armbian-config.list in the source folder) for awhile to speed up with the integration. There is a lot of automation that is helping preventing shipping broken app. And the app itself is very simple compared to everything else.