SPL-U-BOOT 202308 now boots USB, NVME, SD, EMMC

starting with 202308 sdcard.img, u-boot-spl.bin and payload.img
flashcp -Av u-boot-spl.bin.normal.out /dev/mtd0
flashcp -Av visionfive2_fw_payload.img /dev/mtd1

boot switches to 0 0 flash
boot to u-boot prompt StarFive #

env edit kernel_comp_addr_r
edit: 0x90000000
env edit kernel_comp_size
edit: 0x10000000
env edit bootcmd_mmc0
edit: setenv devtype mmc; setenv devnum 0; run mmc_boot
env edit bootcmd_mmc1
edit: setenv devtype mmc; setenv devnum 1; run mmc_boot
env edit bootcmd_nvme0
edit: setenv devtype nvme; setenv devnum 0; run nvme_boot
env edit bootcmd_usb0
edit: setenv devtype usb; setenv devnum 0; run usb_boot
env edit bootcmd
edit: pci enum; nvme scan; usb start; usb reset; run distro_bootcmd
env edit boot_targets
edit: mmc1 usb0 nvme0 mmc0 dhcp
env edit mmc_boot
edit: if mmc dev ${devnum}; setenv devtype mmc; then run scan_dev_for_boot_part; fi
env edit nvme_boot
edit: if nvme dev ${devnum}; setenv devtype nvme; then run scan_dev_for_boot_part; fi
env edit usb_boot
edit: if usb dev ${devnum}; setenv devtype usb; then run scan_dev_for_boot_part; fi
env edit boot_devs
edit: mmc usb nvme

Will now boot in order first SD, USB, NVME, last EMMC
Now fails to boot sdcard.img
Now boots -
starfive-jh7110-202308-SD-minimal-desktop.img
ArchLinux-VF2_5.15.2_v3.7.5-cwt17.img
Armbian_23.8.1_Visionfive2_jammy_edge_5.15.0.img
DietPi_VisionFive2-RISC-V-Sid.img
OpenBSD install74.img installing from sd/usb to nvme, running from nvme, following instructions from openbsd-vf2.md · GitHub
but with .dtb file copied to /starfive/jh7110-visionfive-v2.dtb
all run from SD, USB, NVME
Could someone test and confirm EMMC operation please.

2 Likes

The title is a bit misleading, these are instructions you are publishing, not something new being added by StarFive.

try more clarity, eg:
My instruction on how to make v3.6.1 spl/uboot release boot USB, NVME, SD, EMMC

Also, it is already outdated… we already have a v3.7.5 spl/uboot release here

And finally you can use markdown to format posts so that

# code is formatted properly

and not confused with other text.

I’ll do a diff to the new version and re-post
My concern is the direction official devs are going, not building a ubiquitous u-boot which just works for any Linux, BSD or whatever is thrown at it.
Old school plain text, get over it.

colin@treehome:~/Documents/Risc-V/VisionFive2/U-boot$ diff boot.orig boot-v3.7.5
colin@treehome:~/Documents/Risc-V/VisionFive2/U-boot$

addendum

before editing u-boot env
env default -f -a
saveenv

and after editing
saveenv

If a uEnv.txt is in the boot partition, comment out any env statements which will change u-boot execution flow.
no need to bother with -
jh7110_uEnv.txt vf2_nvme_uEnv.txt or vf2_uEnv.txt
they will be avoided by u-boot

1 Like