This week I powered up the StarFive VisionFive v2 board that I have. I figured I would give FreeBSD another whirl on it, in the vague hope that RISC-V boards are a more cohesive family than ARM boards were five years ago. tl;dr: I didn’t get it to work as well as I want it to. Here are some notes.

I mentioned this board when it arrived and documented the serial pinout as well, but it has been languishing while I had other things to do.

F(reeBSD) Around And Find Out

This is what I did. The board is listed as partially supported on the FreeBSD RISC-V Wiki so I’m not entirely surprised it craps out. I’ll update the wiki if I get any further than this.

  • Downloaded a FreeBSD -CURRENT snapshot. The ISO images live here for RISC-V. I picked up the GENERICSD image from May 15th.
  • Wrote the uncompressed image to a micro-SD card with dd.
  • Stuck it in the board, connected serial ports, and powered it up.

The board starts and spits out things over serial, like all SBCs seem to do.

Platform Name             : StarFive VisionFive V2
Platform Features         : medeleg
Platform HART Count       : 5

Note the HART (core) count of 5. That’s relevant later, because this is nominally a quad-core CPU. After a little bit of SBI, we get to a U-Boot layer of the boot process, which tells me this:

U-Boot 2021.10 (Feb 12 2023 - 18:15:33 +0800), Build: jenkins-VF2_515_Branch_SDK_Release-24

CPU:   rv64imacu
Model: StarFive VisionFive V2
DRAM:  8 GiB

That is still consistent with what I think is on my desk. The FreeBSD kernel loads! And then the usual message Hit [Enter] to boot immediately appears. If I go on to boot normally, it invariably fails like this:

sbi_trap_error: hart0: trap handler failed (error -2)
sbi_trap_error: hart0: mcause=0x0000000000000005 mtval=0x0000000040048060

It is remarkably unhelpful to search for this, since the error message is both all over the place, and rarely fully explained or diagnosed. I don’t have a good explanation either, but

That fifth core, hart 0, is a different kind of CPU, and is mislabeled in the FDT that is still being shipped. FreeBSD then tries to set up the CPU in the wrong way, and it dies. The issue is quite descriptive, after you read it like six times to figure out what it actually means. Anyway, instead of hitting \[Enter\], I press some other key, and then use the loader prompt:

OK fdt prop /cpus/cpu@0/status disabled
Using DTB provided by EFI at 0x47ef2000.
OK boot

This subsequently craps out with:

starfive_dwmmc0: <Synopsys DesignWare Mobile Storage Host Controller (StarFive)> mem 0x16020000-0x1602ffff on simplebus0
starfive_dwmmc0: No bus speed provided
starfive_dwmmc0: Can't get FDT property.
device_attach: starfive_dwmmc0 attach returned 6

Followed by:

Mounting from ufs:/dev/ufs/rootfs failed with error 19.

Not even close to workable. The board itself is fine, there is a Debian image for it which just boots on through, does useful things, but that just isn’t what I want to run on this board.

It Helps To Read The Documentation

There’s a long post – someone who wanted to run FreeBSD, hit snags, then tried OpenBSD instead – over here in a GitHub gist that describes most of the process that I went though. And there is a post on the FreeBSD Forum about progress.

So I looked at both, and then went over the instructions more carefully.

  • Write the generic SD-card image to a micro-SD card.
  • Mount the EFI partition from the micro-SD card. Use gpart list da0 to see what GEOM thinks of the card. The card is GPT-partitioned, and the EFI partition is third on the disk in the standard getup. Then mount -t msdosfs /dev/da0p3 /mnt/tmp , and copy “the DTB file” into, say, the root of that filesystem. Scare quotes explained later. I used target name s5v5.dtb to save typing later.
  • Unmount, then move the card to the VisionFive board.
  • Boot, and interrupt SBI. Having remembered that the third partition is the EFI partition, load the DTB and EFI from there: 
    load mmc 1:3 ${fdt_addr_r} s5v5.dtb
load mmc 1:3 ${kernel_addr_r} EFI/boot/bootriscv64.efi
bootefi ${kernel_addr_r} ${fdt_addr_r}
  • This, somewhat to my surprise, chugs right along to a login: . The default credentials are root and root.
  • Along the way, ethernet is detected and DHCP happens and partitions on the SD card are resized.

The scare quotes around “the DTB file” are because there are many DTB files floating around for this, and lots of links to an email message attachment. I downloaded it and this one works for me, so now I have archived it locally under a slightly different name.

Why the different name? Well, investigation at the SBI prompt with env print -a showed a variable fdtfile=starfive/starfive_visionfive2.dtb. I moved the s5v5.dtb file to that location in the EFI partition, and now I don’t need to interrupt SBI because it loads the right DTB file directly.

The lack of eMMC (the controller seems to be found, but the 16MB eMMC module isn’t) and NVMe (there’s an M2 slot, and I have a WD stick in there) means that storage is rather constrained, still, and there’s nothing I would trust a write-heavy load to.

What Would OpenBSD Do?

Going through the same steps with OpenBSD (which suffers from the same kind of “there’s a gazillion ways to put together an SD card for this board”, and not one is canonical or step-by-step) is also successful. More successful, even, because all the storage options are found:

nvme0: WDC WDS240G2G0C-00AJM0, firmware 231050WD, serial 22465R472602
scsibus0 at nvme0: 2 targets, initiator 0
sd0 at scsibus0 targ 1 lun 0: <NVMe, WDC WDS240G2G0C-, 2310>
sd0: 228936MB, 512 bytes/sector, 468862128 sectors
gpiorestart0 at mainbus0
"clk_ext_camera" at mainbus0 not configured
scsibus1 at sdmmc0: 2 targets, initiator 0
sd1 at scsibus1 targ 1 lun 0: <Samsung, AJTD4R, 0000> removable
sd1: 14910MB, 512 bytes/sector, 30535680 sectors
scsibus2 at sdmmc1: 2 targets, initiator 0
sd2 at scsibus2 targ 1 lun 0: <Sandisk, SC32G, 0080> removable
sd2: 30436MB, 512 bytes/sector, 62333952 sectors

That is some serious storage for a tiny board like this.

Takeaways

It helps to read the documentation carefully. I need to update the FreeBSD wiki. The board is usable, but needs additional storage options to be a nice kind of machine for router-and-storage or NAS work.