Igor

If you opt for 1 year for Community Hero, you are not going to cover damages your request made to our non-profit organisation: https://forum.armbian.com/subscriptions/ We fixed the problem and it will be released when possible. root@orangepizero:~# iperf3 -c 192.168.29.129 Connecting to host 192.168.29.129, port 5201 [ 5] local 192.168.29.132 port 41820 connected to 192.168.29.129 port 5201 [ ID] Interval Transfer Bitrate Retr Cwnd [ 5] 0.00-1.00 sec 2.08 MBytes 17.5 Mbits/sec 0 106 KBytes [ 5] 1.00-2.00 sec 1.93 MBytes 16.2 Mbits/sec 0 136 KBytes [ 5] 2.00-3.00 sec 1.86 MBytes 15.6 Mbits/sec 0 136 KBytes [ 5] 3.00-4.00 sec 1.68 MBytes 14.1 Mbits/sec 0 136 KBytes [ 5] 4.00-5.00 sec 1.86 MBytes 15.6 Mbits/sec 0 143 KBytes [ 5] 5.00-6.00 sec 1.86 MBytes 15.6 Mbits/sec 0 143 KBytes [ 5] 6.00-7.00 sec 2.05 MBytes 17.2 Mbits/sec 0 182 KBytes [ 5] 7.00-8.00 sec 1.99 MBytes 16.7 Mbits/sec 0 228 KBytes [ 5] 8.00-9.00 sec 1.74 MBytes 14.6 Mbits/sec 0 228 KBytes

AFAIK modern kernel doesn't have support for NAND (at least not all variants that exists) and you need to add it.

I don't know. Just speculating - it has to do something around boot area / low level init as Armbian works normally on 1st class / right hardware. Armbian comes in single partition in most of the cases. That is nothing unusual and not a problem.

We only deal with R&D of mainline based kernel here. Copy pasting their kernel doesn't add much value. We dropped, legacy Rockchip made and maintained kernel 4.4.y / 5.10 perhaps now, some time ago. With mainline, things are much more complicated and expensive. It is very hard to lead R&D with almost complete (99.5%) absence of people that needs this software support and where ROI is extremely negative. What is provided is provided with very limited resources and we are very close to abandoning this very little what we have. There are more (unknown number) different board revisions out there which just adds costs, waste more of our most precious resource - time. They have incompatible boot firmware that needs to be adjusted. Our device in automatic testing facility show instability ... It boots, but doesn't survive many reboots. There are 100+ similar HW cases around with their own pros and cons and only X hours per day we can work on something.

Welcome! Possible, officially not. Some people made some experiments, do extensive search on forums and around. Android? We don't touch it here ... Good luck. If you are coming from Gentoo world, you must dive into our build framework. Perhaps you can give us some hints: https://github.com/armbian/build Universal ways are, like mentioned, in experimental phases. Can't point you to any solution. Absolutely no doubt about. There is nobody but spam bots, Radxa forums are better but also pretty not moderated and mainly populated with repeated novice questions. - they have nothing to do with MESA - they ship and maintain (usually with 1-2 people) kernel they got from chip maker. They are behind legacy kernel development. - support they provide is mainly leaned to community. Profit margins putting SoC on PCB are not enough to cover wasteful end user support or extensive R&D. In most cases support is done by their clients if there are any. Just like with Raspberry Pi. Or sponsored by groups like ours. Some vendors afford to cover for a person on their forums, mainly not. In contrast - Armbian is more developers oriented community towards mainline based software oriented community that is above vendor specifics. Panfork is hacked unofficial one man fork of mesa that is not recognized and approved by upstream. Google if you want to understand dirty details ... But if you don't care, use it. It works, just adjust expectations. Yes. We are getting there too. I am already experimenting running GitHub runners on 3588 devices with mainline kernel. Headless is conditionally usable to some degree, but if you have questions ... download and play with it. If something you need doesn't work, don't waste time asking. Its almost certainly not developed yet. Also worth checking: https://docs.armbian.com/User-Guide_FAQ/

Do not change OS.

Until we fix website https://fi.mirror.armbian.de/archive/ You can also try and build image with latest kernel / userland https://github.com/armbian/build

https://www.armbian.com/download/?tx_maker=radxa It is there, just default link from forum goes to "Supported" by default. Probably better to change to all ... Supported download list = 1st class Armbian community support, where we have a dedicated maintainer. If there is none and if vendor doesn't help team of developers that maintains this code, support is declassified into community support. Which means images are assembled, but nobody dedicated look or care to fix troubles. Anyone can submit a fix and it will be integrated at once. If you don't know how but you need something to be fixed, we can help you find someone that will help you in exchange for something ... This is the same as most of other Linux distributions "supports" those boards. We takes "support" more serious. If Armbian Linux can boot on some device, this doesn't mean "Armbian supports it". Usability and quality of working has many different areas.

