Igor

We don't have enough of people to tweak desktops well and I am by no mean an expert in this area. I am more interested into low level. KDE is maintained by nobody / vanilla install ... I am trying to address XFCE, Gnome, Cinnamon, while for more (in fact already this is out of possible) ... https://docs.armbian.com/Process_Contribute/ I am just playing with Rock 5 at this very moment, running Gnome (Jammy), kernel 5.10.y ... Chromium under Wayland is accelerated, under X, not. Not sure if we want to enable Wayland by default as its not very stable. Arch / Manjaro don't care about stability at all.

If you want acceleration within Chromium, you need to switch to Wayland. It doesn't work under X.

That should not happen. What apt-mark showhold tells after installing OMV. It should list that kernel and dtb package are set to hold back from updates. Another workaround is to comment out repository /etc/apt/sources.list.d/armbian.list

Don't have Rock 3A, but 3D acceleration is present in all Armbian desktop builds OOB since years. Video acceleration within browsers? That is something else and doesn't work in Linux. Any. Their ARM section development is more or less porting from Armbian and build what comes to upstream.

https://www.armbian.com/lepotato/ Gnome Jammy desktop comes with Wayland support -> logout / login with wayland.

Recent boot loader has some issues. Our test device is running SD card, where problems weren't detected. Try to build an image with changes similar to those. By using previous boot loader ... ... adding this: BOOTBRANCH_BOARD="tag:v2022.04" BOOTPATCHDIR="u-boot-rockchip64-v2022.04" to board config file following by full recompilation.

This is not related. But it seems you don't understand. There is a group that is doing something and you are from the group that is consuming that work and pressing on the first group. There is no joint effort whatsoever. This is an illusion.

This forum exists for this. Here on graph below https://armbian.atlassian.net/jira/dashboards/10103 you can see how long it takes before tickets are closed when developers are sponsoring you at close to 100% and not the other way around. Biggest challenge and personal time loss is organising and coordinating activities (what you are expecting can easily be a full time job for several people) so we are rather relying on automated testings. Its significantly cheaper, more reliable and can be executed at any moment. We know for most of the issues, but since day has only 24 and not 2400 hours, this is best what can be done. What you would do? Project needs more help in other non technical tasks.

It seems that support for SPI got lost when upgrading kernel. Nothing unusual for software where maintaining is sponsored by its developers in their free time. Workaround (thank you) - previous 5.10.y kernel images from archive works well ... use it and don't upgrade (apt-mark hold linux-image* and linux-dtb*)

Worth trying older armbian-firmware package. Perhaps changes in https://github.com/armbian/firmware break it ?

SD / eMMC card compatibility. Possible workaround = power cycle several times. I found the same problem on Bananapi M5 and it seems this https://github.com/armbian/build/pull/4523 and https://github.com/armbian/build/pull/4524/files helps. If you can, try this. I'll double check when possible.

Now this is odd. I just built current and edge images from sources in no time. Hmm. Try with Docker as a last resort. Can you provide debug/output/compilation.log

You need to adjust sources that will be compatible with kernel 6.0.y If you know what needs to be done, then it looks like this: https://github.com/aircrack-ng/rtl8812au/pull/1008/files some of ours https://github.com/armbian/build/tree/master/patch/misc Can be few hours of work ...

This is my test M1 which runs perfectly fine. With kernel 6.1.y it will be declared supported / stable. Boots from SD card, root on NVME. This is currently the only way as we don't want to use dirty proprietary boot solutions provided by Hardkernel. Support for SPI boot / NVME root is under development, mainline ATF is floating around , but integration and testing is a lot of work ... we receive no funding so things doesn't really move fast. I can't tell when this will be done and integrated. Probably mid next year.

This should do: https://armbian.atlassian.net/browse/AR-1412

We have been applying many fixes for this ... is this happening with latest image? Or this is some old build with upgrades? Always provide this.

As this is not supported target anymore, you need to build from sources. Build from pre-build packages might not work, from sources works:

Which desktop environment?

Aha, ok, we merge this then. Remaining ones for H616 some other day ...

Switch to v22.11 or to master and it will work.

This is in the boot logs: ERROR: Did not find a cmdline Flattened Device Tree Nanopi Duo never reached mainline. It only lives in Armbian and it seems this problem is because our complete patch-set was not adopted to 6.x yet. @going is still working on it and dunno how much work there is behind. It will work if you build a CURRENT image.

Check pinned topic in this forum.

Can you try with images from 1st of December?

In a couple of days once repository is updated and synced across download network. Or switching to beta repository ... which is good for testing not recommended for production. Kernel recompilation per release is not yet in function. I only tested it, but we don't have enough build hardware for native compilation.