Yeah, me. When I heard about this I immediately rushed to get git head then to build it.
Immediately I found that U-Boot does not enumerate PCI automatically, but I knew it can be scripted to do so before you even get dropped to it’s prompt.
U-Boot runs preboot each time it runs but before bootcmd or shell pops up. All you need is to properly instruct it:
Append pci enum; nvme scan to end of existing preboot contents: echo $preboot to get current contents, then add ; pci enum; nvme scan to the end. For example, I had run chipa_set_uboot;run mmcbootenv in $preboot, I just made it look like run chipa_set_uboot;run mmcbootenv; pci enum; nvme scan. Run saveenv to save changes (they are saved to same QSPI flash space at 0xf0000), and reset / power cycle your VF2. If your NVME is inserted, it will catch up automatically, otherwise there is no any harm if no any present, driver will just silently fail but will not prevent U-Boot from continuing.
Sometimes PCI enumeration gets stuck for about ten seconds, dunno why, it happens rarely and usually successfully.
If you don’t like it, you can remove the change. In worst case you can reflash the entire thing with recovery binary.
I also made entire thing of booting more convenient by instructing U-Boot to read an extlinux.conf from my NVME boot partition.
Copy existing contents of bootcmd to a backup variable: env set bootcmd_b $bootcmd
Set bootcmd to sysboot nvme 0:1 any ${pxefile_addr_r} /extlinux.conf
Save environ: saveenv
Reset / power cycle
Prepare your {nvme0n1p1}/extlinux.conf with like:
menu title Slackware RISCV boot options
timeout 20
default linux64
label linux64
kernel /linux64.gz
fdt /jh7110-visionfive-v2.dtb
append ro quiet console=ttyS0,115200 earlycon=sbi root=/dev/nvme0n1p2 rootwait stmmac.chain_mode=1
initrd <optional if you need it>
idk, you might also need a /extlinux/extlinux.conf symlink to /extlinux.conf. Mine board does have it. If you have troubles booting, move file there or make this symlink. Consult U-Boot environment.
This way you can add boot targets, like working one and another with init=/bin/sh for recovery. And you’ll get text menu to choose from, with timeout to default.
If you are upgrading kernels via packages (as I do) this helps update-uboot to set the defaults properly when dpkg -i installs the new kernel.
Note that I remove the root= line from the line parameters, U_BOOT_ROOT should be set automagically by DPKG based on the current root partition, but specifying it here makes sure it is correct. If you do not remove it from the default line you will have tworoot= entries in the extlinux commandline, which works but is ugly/confusing.
I’ve independently gone through much of the same exercise today as coltree did, modifying and/or duplicating the mmc-specific boot commands to make them suitable for use with nvme. I agree, a big cleanup of the boot scripts/commands would be very welcome - it’s clear that there’s a lot of “initial development and bringup” logic in there, and not as much generality as would be useful.
Ne’er the less, after a few hours of hacking, I’ve gotten my board so that it can boot directly from QSPI into NVME, with no mmc access at all being required (my SD card is now sitting happily in the storage box).
This took a bit of experimental hackery, since the released versions of the U-Boot payload for QSPI don’t have PCIe/NVMe support yet. I ended up extracting the versions of the SPL and U-Boot from the Wayland .img recently released (used loopback to access the .img file, dd to copy partitions 1 and 2), stripped off some of the redundant zeroes at the ends of each so that spflash didn’t complain about size, and flashed. Amazingly enough, this worked without a single episode of bricking
So, I now have the Wayland image copied to NVME, its SPL and U-boot copied to QSPI, a bunch of new commands and settings added to the QSPI environment, and it seems to boot NVME reliably every time.
My version of this QSPI stuff won’t auto-boot from MMC at all - if I want to do that again I have to either stop the boot process from the console and “run mmcboot” manually, or flip the boot-device switches so that the ROM loads the SPL and U-Boot from the MMC.
I can now boot from sd, emmc or nvme with a few small changes
not the major changes I feel are needed for a universal u-boot.
it now fails when booting SD sdcard.img from Releases · starfive-tech/VisionFive2 · GitHub
they have forked it…
I have had no luck booting the Starfive Debian ‘69’ image off my NVMe SSD yet by following the instructions in the first post. It starts to boot but it kernel panics before it loads Xorg or gets to the login screen.
I have updated my VF2 to the latest official u-boot and firmware, expanded the root partition to fill the SSD and I’ve adjusted the fstab and extlinux.conf files to use nvme0n1p3 for the root partition instead of the SD card.
Here’s a boot log of me ‘manually’ entering (copy/pasting) the above suggested U-boot commands via a serial connection followed by the kernel panic which seems to be HDMI firmware related?
I can successfully boot the Debian 69 image off SD card fine and I can also access my NVMe disk under Debian 69 when booted from SD card fine but I want to boot Debian directly from NVMe with no SD card boot partition.
This log is from when my VF2 was attached to a 1080p HDMI display that I have tested and know works under Debian 69 when it is booted from a SD card.
you can’t boot old images with a new u-boot and visa versa
get the new Debian image or Armbian, etc
the info is all up there somewhere
get the uboot prompt and good hunting
have to modify a couple of uboot scripts
I would like to try your method and I think others would also. Could you possibly present a step by step method for a learner with limited experience but eager to learn. Thanks much!
That booti command boots Debian off the NVME. Note I’ve omitted saveenv because these commands don’t work when saved, only entered manually at the uboot prompt. I’ve already tried defining the relevant env names ($bootfile, $ramdiskfile, $fdtfile), adding nvme0 to $boot_targets etc and a few other things but I’ve not hit the winning combo yet.
I’m hoping that someone who understands u-boot and the VF2 boot process better than me can tell me how to configure uboot to make this Debian sid image boot without manual intervention or adding extra boot partitions/disks. I doubt that a new u-boot or opensbi is required to fix this.
4K HDMI output works under sid and it survives apt upgrade too.
I have now got Debian sid automatically booting from my m.2 SSD.
Note that this is a hacky solution because it uses the booti command to load the kernel and initrd instead of using the u-boot sysboot command to parse the extlinux.conf but its a step in the right direction and proof that direct SSD boot is possible with a current image and the current official u-boot/firmware, 2.11.5.
I did not need to modify the default fstab nor the extlinux.conf included with sid. The only modifaction to the standard sid image was to resize the root btrfs partition to fill the disk using gparted.
You might want to run env default -a -f to reset your current u-boot config before running the following u-boot commands:
NVMe UEFI boot still not work by default with V3.0.4 firmware. It boot after messing with U-Boot commands, but I am not sure how to do it right.
What is recommended method to boot from NVMe UEFI? ESP is first partition on NVMe disk. It contains only EFI boot loader and nothing else (no extlinux, no uEnv.txt etc.).
I’ve not tried UEFI booting on VF2 but I can confirm that direct NVMe boot using extlinux.conf works with the latest arch image (cwt13) using the default u-boot settings.