Expensive research is usually needed to fully understand why this is happening. But as most developers knows that Rockchip legacy kernel is a consumer demo-grade trash, its unlikely this will happen. Repairing deep problems just for this kernel is usually futile. It is not Armbian problem, but Rockchip's which provides this fork and currently the only stable(ish) kernel you can run on those devices. It is worth trying to build image from latest sources. They have been greatly improved, but can't tell if your problem will be gone. I assume you are using stock power supply? Not sufficient power can help in crashing ... If you need to run some serious things on your device, move to test 6.5.y kernel (CI builds at the bottom of the page). This is the only sane way, but they come without video output. We are running several build runners on few Rock 5 devices and so far it does the job. Here are logs: https://paste.armbian.com/gupidarusa BTW, Welcome!

Debugging and fixing is not automatic. You will need to fix it first. When your fix will be merged, then new build will provide fixed results ... It could be this.

Try latest images from CI automated build section - should be fixed by now. Stable images rebuild = soon. https://www.armbian.com/download/

https://docs.armbian.com/User-Guide_FAQ/#why-does-hardware-feature-xy-work-in-old-kernel-but-not-in-more-recent-one

Yes. Vendor kernels are traditionally a pile of sh*, as cheap production as possible. We provide images with experimental kernels v6.5 to try out (at the end of download page). There it might work, but don't complain about several non/badly working things - its not production quality / stability. We are running several GitHub runners on two devices. With vendor kernel, this job was very fragile, while here, so far, it just work.

Welcome to Armbian community support forums! Adjust expectations ? We also need to. Even small group of contributors are throwing thousands of our hours into supporting you, this is not on the plug and play Raspberry Pi level. Developers base here is smaller facing much bigger hardware diversity. You don't have many options. Stock, Armbian or Armbian based OS (with the same problems). I believe stock is best at such things, but also on Armbian this should work ... just analysing and fixing is perhaps not on the consumer grade time frame. Support, where 99% contribute with demand and questions, can only be best effort. Next time, when you will run into problems, provide logs, try to help someone in between, make friends. This helps you most when you are in trouble.

Strange. Vendor asked us to update images with new boot loader that should support most recent board revisions with new memory chips. I don't have that latest board, but those images are: - automatically tested on stable and unstable kernels https://github.com/armbian/os#latest-smoke-tests-results (no issues found, but testing is limited) - manually tested Bookworm with Cinnamon desktop (this) on M2PRO (which is identical to M5, just different size and comes with onboard wireless) . Logs https://paste.armbian.com/elogateles For further diagnosis: - console boot log - pcb photo

Now unpack both files (DTB to DTS) and run diff on files. That might reveal some clues.

Sources are here https://github.com/armbian/build Take a look. To be sure to be ignored? Your second identical post was deleted as its obviously against the rules. This is community forum, not a satisfaction machinery or customer support mixed with forums (Radxa, Odroid, ...). You are not our customer, Armbian community or maintainers owes you nothing. Here we help each other. How you can help? Be different. Look around if you can help someone ... or act shocked on my patronising. Welcome! 🙃

That is off topic. But if you brought that up - I show you opportunity to help changing precisely that problem, to help yourself and others that helps you with very little problem, where you can't say "I don't know, its too hard", as this is the only way things can improve. Armbian team, people you hate because they don't provide you top software, lost 100 hours every day, donations covers perhaps 3-5 minutes. Everything else we need to cover with our private resources. This also bring a lot of FOSS predators they are stealing in organised manner, including vendors. Some are playing very dirty. If few people would add their small contribution, like this one, without me spending hours and hours trying to convince you to help yourself, that changes a lot.

Are you changing kernel version with a patch?

So you managed to build a good image after all?

This script works (almost) on any .deb OS and also on Windows / WSL, x86 or arm64. Build system is containerised and container inside container is calling for troubles OK. Perhaps rather focus on this part and try to make a PR for both WiFi chips. Enabling this module is certainly not a reason why board doesn't boot. It can be your build host or there is some f* up in around u-boot. What about nightly / rolling releases from bottom of the page - that is fresh https://www.armbian.com/rock-3a/ Do you have a serial console perhaps? First build system didn't work on weird host, now image doesn't work. Well, I don't have this hardware, can't check. Perhaps @vamzi @catalinii @ZazaBr @amazingfate can provide some hints - is latest build working well or not. P.S. As you can see, in software development, we can easily blow a day achieve nothing (except learning for those that don't know this)

Exactly. You can get first hand information only if you will be investing your time to help us: https://www.armbian.com/participate/ If you will be asking from users perspective, "access denied" comes by default. We are not Lenovo employees or contractors.

Image is not made by installing .deb package. You need to use https://github.com/armbian/build and you will receive no support. As build target is not supported. You should also find that in the documentation. Not just your rights. This world is not as simple and organised as x86 Debian world you must be coming from ... sources are on Git. We don't hide anything, just support is extremely limited. Next cycle perhaps. https://docs.armbian.com/Process_Release-Model/#release-cycle

No. This task was assigned to general public as we are completely overloaded with work. If you (anyone) will not provide a PR, this will not get it. I don't need this feature.