ProductsSiFive Core IPPerformanceIntelligenceEssentialSiFive Core DesignerSoftwareBoardsSoC IPCustom SiliconDocumentationCustomer Support
Palmer Dabbelt—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
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
lp64d. The new
emulations that were added map to the extra ABIs (those not being built
by Debian and Fedora):
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
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
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/pic.md. 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.
- September 7: RISC-V BoF at the GNU Tools Cauldron in Manchester, UK.
- September 12: Bay Area RISC-V Meetup hosted by Rambus in Sunnyvale, CA.
- October 18: RISC-V Day Tokyo hosted by Keio University in Tokyo, Japan.
- October 22: RISC-V BoF at Embedded Linux Conference + IoT Summit Europe hosted by The Linux Foundation in Edinburgh, UK.
- November 13: RISC-V Microconference at Linux Plumbers Conference in Vancouver, Canada.
- December 3: RISC-V Summit in Santa Clara, CA.
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 github.com/sifive/last-week-in-risc-v, 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!