Werner

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

Well as you see, I am not Again, just use dd to grab a backup (dd if=/dev/mtdblock0 of=/somewhere/to/store/spi.backup)

Then wipe spi and retry. You can also pull a backup, simply via dd

Hi, It depends on what you want to do with your device. You should check this sheet if the features you depend on are actually available in mainline linux: https://gitlab.collabora.com/hardware-enablement/rockchip-3588/notes-for-rockchip-3588/-/blob/main/mainline-status.md Also take note that you may run into trouble booting when switching kernels. The reason is that vendor kernel images may (I don't know for this particular board) also come with (from guts feel from the stoneage) 2017 vendor uboot which may have issues booting an up to date mainline kernel. Fixing can be a bit of a pain if you don't have a second arm64 device which you could plug your microsd (via usb adapter for example) into, chroot into and fix this.

Yes, true. Meaning dirty spi Yes and no. If SPI is detected and valid it is used. However if this one detects a microsd card with a boot loader it will chain-load this one to ultimately load the os from microsd. Having mixups between vendor and mainline u-boot and/or mixed blobs (like ddr training) this will much likely cause issues.

Then my guess was correct. That's the image I tested a few minutes ago. https://paste.armbian.com/enadozucir

Tried booting cli minimal with vendor kernel from microsd, boots just fine. How to debug boot issues: https://www.youtube.com/watch?v=UpVMO7gbnYM

which image did you try?

moved to off-topic since 3rd party os. and nobody will care about a wall of text written by ai

Yes, the next step should be u-boot normally. @meco any clue?

Hm. Pure guess: https://github.com/armbian/build/commit/1bac6d977217039cae7193a1d6c19ae5b50c2c5f Try to build and boot an image with this reverted

Does it simply stop after that line or is the output incomplete?

correct. If the soc does not detect a valid boot loader on spi it will fall back to its hard coded boot order which is spi, emmc, microsd or something like this.

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

I guess dirty spi. wipe it and try again