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.
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.
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 #
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
edit /boot/extlinux/extlinux.conf to point to the root partition
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…
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.