Werner

I think this "unsupported version" thingy when doing initramfs update is just a cosmetical thing. The script comes from upstream and checks for version string included in upstream (directly from Raspberry to say) kernels. However I believe this has been worked around by our own bsp which is silently executed right after. Cannot tell for sure if that's the issue I remember it is since I don't have access to hw atm.

Have you tried to get into by keyboard/hdmi or serial console? If so you could track down why sshd refuses to start

Basically you as heads-up for upcoming kernel bump in this branch and everyone else for attention getting this merged (or not)

Never had an issue like that. However we also have mirrors in Asia or RU/UA where politics might interfere with bandwidth. So perhaps you hit one of those? Or you simply hit a mirror which was under heavy load at this time.

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.