All Aboard, Part 8: The RISC-V Linux Port is Upstream!

As some of you may have heard, the RISC-V Linux port has been accepted into Linus' tree and is slated to release as part of 4.15. While this is a major milestone, we're far from done in Linux kernel land and there's a whole lot of work left to be done in userspace.

That said, this is a big enough development that it warrants a blog post of its own -- at the least as an excuse for why I haven't been blogging for a bit :).

What is Upstream?

The core of our port has landed upstream. That includes:

• Device Tree bindings for RISC-V CPUs.
• Early boot and initialization code.
• The Linux atomic and memory model intrinsics, targeted at a non-formal memory model (aka, a bunch of guesses I've made).
• Some interrupt and timer infrastructure, but this needs to be cleaned up.
• Paging and MMU related code.
• An implementation of the user-facing ABIs for RISC-V Linux systems, which will be turned into a specification.

All this code, in addition to a handful of fixups, will be included in the 4.15 tarball release. We're targeting the next glibc release, which should be out in early February. At that point, the ABIs will be set in stone and distributions will be able to begin work while maintaining binary forever.

What isn't Upstream?

We're still missing quite a few features, most notably:

• We need to clean up first-level interrupt handling on RISC-V systems, which I will probably borrow from how ARMv8 and OpenRISC are doing it.
• The SBI console driver isn't upstream yet, but it appears to be in pretty good shape.
• The per-hart interrupt controller will need to be modified to work with the new interrupt handling scheme.
• The PLIC driver should be converted to the FastEOI flow, but I've yet to finish that refactoring.
• The ISA mandated timer driver needs to be converted to avoid initialization code in arch/riscv/, to handle more of the device tree specification, and to use the new interrupt handling infrastructure.
• Our 32-bit DMA patches need to be cleanup up and submitted for review.
• We have some workarounds for bugs in the Xilinx PCIe controller that need to be fixed sanely .
• There's a handful of cleanups floating around in PCI and OF land that need to eventually make it in. Some of these were also being worked on in better ways by upstream, so hopefully that sorts itself out.
• We have a handful of device tree documentation fixes that should go in.

How to Help

If you're interested in helping with the RISC-V Linux effort (or any other RISC-V software project), the best place to get started is on our GitHub page. Each project has its own development repository on GitHub that contains various outstanding patches, and the RISC-V maintainers of those projects are active on those GitHub pages to discuss development.

If you're already familiar with the development process for a particular project, then we of course follow the standard development practices on a per-project basis for all the ports that have landed upstream. In general, a MAINTAINERS file of some sort will contain the mechanism for contacting the RISC-V developers. There is also a patches@groups.riscv.org mailing list where all patches for upstream RISC-V software are meant to be CC'd -- this is mainly meant for distribution maintainers as an easy place to find all software patches, but also serves as a place for discussion.

Additionally, for questions that don't fit into any of the above bins you're welcome to send them to the RISC-V software mailing list, sw-dev@groups.riscv.org or ask on #riscv on freenode.