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

orangepi zero3 and 3w have, besides the confusing name, nothing in common. There is no support for any Allwinner A733 device in the framework yet. Best chance is to get in touch with Nick A since he tries to bring up support for raxda a7a, a7z, a7whateever devices which also use this SoC.

https://github.com/armbian/configng/releases

https://github.com/armbian/build/tree/main/config/boards BOARD equals filename (without file extension) from above

In the world of cheap ARM sbcs you cannot simply use image for board X and assume it works for board Y. It may up to a certain point, even boot, but you have to live with regressions. https://docs.armbian.com/User-Guide_FAQ/#why-no-universal-image If there is no pre-made image for a specific board, then you can DIY if it is even supported by the framework. keep in mind, boards in eos or csc status may or may not work. We don't know, we don't pay attention, we don't support.

Perhaps send fix here: https://github.com/armbian/build/blob/main/patch/kernel/archive/rockchip64-6.18/board-nanopi-m5-add-wifi-bt-ufs-and-misc.patch

We're in the middle of the May release, so new packages should eventually hit repo in a few days/weeks.

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

Tested orangepi5 current and vendor. works as expected

Known issue on multiple older 64 bit Allwinner socs Try these: https://fi.mirror.armbian.de/incoming/igorpecovnik/pine64/archive/

none which doesn't break other boards.