Werner

I'd try with linux-image-vendor-rk35xx and linux-dtb-vendor-rk35xx and leave cli bsp package for now as it is. That being said it would be more useful to get an idea about WHAT is actually failing an attempting to fix before messing with the kernels. Hook up a serial console and set verbosity to 7. https://debug.armbian.de

You seem to be the first person reporting such an issue and none of us has a second sight. Therefore without logs there is pretty much nothing we can do.

https://docs.armbian.com/User-Guide_FAQ/#can-i-upgrade-my-userspace-flavor-like-bullseye-to-bookworm-or-jammy-to-noble

Moved

Don't use bleeding edge if you expect stability. Use vendor until mainline is more matured.

Existing installations can simply be apt update/upgraded since both Ubuntu and Debian released fixed versions for their supported userspaces. Armbians rootfs packages, which are used for building new images, have been recreated and pre-built images available for download are being rebuilt/replaced as well. tl;dr: mitigation is in the works/already done

Not possible without tinkering since at least the boot loader must be present either via sd or on board SPI flash. However no idea how to access this onboard 2M storage w/o the option to boot the board via sd beforehand. Not sure if it is worth exploring in this direct. Faster and probably cheaper too is to buy a new board.

Sometimes newer kernel packages are not pushed automatically via apt for various reason. This usually isn't an issue. Having .36 instead of .32 most likely does not give you significant advantages. There is however always the option to build a kernel package by yourself and then install via dpkg. https://github.com/armbian/build

There is no UEFI or Secureboot available on this board. However you may want to try this: https://github.com/edk2-porting/edk2-rk3588 and then https://github.com/tianocore/tianocore.github.io/wiki/How-to-Enable-Security

@NicoD do you still have your m4v2 and may verify uart connection and working debug console? thx in advance

Hm as for me I only have standard jumper wires for debugging my stuff. last but not least because it does not connect 5 volts which isn't necessary anyways for serial interaction and reduces the risk of frying a board by connecting this wrongly.

Well the other variant of course is that it might be connected wrongly . Tried to flip RX and TX lines? common mistake having these mixed up. If it boots from sdcard there MUST be ouput to the debug serial.

This output isn't related to uboot. So I assume you don't get any output whatsoever which means broken/missing boot loader. I'd try to boot from fresh sdcard and then start investigating.

Have you simply tried either + or +2E images if they work?

https://debug.armbian.de

moved

I'd do the following: Boot any image that works for your and check if /dev/mtd0 is present. Then simply overwrite it with dd if=/dev/zero of=/dev/mtd0. May take a few minutes. This type of memory is rather slow at writing.

Wipe SPI/eMMC before trying to boot vendor/legacy/3rd party OS from microsd again.

https://docs.armbian.com/Developer-Guide_Build-Preparation/

We cannot afford to provide pre-made images in every kernel-userspace combination for every board. The amount of resources necessary could be just insane. However that is what the build framework is made for so you can choose exactly what you want and build it by yourself. https://github.com/armbian/build

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

6.10 is, as the name implies, bleeding edge, so do not expect stuff to work. Mainline support for rk3588 is still in development. In theory though HDMI should work already, however might not have been tested on this device yet and there are caveats. Anyway if you prefer a working system, get an image with vendor 6.1.y kernel. Regarding the ssh stuff I think @Alessandro Lannocca did some work on SSH, either you grabbed an image where fixes were ongoing or you found another bug that needs attention.

Might be a known similar issue where when using armbian-install on OPi5 the contents of /boot is not copied to the nvme and therefore booting fails. However copying everything manually and adjusting the blkid it works just fine.

https://github.com/armbian/build/pull/6771

In theory everyone can create fake Armbian images since it is open source. This is why authenticity is important. Debug boot issues: https://debug.armbian.de