Practically speaking, what am I going to be able to do w/ a risc v board? I imagine a ton of software will have problems with it, at least for now.
I think this is a crucial step on the way to getting an actually good experience on RISC-V based platforms.
IIRC even a port of Fedora Linux.
So you could use it as a daily driver already — unless you need a bit more computing power. A YouTuber made a nice video on how he edited a full episode on a RISC-V SoC using Kdenlive on Debian some time ago: https://youtu.be/7ke7d0iO_-0?si=-rjXdTxfYd_jLQuU
The official RISC-V port of Debian is around 97%[0] to be exact. This is already above "armel", an architecture that's been officially supported for much longer.
Current build process status is available[1].
>IIRC even a port of Fedora Linux.
Arch, too. I run Arch on my VisionFive 2.
0. https://buildd.debian.org/stats/
1. https://buildd.debian.org/status/architecture.php?a=riscv64&...
The neat thing about this specific implementation is that it can be dropped right into an existing Framework laptop — a very viable hardware platform. Thus, it will allow developers (presumably mainly on Linux) to test and iron out issues in their software, the only way to fix those software problems you speak of.
It represents a strong leap forward for RISC-V and open ISAs in general.
Be the coolest kid in the block.
Now, seriously, people buy RISC-V boards in order to use RISC-V boards. If it were to do something else, you'd probably be better off with an x86 or ARM design.
Ironically, with JH7110, there isn't much driver development left to do.
Most of it is already upstreamed[0].
Actually, it does! Check the block diagram on the first PDF linked to by this article, it has two RISC-V "monitor cores", a 32-bit one and a 64-bit one, besides the four 64-bit main cores.
> and thus will be open-source "librebootable" from the start, with no binary blobs.
There's always going to be a small bootstrap ROM, to configure everything to the point where code can be loaded from the external flash; but other than that, I agree with you: I also hope that the bootstrap code, and the code which runs on these "monitor cores", will be open-source from the start.
Already is.
There's a default flow with u-boot SPL, opensbi and u-boot.
There's an alternative flow which includes TianoCore (UEFI).
There's another alternative flow, oreboot.
All the tiny ROM inside the SoC does is fetch the next stage from elsewhere, as per the state of some GPIOs. One of the options is XMODEM on the UART.
DRAM setup and such happen in the next stage, which is e.g. u-boot SPL mentioned above.
>doesn't have the equivalent of the IME
There are some extra tiny cores in the SoC. They are available for you to use; you can implement an IME if you wanna. But by default they're doing nothing.
Anything else can generally be re-compiled. Several distributions support RISC-V already. Alpine has a total of 11378 aports, of which 850 are marked explicitly as "doesn't build for riscv64".
It's not pretty, or fair, but that's how it all actually works.
Currently I'm using qemu for that, but for someone who doesn't live and breath qemu it's an uphill battle.
(I know you can use a virtual machine for that)