No more fighting with a loose TTL-USB-cables: I have USB hub shield with USB-to-UART port :-) Or two of these: one for Raspberry Pi 3B+ and other for VisionFive 2 RISC-V SBC (in the pic). Need to still pile a TPM2 chip to the pins on top of the shield and hopefully it will still work. #arm#riscv#visionfive2#raspberrypi
Not that there’s anything particular about it but here’s the obligatory neofetch shot running Debian (provided image) on #VisionFive2 after installing everything suggested in QuickStart PDF.
In this context the experience isn’t very different from any ARM board but it’s nice to see #RISCV in real life.
The board still boots, still has GUI and network.. but anyway rather than being bitten by this later I’ll just reflash and avoid upgrading this time. It’s going to be hard to not do it by accident.
Not planning to use Debian much on this but it'll be a good tool / reference as I try to get #HaikuOS running on it.
Do we see here the first ever #RISCV based #TOR node running? I just provided a TOR node for the #onion network on one of my #VisionFive boards. This one currently runs on #Debian#Linux (will be switched to #FreeBSD soon).
The acrylic case and fan I ordered for the VisionFive 2 a few weeks ago arrived today.
Like almost everything in the RISC-V ecosystem, it arrived as a bunch of raw parts without instructions. Nothing I couldn’t handle, though. #RISCV#SBC#VisionFive2
After kicking this hornets' nest of Linux users in general and RISC-V in particular this week, it occurred to me that I hadn't touched my RISC-V board in months, and things have probably improved in the meantime.
So, I fired up my VisionFive 2 again, and this time finally got it to boot off of an NVMe drive instead of micro SD.
Even with the SSD, it's still pretty pokey, but in an Ubuntu-on-Raspberry-Pi-circa-2020 kind of way (i.e., more or less usable).
I’ve opened LibreOffice and wrote and ran my first (very short) Python script on RISC-V.
Contemplating what place this thing is going to occupy in my computing life.
I suppose I should probably get a case and a fan if I’m going to try to actually use it for anything, but I enjoy seeing it on my desk, picking it up, and messing with it too much. #RISCV#VisionFive2#Linux
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)
Good: #OpenBSD :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.
sigh of course there are multiple Lenovo key cap styles that only differ just slightly enough on their underside (they're visually the same) to make them incompatible. Proprietary bullshittery 101.
There are no #3Dprinting files for these (Lenovo V15)... gonna need to make my own.
@Natanox So true. I've been irked by the same bullshit lately and I've been seriously thinking about building myself a #cyberdeck with a fully custom keyboard pcb. I wish there was a better choice of powerful #riscv cpus, but maybe a #VisionFive2 would be easy enough to replace eventually... (I'm the I-need-to-invent-a-programming-language-and-rebuild-the-os-from-first-principles-to-fix-this-off-by-one-pixel-bug kind of geek, obviously :-P)
This took quite a while again and I had needed some breaks here and there. Go 1.21RC2 has the necessary alignment checks for this to work without too much performance penalty otherwise caused if Linux or (even worse!) oreboot handled this.
In other news, this is a vast improvement to what OpenSBI offers. Less hacks, a cleaner architecture, and IT WORKS! 🥳