The problem, as I see it, is that the QSPI NOR flash on your board contains a very old bootloader.
And the size that has been allocated to that bootloader1 (SPL ; /dev/mtd0 ; u-boot-spl.bin.normal.out ) has changed since that firmware was created. It was originally allocated 0x20000 bytes (128KiB), but it is currently allocated 0x40000 bytes (256KiB).
So if you boot up using the onboard QSPI NOR FLASH, that first partition (/dev/mtd0) is too small. If you try and write the current bootloader1 (147336 bytes) everything after the first 128KiB (131072 bytes) will be truncated and you will be missing about 13% of the firmware.
Here is what I see on my fully updated board when I boot up the “current” StarFive VisionFive 2 202308 Debian image:
user@starfive:~$ cat /proc/mtd
dev: size erasesize name
mtd0: 00040000 00001000 "spl"
mtd1: 00300000 00001000 "uboot"
mtd2: 00100000 00001000 "data"
user@starfive:~$ uname -a
Linux starfive 5.15.0-starfive #1 SMP Wed Aug 23 11:18:20 CST 2023 riscv64 GNU/Linux
user@starfive:~$ sudo strings /dev/mtd0 | grep "U-Boot SPL 2021.10"
[sudo] password for user:
U-Boot SPL 2021.10 (Aug 31 2023 - 12:55:45 +0800)
user@starfive:~/firmware$ sudo strings /dev/mtd1 | grep "U-Boot 2021.10"
U-Boot 2021.10 (Aug 31 2023 - 12:55:45 +0800)
user@starfive:~$
I know that a compile/build date of “August 31 2023” corresponds to the “VF2_v3.6.1/u-boot-spl.bin.normal.out” (bootloader1) and the “VF2_v3.6.1/visionfive2_fw_payload.img” (bootloader2).
This is what I would expect to see for your board (00020000 is the problem area):
dev: size erasesize name
mtd0: 00020000 00001000 "spl"
mtd1: 00300000 00001000 "uboot"
mtd2: 00100000 00001000 "data"
U-Boot SPL 2021.10 (Oct 31 2022 - 12:11:37 +0800)
U-Boot 2021.10 (Oct 31 2022 - 12:11:37 +0800), Build: jenkins-VF2_515_Branch_SDK_Release-10
Because the bootloader1 (/dev/md0 ; U-Boot SPL ; u-boot-spl.bin.normal.out) has a current filesize of 147336 bytes (~144 KiB) that is now too large to be written to the 128 KiB allocated on your QSPI flash.
The way I see it you have 3 options be able to boot up using the latest image.
1> Upgrade the firmware on the QSPI NOR FLASH using a TFTP server from within the U-Boot bootloader.
2> Change the boot switches to boot from SDIO 3.0 and read both firmware/bootloaders from the last SD (or eMMC) image that supported that (now depreciated) feature (StarFive VisionFive 2 202303 Debian image)
3> Decompile your current dtb (Device Tree Binary) file for image-55, patch it with the new size, boot up using the newly patched dtb with the larger allocation and then upgrade the QSPI NOR FLASH from Linux using flashcp command (apt install mtd-utils).
I choose option 2 because it was the simplest method with the least effort for me to upgrade my QSPI NOR FLASH.
For now I suspect that the only two image files that will work for you are Image-55 if you are booting using QSPI (the current recommended way of booting the board) provided you leave the boot switches in the factory default position. Or image image-202303 if, and only if, you change the boot switches (while the board is powered off) to boot from SDIO3.0. P.S. If you boot using image-55 you can not easily write the latest firmware without using option 3 above, which is simple for some and a nightmare for others.