logo

drewdevault.com

[mirror] blog and personal website of Drew DeVault git clone https://hacktivis.me/git/mirror/drewdevault.com.git
commit: 4784fd2b3ba2c35dff2a80b4239807c5e1bb1dd3
parent 6367ee513940b7b228131c78a0b6ca85af5d28bb
Author: Drew DeVault <sir@cmpwn.com>
Date:   Sat, 15 Jan 2022 13:02:26 +0000

The RISC-V experience

Diffstat:

Acontent/blog/2022-01-15-The-RISC-V-experience.md170+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
1 file changed, 170 insertions(+), 0 deletions(-)

diff --git a/content/blog/2022-01-15-The-RISC-V-experience.md b/content/blog/2022-01-15-The-RISC-V-experience.md @@ -0,0 +1,170 @@ +--- +title: The RISC-V experience +date: 2022-01-15 +--- + +I'm writing to you from a Sway session on Alpine Linux, which is to say from a +setup quite similar to the one I usually write blog posts on, save for one +important factor: a RISC-V CPU. + +I'll state upfront that what I'm using is not a very practical system. I'm +going to describe is all of the impractical hacks and workarounds I have used to +build a "useful" RISC-V system on which I can mostly conduct my usual work. It +has been an interesting exercise, and it bodes well for the future of RISC-V, +but for all practical purposes the promise of RISC-V still lives in tomorrow, +not today. + +In [December of 2018], I wrote an article about the process of bootstrapping +Alpine Linux for RISC-V on the HiFive Unleashed board. This board was +essentially a crappy SoC built around a RISC-V CPU: a microSD slot, GPIO pins, +an ethernet port, a little bit of RAM, and the CPU itself, in a custom +form-factor.[^expansion] Today I'm writing this on the HiFive Unmatched, which +is a big step up: it's a Mini-ITX form factor (that is, it fits in a +standardized PC case) with 16G of RAM, and the ethernet, microSD, and GPIO ports +are complimeneted with a very useful set of additional I/O via two M.2 slots, a +PCIe slot, and a USB 3 controller, plus an SPI flash chip. I have an NVMe drive +with my root filesystem on it and an AMD WX 2100 Pro GPU installed. In form, it +essentially functions like a standard PC workstation. + +[^expansion]: Plus an expansion slot which was ultimately entirely useless. + +[December of 2018]: https://drewdevault.com/2018/12/20/Porting-Alpine-Linux-to-RISC-V.html + +I have been gradually working on bringing this system up to the standards that I +expect from a useful PC, namely that it can run upstream Alpine Linux with +minimal fuss. This was not really possible on the previous SiFive hardware, but +I have got pretty close on this machine. I had to go to some lengths to get +u-Boot to provide a working UEFI environment,[^uefi] and I had to patch grub as +well, but the result is that I can write a standard Alpine ISO to a USB stick, +then boot it and install Alpine onto an NVMe normally, which then boots itself +with UEFI with no further fiddling. I interact with it through three means: the +on-board UART via a micro-USB cable (necessary to interact with u-Boot, grub, or +the early Linux environment), or ethernet (once sshd is up), or with keyboard, +mouse, and displays connected to the GPU. + +[^uefi]: I have u-Boot installed on a microSD card which the firmware boots to, + which then runs grub, which runs Linux. I could theoretically install u-Boot + to the SPI Flash and then I would not have to use a microSD card for this + process, but my initial attempts were not met with success and I didn't debug + it any further. I think other people have managed to get it working, though, + and someone is working on making Alpine handle this for you. In future + hardware from SiFive I hope that they will install a working u-Boot UEFI + environment on the SPI before shipping so that you can just install standard + ISOs from a flash drive like you would with any other PC. + +Another of the standards I expect is that everything runs with upstream free +software, perhaps with a few patches, but not from a downstream or proprietary +tree. I'm pleased to report that I am running an unpatched mainline Linux +5.15.13 build. I am running mainline u-Boot with one patch to correct the name +of a device tree node to match a change in Linux upstream. I have a patched grub +build, but the relevant patches have been proposed for grub upstream. I have a +spattering of patches applied to a small handful of userspace programs and +libraries, but all of them only call for one or two patches applied to the +upstream trees. Overall, this is quite good for something this bleeding edge +&mdash; my Pinephone build is worse. + +I have enclosed the system in a mini-ITX case and set it down on top of my usual +x86_64 workstation, then moved a few of my peripherals and displays over to it +to use it as my workstation for the day.[^workstation] I was able to +successfully set up almost all of my standard workstation loadout on it, with +some notable exceptions. Firefox is the most painful omission &mdash; +bootstrapping Rust is an utter nightmare[^bootstrap] and no one has managed to +do it for Alpine Linux riscv64 yet (despite many attempts and lots of hours +wasted), so anything which depends on it does not work. librsvg is problematic +for the same reason; I had to patch a number of things to be configured without +it. For web browsing I am using [visurf], which is based on Netsurf, and which +works for many of the lightweight websites that I generally prefer to use, but +not for most others. For instance, I was unable to address an issue that was +raised on GitLab today because I cannot render GitLab properly on this browser. +SourceHut mostly works, of course, but it's not exactly pleasant &mdash; I still +haven't found time to improve the SourceHut UI for NetSurf. + +<a href="https://l.sr.ht/jJWl.jpg"> + <img src="https://l.sr.ht/jJWl.jpg" alt="A picture of two computers stacked on on top of the other." style="max-width: 70%" /> +</a> + +<div class="text-center"><small>The lower computer is my typical x86_64 +workstation, and the upper computer is the RISC-V machine. The USB ports on the +side are not connected to the board, so I pulled a USB extension cord around +from the back. This is mainly useful for rapid iteration when working on a +RISC-V kernel that a colleague has been developing using our new programming +language. I can probably get netboot working later, but this works for +now.</small></div> + +[^workstation]: I use this machine fairly often for RISC-V testing, particularly + for the new programming language I'm working on, but I usually just SSH into + it instead of connecting my displays and peripherals to it directly. +[^bootstrap]: Incidentally, my new language can be fully bootstrapped on this + machine in 272 seconds, including building and running the test suite. For + comparison, it takes about 10 seconds on my x86_64 workstation. Building LLVM + on this machine, let alone Rust, takes upwards of 12+ hours. You can + cross-compile it, but this is difficult and it still takes *ages*, and it's so + complicated and brittle that you're going to waste a huge amount of time + troubleshooting between every attempt. + +[visurf]: https://sr.ht/~sircmpwn/visurf + +Complicating things is the fact that my ordinary workstation uses two 4K +displays. For example, my terminal emulator of choice is [foot], but it uses CPU +rendering and the 4K window is noticably sluggish. Alacritty, which renders on +the GPU, would probably fare better &mdash; but Rust spoils this again. I +settled for [st], which has acceptable performance (perhaps in no small part +thanks to being upscaled from 1080p on this setup). visurf also renders on the +CPU and is annoyingly slow; as a workaround I have taken to resizing the window +to be much smaller while actively navigating and then scaling it back up to full +size to read the final page. + +[foot]: https://codeberg.org/dnkl/foot +[st]: https://st.suckless.org/ + +CPU-bound programs can be a struggle. However, this system has a consumer +workstation GPU plugged into its PCIe slot. Any time I can get the GPU to pick +up the slack, it works suprisingly effectively. For example, I watched Dune +(2021) today in 4K on this machine &mdash; buttery smooth, stunningly beautiful +4K playback &mdash; a feat that my Pinebook Pro couldn't dream of. The GPU has a +hardware HVEC decoder, and mpv and Sway can use dmabufs such that the GPU +decodes and displays each frame without it ever having to touch the CPU, and +meanwhile the NVMe is fast enough to feed it data at a suitable bandwidth. A +carefully configured obs-studio is also able to record my 4K display at 30 FPS +and encode it on the GPU with VAAPI with no lag, something that I can't even do +on-CPU on x86_64 very reliably. The board does not provide onboard audio, but +being an audiophile I have a USB DAC available that works just fine. + +I was able to play Armagetron Advanced at 120+ FPS in 4K, but that's not exactly +a demanding game. I also played SuperTuxKart, a more demanding game, at 1080p +with all of the settings maxed out at a stable 30 FPS. I cannot test any +commercial games, since I'm reasonably certain that there are no proprietary +games that distribute a riscv64 build for Linux. If Ethan Lee is reading this, +please get in touch so that we can work together on testing out a Celeste build. + +My ordinary workday needs are mostly met on this system. For communication, my +mail setup with aerc and postfix works just fine, and my normal Weechat setup +works great for IRC.[^discord] Much like any other day, I reviewed a few patches +and spent some time working on a shell I've been writing in our new programming +language. The new language is quite performant, so no issues there. I think if I +had to work on SourceHut today, it might be less pleasant to work with Python +and Go, or to work on the web UI without a performant web browser. Naturally, +browsing Geminispace with gmnlm works great. + +[^discord]: There's not a snowball's chance in hell of using Discord or Slack on this system, for the record. + +So, where does this leave us? I have unusually conservative demands of my +computers. Even on high-end, top-of-the-line systems, I run a very lightweight +environment, and that's the way I like it. Even so, my modest demands stress the +limits of this machine. If I relied more on a web browser, or on more GUI +applications, or used a heavier desktop environment, or heavier programming +environments, I would not be able to be productive on this system. Tomorrow, I +expect to return to my x86_64 machine as my daily workstation and continue to +use this machine as I have before, for RISC-V development and testing over +serial and SSH. There are few use-cases for which this hardware, given its +limitations, is adequate. + +Even so, this is a very interesting system. The ability to incorporate more +powerful components like DDR4 RAM, PCIe GPUs, NVMe storage, and so on, can make +up for the slow CPU in many applications. Though many use-cases for this system +must be explained under strict caveats, one use-case it certainly offers is a +remarkably useful system with which to advance the development of the RISC-V +FOSS ecosystem. I'm using it to work on Alpine Linux, on kernel hacking +projects, compiler development, and more, on a CPU that is designed in adherence +to an open ISA standard and runs on open source firmware. This is a fascinating +product that promises great things for the future of RISC-V as a platform.