Werner

Sent a nudge.

The three holes could be access to a serial console if necessary. Ground Transmit Receive. If you want to try this, baudrate is most likely 115200 like all Allwinner SoCs.

I think the easiest would be to get/build an image with mesa-vpu extension enabled. Unfortunately there is no automated way to do the stuff this extension does while building, in a live system. In general there are two ways to get hw acceleration: panthor or proprietary mali blobs. Former is from my feels better for general desktop usage and latter for hw encoding/decoding. Both cannot co-exist, no idea why. Latter needs vendor kernel branch. This would give you a Noble Gnome desktop image with Panthor driver enabled: ./compile.sh BOARD=youyeetoo-r1-v3 BRANCH=vendor BUILD_DESKTOP=yes BUILD_MINIMAL=no DESKTOP_APPGROUPS_SELECTED='browsers desktop_tools internet multimedia' DESKTOP_ENVIRONMENT=gnome DESKTOP_ENVIRONMENT_CONFIG_NAME=config_base ENABLE_EXTENSIONS=mesa-vpu KERNEL_CONFIGURE=no RELEASE=noble Feel free to test: https://testing.armbian.de/Armbian-unofficial_25.11.0-trunk_Youyeetoo-r1-v3_noble_vendor_6.1.115_gnome_desktop.img.xz

edge = 6.16.y vendor = 6.1.115 Which kernel do you actually use? Also isn't panthor the backported gpu driver for rk35xx?

So besides Armbian a more recent image from khadas themselves also fails to boot?

Yes, this is quite common that feature xy has been implemented but the device trees don't get necessary updates. Often this is fixed by inheritance but sometimes adjustments on board level are necessary. Feel free to compare and send a PR to fix this until edge is bumped to 6.17 or even 6.18-rc1

This is severely outdated. Use this one instead: https://docs.armbian.com/Developer-Guide_Build-Preparation/

No need to emulate anything. Customization can be done while building. Easiest is via customize-image.sh script in userpatches: https://docs.armbian.com/Developer-Guide_User-Configurations/#user-provided-image-customization-script

https://debug.armbian.de tl;dr: get an USB uart adapter and debug via serial console.

Providing logs with armbianmonitor -u helps with troubleshooting and significantly raises chances that issue gets addressed.

moved

Probably never will until roll-over to next LTS version. We don't have people to maintain this.

mainline support for rk3588 is still incomplete. If you need vpu stuff mostly work you need to use vendor kernel which is based on rockchip bsp.

Should be resolved

HI. We cannot support 3rd party images, therefore please refrain from asking further questions about other images. Though Armbian should work just fine with this board. https://docs.armbian.com/User-Guide_Getting-Started/ There are some pitfalls that might cause issue. This board comes with a spi flash memory which, when containing a poor/bad boot loader, can prevent proper boot of any OS. In this case rkdevtool might be necessary to erase via USB if possible.

We're aware

duplicate

If you're still able to boot from microsd (which should be prefered over emmc if Armbian uboot is used) you can chroot into the system on eMMC and downgrade packages, either manually (apt/dpkg) or with armbian-config.

No clue, sorry. Maybe the driver might be optimized to work best with wayland. Maybe there is a fix pending or already merged into newer Linux version.

Simply mark whatever you want to quote and a box will appear to click:

Providing logs with armbianmonitor -u helps with troubleshooting and significantly raises chances that issue gets addressed.

moved

moved Providing logs with armbianmonitor -u helps with troubleshooting and significantly raises chances that issue gets addressed.

Hard to tell without any logs whatsoever In general it works on x86 since a few month ago I used it to move the OS from an old NUC-like pc from sd to built-in emmc which was flawless (besides I had to get rid of Ventoy since it messes up Armbian boot).

I don't know and I won't spend time investigating. We cannot provide support for 3rd party images/software. Moved to off-topic since OP is not using Armbian.