Okay, short instructions on booting #FreeBSD on a #VisionFive2 #riscv board, maybe I'll put these somewhere more stable later:

- Grab a copy of https://github.com/robn/freebsd-vf2
- edit mkvf2img.sh to mention an actually-existing snapshot; I used alpha 2
- optionally, edit it use grab a newer dtb for the board. 2.5.0 probably still works, but I took a gamble on 3.1.5 and it worked for me.
- run mkvf2img.sh on a FreeBSD system. If you know how to replace those uses of mdconfig and mkimg (which appear FreeBSD-specific) you could probably get it to run elsewhere, but I don't know how
- burn vf2.img to an sd card
- set your board to boot from flash/SPI. On my board (v1.3B) there's already a working u-boot installation there; on earlier boards it's possible you'll have to follow StarFive's directions to flash u-boot if you haven't already (not sure, I only have a recent 1.3B). This is the main thing missing from the instructions in that repo (I'll make a PR at some point), was which u-boot was in use (common instructions work with images that stick a copy of u-boot on the sd card)
- Now follow the instructions from the readme, using a USB TTL cable, *except* change the first command to ```fatload mmc 1:1 0x48000000 dtb/starfive/starfive_visionfive2.dtb``` (there was a PR that changed where the DTB went). All later commands work as advertised.
+ (they're not kidding about loading of root.img.uzip taking a while)

Useful tips:
- Along the way you'll see *a lot* of one particular error message. Clearly something isn't quite right, but don't panic if you see the one error a few hundred times
- If you get dumped at a ```dd>``` prompt you probably mistyped something at the OK prompt (or accidentally hit enter, in which case it tries to boot without a root filesystem)

Ah! The JH7110 in my VisionFive2 is actually the same SoC as in @PINE64 's Star64 and PineTab-V! So many of these drivers missing from FreeBSD are useful to all three systems (there's some variance) and the PINE64 folks look to a much newer datasheet (https://doc-en.rvspace.org/JH7110/PDF/JH7110_Datasheet.pdf) that is basically impossible to find directly browsing StarFive's website! This plus the OpenBSD drivers should be enough to get me started...

Mixed bag today:
- Good: #OpenBSD boots without issue on the #VisionFive2 without even mucking with u-boot (there are commits from at least 2 OpenBSD devs working with this board, they figured out where to store the EFI loader so the onboard OpenSBI finds it)
- Good: the latest -current snapshot tries to attach several drivers!
- Not great: the sd driver complains that it can't get a clock frequency to talk to the card and so *doesn't* attach. Booting in verbose mode indicates there are other failures attachments (also successful attachments for less exciting items).
- Hope: I only had time to try a couple dtb versions today, and I tried the latest. But the last commit to the jh7110 files was July, so it was probably last tested with an older version. So maybe backing up to a July or earlier version will work
- More encouraging news: the changes to the sd card driver basically consist of the driver just saying yes to a new manufacturer string, so if I can get this working under OpenBSD without the clock issue, there's a decent chance #FreeBSD support is a similarly straightforward change to an existing driver.

If I can get sd storage working, I could try cross-building a #NanoBSD (https://docs.freebsd.org/en/articles/nanobsd/) image for local (over serial) work...

Only had a little time this morning before meetings and needing to get back to POPL reviews, but made some progress.

Apparently there are *3* streams of dtbs for the VisionFive2 🙃
- The version that ships with the board, which is kinda borked even on my recently-shipped v1.3b
- The version posted on StarFive's board release page: https://github.com/starfive-tech/VisionFive2/releases
- The version in the tree they're using to work towards upstreaming Linux support: https://github.com/starfive-tech/linux/tree/JH7110_VisionFive2_upstream/arch/riscv/boot/dts/starfive

The latter two seem to evolve semi-independently?

I discovered I was booting OpenBSD with the borked onboard version, nothing was loading dtbs from the sd card, and doing so *does* require using fatload and bootefi commands manually in OpenSBI. When I do that, relatively recent "release" dtbs (the second of the trio above) partially boot OpenBSD: it hangs, but it also attaches a fair number of drivers before it does so. The last driver that reports attaching is pcie, and the last mailing list traffic on this board reports changes there breaking things in pcie, so... I guess I'm caught up with state-of-the-art. (I suspect something goes awry when interrupts are enabled for the pci bus, but don't know how to confirm.) Sadly this hangs *before* the mmc driver gets a chance to try loading, so I don't know if that particular driver works with any given tree.

Tomorrow I'll have to try (1) a couple slightly older "official" dtbs, (2) extracting the dtbs from their official linux image released in June, which should be close to what has been used, and then fall back to (3) manually build 85 versions of dtbs out of the Linux tree if the first two don't work... 🙃

IT WORKS #OpenBSD #riscv

ALT

The magic was finding a copy of the dtb that was used as the basis for most OpenBSD support: https://marc.info/?l=openbsd-misc&m=169046816826966&w=2

So I can use that as the basis for some FreeBSD work, though it's clear some later board updates will eventually require updates once the dtbs for this board have settled.

After lunch, I'll hook up to wireless and try installing OpenBSD to the eMMC

I am now the proud owner of one of what is probably an extremely small number of #OpenBSD #RISCV machines!

As when booting #FreeBSD on this board, it only sees 4GB despite being on an 8GB board, clearly a dtb issue

ALT

You, too, can run #OpenBSD on a VisionFive2, if you happen to have one around. I wrote up notes on what I did and some of the resources I used to figured it out: https://gist.github.com/csgordon/74658096f7838382b40bd64e11f6983e

I tried to give credit to folks who tried this before I did and did all of the actual technical work so far, but if you think I missed someone, please let me know.

Next stop: driver development hell.