Werner

moved

short version: switch to vendor kernel. long version: mainline support for rk3588 is far from being feature-complete. Audio probably hasn't been mainlined yet. Check https://gitlab.collabora.com/hardware-enablement/rockchip-3588/notes-for-rockchip-3588/-/blob/main/mainline-status.md If you need most things to work vendor is the way to go for now which is based on Rockchip SDK.

Just do "./compile.sh PREFER_DOCKER=no" and leave everything else to the interactive menu.

Took a quick look. Nothing obvious. Maybe kde noticed some broken package and sent a fixed version in the mean time? Hard to tell...

duplicate of https://github.com/armbian/configng/issues/360 ?

Cannot confirm. 217 package upgrades, reboot, works fine.

moved

This doesn't tell much. This below does Providing logs with PASTE_SERVER_HOST=paste.armbian.de armbianmonitor -u helps with troubleshooting and significantly raises chances that issue gets addressed. Anyway DE is userspace. These packages come from KDE directly. If it worked before but broke after upgrade, there isn't much we can do since we don't control these packages. Since I have an opi5+ with KDE6 as well I'll try to upgrade later to see what happens.

merged

Ah alright. If this virt-manager creates a full-fledged vm with its own OS, own kernel and all the good stuff then it will work. You CAN use docker, but you don't have to. Cheers

You don't have to do that. The build framework will handle all dependencies by itself. Debian 12 may work but we won't accept any reported bugs that might occur. Is not used by the build framework. Though Docker would be used and accessible.

Um no? disable boot logo in /boot/armbianEnv.txt

glxinfo -B

Would you mind sending a PR adding these changes? Might be useful for others. https://docs.armbian.com/Process_Contribute/

expected. HDMI implementation is not yet complete. 6.13.y will bring a few enhancements in that matter. have you explicitly apt update;apt upgrade before? There were issues in the past but have been fixed iirc.

While it is overpowered it would be ideal to power any SBC since the output voltage can be adjusted/raised to compensate for losses. I personally have something similar but with 35 amps output current Check my ramble here:

Hm even though that's probably an edge case it would be nice to know if the workaround of openwrt actually works and why for Armbian it does not....

You could try a more recent rockchip sdk kernel based image if the result differs: https://github.com/armbian/community/releases/download/25.2.0-trunk.293/Armbian_community_25.2.0-trunk.293_Orangepi5pro_noble_vendor_6.1.84_gnome_desktop.img.xz

Check with armbian-config if this is implemented already or https://www.google.com/search?client=firefox-b-e&q=debian+install+desktop+environment I won't recommend desktop with your unknown rk3588s device since hdmi and other related things are not fully implemented in mainline yet. Best desktop experience gives you vendor kernel.

I am pretty sure you have been warned before switching to beta that this might break things. Anyway, overall the only thing I can say about all of this is 'welcome to the world of cheap SBCs'. This is the kind of stuff we are dealing on daily basis where stuff randomly breaks and under-staffed to fix things in reasonable time and vendors flood the market with devices, some better, some worse, some downright ugly. We're both frustrated, you're not alone. If you want something on arm architecture that just works an behaves like x86 you have to spend a lot of money (Ampere Altra system for example or anything with proper UEFI implementation). But for cheap SBCs you pay for hw only, not for sw. Latter is left to hobbyists and projects like Armbian (which consists mostly of hobbyists) to take the burden of software maintenance. To get back to the actual problems. I think NVMe support broke at some point with vendor but should be good again with latest sdk. I have an opi5+ with that running from NVMe just fine. I built an image from the most recent sources here for you to try: https://fi.mirror.armbian.de/.testing/Armbian-unofficial_25.02.0-trunk_Rock-5b_bookworm_vendor_6.1.84_minimal.img.xz

https://github.com/armbian/linux-rockchip When comparing also keep in mind we're on rkr4.1 version of rockchip sdk while Joshua was on rkr3 before he quit. Yes, maybe. Maybe in both the dts exist in full in both sources so comparison is easy.

That's a good question. I would probably try things like comparing dmesg output after boot from the board with and without and check for differences. If you're lucky the name is right there. If so I'd try to extract the blob and place it manually where it would be if the firmware package would be installed and see if it works.

In short: yes In long: yes, but.... Here is a small explanation about following the development efforts of what we call vendor and edge: When and if Rockchip provides a new version of their bsp we may adapt it unless it severely breaks things. Also occasionally various developers contribute to this code to fix things. Kernel updates will be provided with such. Current will stick to 6.12.y since it is an LTS kernel release until a new LTS version is released upstream. There won't be new features but the usual LTS bug fixing. These fixes will be pushed every few versions unless there is a critical issue. Edge will follow mainline kernel which is 6.13.0-rc at this time. Kernel updates also here of course but breakage is much more likely in comparison to current and vendor. Bleeding edge to say Having a SoC well matured upstream takes years. So not sure how long you plan to wait but for now, if you want a nicely working desktop experience, vendor is a good choice.

Mainline kernel which is still under heavy development. HDMI sound might not be implemented yet. I suggest to try a vendor kernel (6.1.y) based image instead. This kernel is a customized variant of the rockchip sdk kernel which should be close to feature-complete. You can follow mainline efforts here: https://gitlab.collabora.com/hardware-enablement/rockchip-3588/notes-for-rockchip-3588/-/blob/main/mainline-status.md

This seems like a bug to me. The linux-*-vendor packages you mentioned should be frozen with this option as well. I forwarded this to the repo: https://github.com/armbian/configng/issues/368