SiFive - August 31, 2018

Last Week in RISC-V: August 31, 2018

Welcome to the first issue of "Last Week in RISC-V", a weekly newsletter tracking the RISC-V community. This newsletter was born out of a discussion in SiFive's internal RISC-V software team and I'm compiling it so it'll have a somewhat heavy focus on the open source software community for now as that's where I spend most of my time. The general idea behind "Last Week in RISC-V" is that the RISC-V ecosystem is getting big enough that it's impossible for any single person to track everything going on. For a while we had the patches mailing list, but we've outgrown a single mailing list for all development -- plus, this mailing list is just for patches to core RISC-V software components so it isn't wide enough in scope to cover everything going on it the RISC-V ecosystem.

The goal of "Last Week in RISC-V" is to ensure that anyone interested in the RISC-V ecosystem can stay up to date with the latest progress without needing to subscribe to every mailing list, which as we've grown has become unfeasible. I'm sort of modeling this after the LLVM weekly or LWN, but we'll see where things take us. For this issue I've avoided restricting myself to the set of developments that actually happened over the last week, but as we move forward I anticipate that we'll end up with more up-to-date content.

The target audience of "Last Week in RISC-V" is anyone who wants to stay up to date with the latest developments in RISC-V, at a weekly cadence. Since I'm currently the only person compiling this it's somewhat heavily slanted to engineers working on the RISC-V open source software ecosystem, but my hope is that we'll be able to get a wide enough breadth of contributors that we can cover everything that happens in RISC-V. Even on the software side of things I'm only really plugged in to the developments in the core RISC-V system components, so I'm far from covering the entire space of RISC-V software development much less everything else that's going on in the RISC-V ecosystem.

My current plan is to attempt to produce this at a one-week cadence, but that may be too much work for me to handle -- in that case I'll do this once a month. This is going to have to be a community effort: it's not feasible for one person to actually follow the entire RISC-V ecosystem, so we'll need help from everyone to make sure the relevant news gets collected in one place. I've got a bit of information on how to contribute to "Last Week in RISC-V" at the end of this message.

Assuming the response is good enough to make this a regular event then I'll set up some sort of mailing list specific to this newsletter, but for now I've gone ahead and posted it to all the RISC-V mailing lists.

New ELF Emulations

The original impetus for the newsletter came from a comment in our weekly software team meeting related to the new ELF emulations that were added as part of our glibc upstreaming process, so while this is fairly old news it seemed like a good place to start.

As part of the process of submitting our glibc port upstream, it was discovered that we'd ended up with a mismatch between what glibc expected (looking for libraries in /lib64/lp64d) and what ld was actually doing (looking for libraries in /lib64). This arose from our aggressive multilib support, where we allow both the soft, single, and double float ABIs to be installed in parallel. Since ld determines where to look for libraries based on the provided emulation, we needed to add additional emulations to match our ABIs.

The patch to do so is fairly mechanical, but like any ABI addition a lot of thought needs to go in to what exactly to add. To maintain backwards compatibility, the existing emulations have been left in place and signify the default ABIs, in this case ilp32d and lp64d. The new emulations that were added map to the extra ABIs (those not being built by Debian and Fedora): ilp32, ilp32f, lp64, and lp64f.

Linux 4.18 Release and Backport Branch

Linux 4.18 released on August 12th. This is the first release of Linux that has a RISC-V specific driver, which is the driver for SBI-based consoles. That is the only driver available for RISC-V systems, which means our Linux port was essentially useless -- it couldn't even get to userspace! This was enough to set a stable ABI and help build Fedora and Debian (with a bunch of out-of-tree patches), but it made actually using Linux on RISC-V a bit of a nightmare because users had to go track down a whole bunch of out-of-tree code.

The 4.19 merge window was a very big one for RISC-V because we landed sufficient driver support to actually boot the upstream kernel on both hardware (the HiFive Unleashed) and QEMU. Unless something drastic happens, 4.19 will contain drivers for the ISA-mandated interrupt handlers (via the sie and sip CSRs), the ISA-mandated timers (via SBI calls), and SiFive's PLIC. While there's still a lot of work to do in Linux land, having a kernel that can boot is a huge milestone -- I'd like to thank the guys at Western Digital for helping out here, as we'd never have been able to get this all going without them.

We're maintaining riscv-linux-4.18, a RISC-V specific branch that contains backports to 4.18. Right now that contains the various drivers that went in during the 4.19 merge window, and we intend to also backport patches that target the 4.20 merge window. We'll retire this branch in favor of a riscv-linux-4.19 when 4.19 is released.

RISC-V Featured on Linus Tech Tips

Drew and Krste went to Vancouver recently to produce a video with Linus Tech Tips, a popular YouTube channel, about RISC-V. It serves as a great introduction to RISC-V for those unfamiliar with the ISA.

GCC Position-Independent Code Cleanups

The RISC-V GCC port describes our patterns for position-independent loads and stores in gcc/config/riscv/ This has been a hairy part of our GCC port for a while, so when Jim recently found a bug he decided the clean the whole thing up. It's much nicer looking now (as well as being correct), and comes with the advantage of producing about a third of a percent smaller code for our C libraries.

For more information see the discussion on the GCC mailing list.

Zephyr 1.13.0 Release

We've had upstream support in the Zephyr RTOS for a while now, but the original port was done as a hobby project so it's needed a bit of love. We've recently found some resources at SiFive to help out with the port, and as a result it's been moving forward fairly quickly over the last few months. We managed to land some major improvements in time for the 1.13.0 release on August 31st, including:

  • Support for our upstream QEMU port, rather than an out-of-tree version that's no longer supported.
  • Support for boards parameterized by Device Tree, which allows us to easily target Zehpyr to new boards.

Nate has done a great job getting our port in better shape for this release, and as a result the 1.13.0 Zephyr release is the first version that's portable to a reasonable set of RISC-V systems. While our port still has a long way to go, we're at least off to a good start!

GDB Support for Debugging without DWARF Info

Andrew Bugress from Embecosm has a GDB patch set out that improves support for debugging targets that don't have DWARF info available. Doing so is impossible (that's why there's debug info), so support for debugging without debug info involves heuristics that pattern match the compiler's generated function call and entry code. This is a tricky proposition on modern ABIs as they tend to allow for fairly aggressive compiler optimization around function calls and therefor have very few patterns to match.

The RISC-V patch set appears to be functional, but only time will tell how reliable it is in practice. For more information about the pitfalls of debugging without debug info see a talk by David VomLehn about how this was done in MIPS land, which managed to scare me away from doing this a year or two ago.


Contributing to "Last Week in RISC-V"

Like everything else in the RISC-V ecosystem, this won't be possible as just a one-man effort. I'm hosting the sources at, so if you're comfortable editing them feel free to open a pull request. If you don't want to get involved in GitHub then you're also welcome to just mail me patches or blurbs for inclusion and I can merge them together.

I don't really have any specific criteria as to what will or won't be included. Part of the reason I'm doing this is that the RISC-V ecosystem has started to get big enough that there are huge sections of it that I know nothing about, so I think the starting criteria will be "anything I'm interested enough in to want to read" and we'll just go from there!