Igor

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. Why should be there in first place? Every code we are adding is liability and maintainers, you don't support, can waste a lot of time by doing that. DKMS is nice as - we provide mechanism, you deal with the rest - bugs in the driver code that prevents compilation. Almost no Linux, especially not Debian, is providing modules for new or obscure hardware. 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.

There are few problems associated with a small problem you have. Lets just name a few: - we are afraid to push out kernel updates and potentially break thousands of deployments. We can't test those upgrades well enough and because we can only do partial upgrade at this moment. Yes, I know you will offer help to test, actually a lot of people does, but when we ask "now we really need your help to test" just a few does and we are again down to our too small in-house testing and automated testing, which nobody wants to help us maintain. If its not maintained and developed, automated testing does not help. We need constant help from you and also deal with this problem on the level I am mentioning. Many many areas are only covered by one person and if that doesn't have time, whole system has to wait. - few months ago we changed to completely reworked build framework. All support script and automation become deprecated over the night and we are still making new ones. - repository management become deprecated, but we managed to setup a new one. But this new one is not matured, was not tested well enough and we keep finding problems. Before this is not fixed, we can't push out update. - kernel headers are handling with armbian-config since we are providing headers per kernel family, not just per version. This adds another level of complexity and the tool itself, armbian-config is not maintained anymore as we are building new one, from scratch. We are re-starting refactoring of this critical tool now for the 3rd time. Just to remind you, there is no budget whatsoever, while hundreds of hours were already lost getting absolutely nowhere. Which is sadly completely normal part of software development - most project fails. - kernel headers compiled for Ubuntu user-space might have troubles in Debian user space and vice versa. This problem is addressed, but only extensive testing will tell us if we manage to overcome this problem. All this is possible only because we supports this project heavily. You are welcome to join and help us fight those problems. Workaround to resolve a problem just for you - build an image with enabled headers or use previous major build, which headers and source install will work via armbian-config, as per design.

Try EDGE kernel. Module for WG should be already in. For this 5.4.y kernel we need to look why headers are broken ...