Igor

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.

I changed what you suppose to change, recompile, it works. It also works for many people and many automated scenarios. Strange ... but deep hidden problems absolutely can exist. Open a ticket here: https://github.com/armbian/build/issues and provide everything that is asked in that wizard. Then we might understand why you have issues.

We have two major changes at PR stage that needs to be merged and fully tested. Alongside with fixes on HW side. Then whole system stabilisation has to begun ... How you can help? Providing status of any board labelled as supported, that is not covered with our automated testings, helps: https://github.com/armbian/os#latest-smoke-tests-results This testing is primitive, so manual checking also helps. If there is a bug, open a ticket: https://www.armbian.com/participate/ If you can, fix it, sent a PR. Few people that contribute to Armbian anyway can't fix all bugs found in open source software.

Stock CLI image is already fully optimised, comes with configured ZRAM, everything is ready for you. Nothing more, that would have any noticeable effect, could be done. This is one of the core advantages of Armbian. If you have a fast storage you and your processes get OOM (killed due to lack of memory) then try to add swap file. If that doesn't work out, consider HW with more memory ... BTW, 2Gb that comes with C2 is plenty of memory for what you plan to do unless you will have "millions of records" in your database.

You are using some old randomly assembled development kernel. It is miracle that it worked this far. No development kernels receive end user support, because costs of supporting you goes sky high and you are involved in cost covering with cold 0%. Free hint: use unchanged OS from download section, which comes with a kernel that received things 6.2.3-RC3 never will = stabilisation. That is troublesome enough.

This information tells close to nothing. A picture of board would help to determine if any help is possible.

Once operational, remember to enable for nightly builds. I just added Rock 5 yesterday https://github.com/armbian/os/commit/c18ab86105e88571453afadf9dd72432a94b75b1

Registration https://id.atlassian.com/login is covered by Jira software. I just tried with some Gmail account and it worked ... Anyway, sent an invite and this should work ...

https://www.armbian.com/participate/ (register to Jira, open a ticket similar to this one https://armbian.atlassian.net/browse/AR-1803 assign yourself to AR-1803 and the one you will be creating for MT7915E solve both in one PR https://docs.armbian.com/Process_Contribute/ (specific instructions on what you need to do are in AR-1803) Its a great and simple way to make a contribution to the open source project. Once merged, changes will be automatically pushed to beta.armbian.com within <24h.

Sorry, don't know nothing about the state of openGL / QT. Making it easy and hiding complexity its the hardest part. Researching further is something you will do on your own, pay for or not know. I am afraid there might not be many shortcuts. Yes, I am familiar with Yocto. Been using it for years ... Yocto is a build system like Armbian and certainly does not support this hardware: https://github.com/armbian/build#compared-with-industry-standards They don't support any hardware, this is a your problem - they support build framework. Yes I do. Hire experts that will help you getting where you want.

Great. Spent some time to build OS for supported hardware to get familiar with the build framework. If board is not supported by Armbian, it can be complicated ... This HW is similar to Rock 3, but different enough that not all things will just work, perhaps it won't even boot ... and your are "very new" which means learning many new things but there will be problems beyond possibility to fix. There are no special guides: Google search? Forum search? Linux kernel mailing lists, Linux kernel sources ... If you look for something that is maintained, supported and you can rely to? I can recommend you to switch to similar hardware from our platinum section https://www.armbian.com/download/?device_support=Supported which has this property. If you have know-how, then you already have all you need: HW schematics can be found on Radxa Wiki somewhere and something is already in the kernel https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/arm64/boot/dts/rockchip/rk3568-radxa-cm3i.dtsi?h=v6.5-rc5 My 2c (will merge this with existing topic as this is forum and not a dedicated technical support)

It's a bug, yes. Working on it. @Pierre Lemmet Always viable workaround is = build from sources, community builds https://github.com/armbian/community

No, not possible. Yes, most of them.

https://docs.armbian.com/User-Guide_FAQ/#why-does-hardware-feature-xy-work-in-old-kernel-but-not-in-more-recent-one It is not possible to copy / paste from old kernel (where this probably works), but it often needs that it has to be developed completely from scratch. Which costs real money (not charity / beer) as nobody can dedicate weeks or months of their private time to fix something he doesn't need ... Code difference between vendors dirty hacked kernel 4.4.y and mainline 6+ is often extreme. Alternative is waiting.

Starting from: https://github.com/armbian/build/commit/8278dc5e4215a84492dbe297fe243b878a60aaf4 Ref: https://github.com/crust-firmware/crust https://linux-sunxi.org/AR100

Looking at the code, the only improvements is that it will (probably) compile and work on K6.0+, while quality will remain the same. Search on this forum for more topic associated with xradio, xr819, wireless on zero ... to understand how much time was already wasted for nothing. If you are not an expert in wireless networking that you will dig deep into the this chip in particular ... rather do something else. Perhaps extend driver we use https://github.com/armbian/build/blob/main/lib/functions/compilation/patch/drivers_network.sh#L229 to be compatible with K6.0+ https://armbian.atlassian.net/browse/AR-1486 which is adding few last commits from fifteenhex repo. Most of those drivers, and especially those that were delivered immature, are maintained with minimum effort. Nobody has months of time, knowledge and equipment to fix everything what is wrong ... (Sorry for being honest) It should work on Armbian for Armbian. Orangepi is using some very old variant of this build system and hasn't been updated since. tl;dr; Armbian is much better then what HW vendors are able to deliver.

As there is some WIP on our repository side you need to workaround this - make an image with enabled HEADERS and then it will work.

we never have dedicated for m1+ Use https://www.armbian.com/bananapi/ and perhaps change DT to m1+ if it exists in /boot/allwinner/dtb

No, just some bug that prevented its re-creation. As you can see, we have bigger exotics in the pool https://imola.armbian.com/apt/dists/