Open vpx23 opened 7 months ago
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
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.
This commit broke it: https://github.com/starfive-tech/u-boot/commit/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: https://github.com/starfive-tech/u-boot/commit/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.
Hello everybody!
I updated the VisionFive2 Software from v2.10.4 to v3.8.2.
As OS I used an SD card with this image: https://nightly.ipfire.org/next/latest/riscv64/
Bootlog of v2.10.4:
Bootlog of v3.8.2:
SD card and image are the same in the two boots so they can't be the issue.
The IPFire image has its own bugs in the kernel but the latest VisionFive doesn't even boot into GRUB.