Igor

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/

This was never even planned nor IIRC anyone asked for in past 10 years. End users usually doesn't need this kind of automation and if this is for your business, welcome to become a partner (cover some of expenses you are generating) where chances for resolving moves into positive direction. Here we are collecting ideas that make sense for everyone: https://forum.armbian.com/forum/38-feature-requests/ and that we can sponsor or finance from public charity: https://liberapay.com/armbian Every line of code is for project maintainers a liability and someone has to maintain it. The part of the code mentioned by @robertoj was introduced some 6-7 years ago and the one adding is long gone. We have many such cases all around and we all want that code doesn't have bugs and you want all this is free for you. This is hard to achieve. One way to patch this problem is by finding volunteers but very very few people are interested in doing this hard work ... Its not that difficult to resolve this, but we really can't do anything anytime soon, certainly not within one year, as we have many other things, that are important for everyone, in plan to resolve. https://docs.armbian.com/Process_Contribute/ Develop, test and implement a feature you need. If it will be done quality enough with low maintainace expectations and / or unit tests, PR will be accepted, else not.

You can find a working example within this script: https://github.com/armbian/scripts/blob/devel2/.github/workflows/build-test-image-docker.yml

OP was not using official tools and Odroid N2 is different beast. If you need that the problem is found and fixes, you need to provide EVERYTHING. Whole procedure on what you did and provide all logs you can ...

Another explanation. Every distro is maintaining their own kernel config. We (try to/have to) maintain 65 kernel configs ... and what you are asking is impossible to pay attention to. I have open a task https://armbian.atlassian.net/browse/AR-1803 but our capacity is pretty small and it takes 4 years on average that task is closed. To give you another perspective. And most of other Linux distros are just worse in this. They simply say - its upstream problem.

... Armbian bookworm. Everything that is important is coming from Armbian. We keep relation to upstram release name because standard user land packages are coming unchanged from Debian. But they are assembled different as on stock Debian. Networking is ours, first install, installation, ... A lot more is changed then on most of Debian based distros. There is a way. Build kernel, dtb and headers package with https://github.com/armbian/build and install to your image, reboot and then proceed as what was your original intention. It looks like its just not enabled. When you will be compiling kernel, enable this https://github.com/armbian/build/blob/main/config/kernel/linux-rockchip64-current.config#L3362 and perhaps that will be enough? You are welcome to send a PR to changes. For externals - DKMS is nice as - we provide mechanism, you deal with the rest - bugs in the driver code that prevents compilation. We cover many https://github.com/armbian/build/blob/main/lib/functions/compilation/patch/drivers_network.sh but adding and maintaining represent serious commitment.

Even almost nothing usable works, when first bits of CPU support is merged to the Linux kernel, such news is produced. It can take years before chip is actually usable and sometimes support never become usable. Here this is not the case as its a popular chip and support is being developed, just procedure to get into the kernel is rigid, takes time. Term "officially supported" by Linux is IMO very overrated and not sure this term exists at all. Armbian mainline based images for 3588 are floating around forums, but ofc no official supported builds with modern kernel yet.