I would like to point out that I have always updated the SPL/U-Boot to the latest version available before testing new releases.
Now with VisionFive 2 Debian Image 202308 Released (latest) and latest SPL/U-Boot binaries there are some problems that I would like to explain to understand whether this is intended or not by the developers.
I use nvme and with boot switch 0.0 it didn’t boot. I had to physically remove the eMMC on which there was an old release (the latest official one with xfce) because I repeat with boot switch 0.0 the boot started from eMMC.
Furthermore, I physically don’t like having to remove my nvme ssd if I want to try other unofficial images that require boot mode 0.0, nor my eMMC which previously didn’t disturb booting from nvme.
in short I could manage at least 3 images with boot 01 emm 00 nvme and 10 microSD with the official releases without having to remove the various physical media from time to time.
I hope I haven’t bored you too much and that someone can clarify what’s new in these updates.
“System will detect in sequence whether it can boot from the following device sequence: SD > eMMC > NVMe. For example, if the boot program is found on the SD, eMMC will be ignored.”
2023-07-14 “Since StarFive no longer recommends JH-7110 users to boot directly from SD card and eMMC, removed all the relevant descriptions and updated the boot flow diagram.”
You need a TUI/GUI select screen . But SPL/U-Boot is not provided.
GRUB2 is supported riscv , i do not known if it is have a select screen like x86.
You can modify uboot’s config in /boot , change “root=/dev/xxxx” to set next boot in which root partition.
I understand the developers’ choice so it makes booting easier and this will be more useful for other releases.
At this point I hope in the future to have a boot gui where I can choose where to boot from and if within a certain number of seconds I don’t do anything the preset sequence starts
I like having more media physically connected to the board to be able to experiment with new releases without deleting the old ones.
I will use the microSD to experiment and leave the current release on nvme, I will put the emmc out of the picture for the moment.
The new u-boot puts nvme before sd in the boot order.
A u-boot gui doesn’t help.
Boot order should be defined in the u-boot and can be redefined in boot_targets.
SD mmc1
USB usb0
NVME nvme0
EMMC mmc0
What you say, USB ? Yes, the devs have now made it available, but didn’t include it in their scripts, why I don’t know.
As previously, I have used distro_bootcmd for bootcmd.
Fails to boot the new sdcard.img. I use this setup for Dietpi, will probably also work for Armbian. Also boots starfive-jh7110-202308-SD-minimal-desktop.img in SD or USB and probably also from nvme or emmc
The fix is basically, from the uboot prompt StarFive #
eraseenv
env edit bootcmd_nvme0
edit: setenv devnum 0; run nvme_boot
env edit bootcmd_usb0
edit: pci enum; usb reset; setenv devnum 0; run usb_boot
env edit bootcmd_mmc1
edit: setenv devnum 1; run mmc_boot
env edit bootcmd
edit: run distro_bootcmd
env edit boot_targets
edit: mmc1 usb0 nvme0 mmc0 dhcp
saveenv
reset
edit /boot/extlinux/extlinux.conf to point to the root partition
e.g.
usb /dev/sda1 (or sda4)
nvme /dev/nvme0n1p1 (or p4)
emmc /dev/mmcblk1p1 (or p4)
sd /dev/mmcblk0p1 (or p4)
Why not? I think you are over-interpreting the word ‘GUI’.
@Mattia is not asking for much; it is clear from their post that they mean a simple text + frambuffer device list & selector, not a full desktop. If JH7110 based machines are to ever become general consumer devices this must be available via HDMI and a USB keyboard; not relying on serial connections and UART dongels. (and No, cranky and badly labelled dip switches on the board are a piss-poor substitute.)
U-Boot upstream has framebuffer support; so this is something I expect to get implemented for the JH7110 to have a viable future instead of just being a cranky dev-board. It is very frustrating that StarFive have only implemented a static splash screen and not taken this any further, and do not appear to be planning to do so either.
Maybe Milk-V pick up the baton; they seem more consumer, less developer focussed.
I assume you are talking about /boot/extlinux/extlinux.conf. In which case you are only changing the location of the / root partition; and the /boot partition will still be on the NVMe, Potentially upgradable in-place, but you lose a lot of flexability if you (say) want to do a one-time boot into another OS etc… (mostly affects developers, not end-users following a simple upgrade path.).
Because there is not have any choosen screen, modyfi the extlinux.conf is the simplest way.
If you have diffence kernel to boot , you can add a new “label” and change “default” instead change “root=” .
u-boot searches for the boot partition to find, load and run extlinux.conf, which could well be a separate /boot partition or on the /root partition.
which in turn sets the root partition and loads initrd, vmlinuz, then init…
Alter the extlinux.conf to suit the place where the install has been done.
Hey, it also loads OpenBSD.
u-boot should be ubiquitous for any distro, without changes. Now the complete install can be on any of the devices in boot_targets.
I will test other distros, but I’m down the coast, surfing and relaxing, so don’t expect full testing today.
Sure changing extlinux.conf could allow you to install Linux and BSD on the one nvme drive and select on boot. Testing that soon…
Using UUID or /dev/part is up to the installer.
sure and dive in and select, but it still wants to be the root partition, maybe with options for single user mode, kernel etc.
Yes, I am aware of all of that. I dont give a flying duck about which device the / root partition is on… The point here is that the /boot device location has become ‘fixed’ to be on the NVMe unless you set up a serial port and screw with UBoot via that, or remove the NVMe entirely.
Just what I’m talking about. Stopping boot at the u-boot prompt and simplifying the boot process by editing the u-boot env statements.
Mattia was initially concerned he had to remove devices to enable another to boot. My boot order would still stop Mattia from booting emmc before nvme, I wouldn’t have an emmc if I had a faster, larger nvme.
My aim has been to enable the use of different distributions partition setups seamlessly, which is blocked by hard coded device types and partition numbers in the u-boot scripts. I have defined a boot order which allows reinstalling new test setups from removable media without playing with switches.
Is there a possibility in future uboot and spl updates to be able to have a boot choice when booting from the keyboard?
I have various media to boot such as ssd nvme emmc and micro sd card and I would like to play with all the media to have various OS to experiment with some configurations.
I have an nvme ssd and boot switch 0 0 only the nvme ssd starts and not the micro sd with the ssd present.
you wrote me the sequence of boot devices but it doesn’t add up to me. I will try to upgrade with the new uboot and spl files with the hope that the boot matter will be even more complicated
NVMe and eMMC seem to be related to changes in the bootloader’s handling of different storage media. It’s advisable to contact the VisionFive 2 development team or their community forum for clarity on whether this behavior is intended or a bug in the update.
The startup sequence is programmed. If you want change it, you can do the following steps.
under uboot: use command of **setenv boot_devs ** (nvme or mmc) to set bootup media and if you chose mmc use command of setenv mmc_devnum_l to chose emmc or sdcard (0 for emmc and 1for sdcard)
