I’ve used u-boot-spl.bin.normal.out and visionfive2_fw_payload.img within sdcard.img to update the firmware of the SBC and it works.
Small weird thing : balena etcher told me that the image was not correctly copied to the sd card but it worked flawlessly.
BTW, I don’t know how to control the update (which files/apps and their version to check) ?
dtb/dtbo are machine readable binary device tree files. The dts/dtsi files in the linux kernel source code are human readable, that the dtb and dtbo files were generated from using a dtc (device tree compiler). dtsi files are include files, so they can contain anything that is in common between multiple dts files.
So then the next question is what are dtb files used for, they are a format expected by the Linux kernel (or u-boot/spl-u-boot) to communicate with hardware. So that the same kernel for one architecture can be used with multiple boards with different SoC’s provided it has access to information held in one or more dtb. I guess it is a way of providing information to software that wants to talk to the hardware in the form of a tree. It can contain information like memory locations and registers and the same information can be accessible through multiple branches. It can also contain information about the multiplexed pins underneath the SoC and the configuration that should be selected for their function on a VF2 board.
And the next question is why is there not just one dtb, because there can be, at the spi-u-boot stage much less information is needed than at the u-boot+opensbi stage. So why waste memory when you have so little, it makes a lot of sense to have multiple dtb files. dtbo is just an overlay file, for when you want to replace information that has changed between stages in the boot.
It should eventually reach a time where at very least the spl boot stage is fully stable and unchanging. But if there are bugs/flaws found or support needed for later revisions of the SoC/board, there is always a chance of an update (or new features added - that someone thought if I do this, that could happen, and that would be very nice - that would increase sales). Like in theory that E24 CPU core in the JH7110 could at some future date be used for …?offloading OpenGL ES?.. and to enable something like that to happen may require an update to the spl-u-boot.
The production version of the board has not even shipped yet, revision 1.2A (2022-12-14) is the board was shipped to the Super Early Bird supporters, was probably the exact same board that was sent to developers who will eventually make it happen that you will never need to a UART* and HDMI just works (even 4K).
*Well there are always a few exceptions, like a power loss during an update.
As for what you need to do, that has been in the pdf supplied with each new release up until now.