Specific image does not boot after SPL and U-Boot update to v3.8.2 about visionfive2 HOT 3 OPEN

This is likely because of the broken default U-Boot environment with the new version, which strictly requires boot configs/scripts and kernel image on a 3rd partition with FAT filesystem. Previously there was a moreless generic fallback, looping through all partitions, but that is gone.

So you must overwrite the U-Boot environment to again support the EFI partition provided by your IPFire image. Here is an example of a generic environment which supports all types of boot scripts/methods from all filesystems on all partitions from all boot media (SD card, eMMC, NVMe, USB, DHCP/TFTP), and at least tries to still support the StarFive DTB load+edit+write and SDK images: https://github.com/MichaIng/linux/blob/6.1-visionfive2/linux-image-visionfive2/etc/u-boot-initial-env

from visionfive2.

Thanks for the insight, could you please tell me the source where I can find this information? Bugtracker, mailing list, release notes, version history, changelog etc., thanks.

from visionfive2.

This commit broke it: starfive-tech/u-boot@1f26242

distro_bootcmd loops through all boot targets and checks all partitions for boot scripts/methods, so it was a generic fallback if the prior StarFive specific commands did not succeed. Now this has gone and only two StarFive-specific commands run, which hardcode a dedicated boot partition 3 with FAT filesystem, extlinux, and root partition 4, without any fallback. You can see both functions/methods added here: starfive-tech/u-boot@af8ba43

This is not a bug, but a totally unnecessary and complex hardcoding of needs for the image this U-Boot is able to boot. The upstream defaults do everything pretty well in a generic way, so there is actually no point to interfere. The only reasons for a custom environment are the in-memory U-Boot DTB rewrites for A revision Ethernet and different RAM sizes, and the (IMO problematic) on-disk DTB file rewrite done on every reboot with StarFive images to achieve the same for the Linux distribution. However, this can be done without breaking generic boot support, which is what we do with the bottom part of the environment I linked.

from visionfive2.