RISC-V is a new Instruction Set Architecture developed in the open and available for use without paying a license fee. Being an open ISA means there are no barriers to achieving open hardware implementations - which opens the door to performant (mostly) open hardware processors!
RISC-V is considerably newer than most ISAs and so can draw on decades more computer architecture research and practical experience. Many of the improvements are well explained in "The RISC-V Reader" by David Patterson and Andrew Waterman.
Rust is a modern systems programming language which uses an innovative type system to track ownership of all data in a program. This allows automatic memory management without a language runtime, multithreaded programs which are provably free of data races, and the guarantee that all values are correctly typed. Furthermore, Rust brings the conveniences of a modern programming language to systems programming: with built in testing and dependency management, and an excellent standard library.
Codethink sponsored me to improve the support for Rust on RISC-V Linux. I was excited to do this because I consider both Rust and RISC-V to be the future of computer systems engineering.
Finding my feet
When I started work there was already an
riscv64gc-unknown-linux-gnu (64-bit RISC-V base instruction set plus compressed
instructions on GNU+Linux) Rust support; Rust's compiler
already had support for
riscv64gc-unknown-linux-gnu; and there were even
This was surprising because the Rust project didn't list RISC-V Linux support on the supported platforms page. When asking about this, I was pointed towards the RFC defining criteria for official Rust support at each of three tiers. To summarise briefly:
- Tier 1 targets will always build and pass tests (e.g. x86_64 GNU+Linux).
- Tier 2 targets will always build, but tests may not pass (e.g. aarch64 Android).
- Tier 3 targets provide no guarantees of support (e.g. MIPS ulibc+Linux).
There were very few requirements for official Tier 3 support so I submitted
a PR advertising Tier
3 Rust support for
riscv64gc-unknown-linux-gnu. This is merged so Rust now
advertises support for RISC-V Linux.
In the long run I would like to see
Tier 2 support so that the Rust Project distribute official binaries: making Rust
easy to install on RISC-V Linux using rustup (the standard
Rust installer). But more work is needed first.
RISC-V Rust tooling support
rustup to be useful on RISC-V Linux hosts it needs official Rust
binaries to install; minor code changes to tell
rustup that it knows how to
riscv64gc-unknown-linux programs; and a CI pipeline to build
for RISC-V Linux.
When I tried out the code and CI
rustup changes I found that
effective-limits (one of
dependencies) didn't build correctly for RISC-V Linux. This was in turn because
of a bug in libc (Rust's bindings for the
standard C library). I wrote a patch to fix
misizanoen1 posted a
PR for this first. I liaised with
libc maintainers to get this PR merged and to
libc's version so that
effective-limits can depend upon the fixed version of
At the time of writing I have completed all changes to
rustup and the
PR is ready for review,
following the merge of my
to add the dependency on the fixed version of
rustup support for running on RISC-V Linux hosts,
supports installing cross-compilation targets to build RISC-V binaries from
other hosts (e.g. from my
x86_64 GNU+Linux Laptop). This worked out of the box
rustc targets are built for each host for which the
Rust project distribute binaries. However, instead of interfacing directly with
rustup to install foreign targets, the usual way for Rust developers to
cross compile is to use the cross
cross was also missing RISC-V support. My PR to
here. There was a spurious CI
failure for an unrelated architecture, which I also
Testing Rust on RISC-V
With the low hanging fruit out of the way, one of the biggest blockers for Rust Tier 2 RISC-V Linux support is documentation explaining how to run the compiler and standard library tests. In the case of RISC-V Linux, tests must run in an emulator because real hardware is not easily available.
Rust already supports emulated testing for
These work using a
program running natively on the build machine to send cross-compiled test programs
and libraries to the
which runs the tests from within an emulated system and sends the results,
stderr back to the client for reporting.
I followed this pattern for
riscv64gc-unknown-linux-gnu, building a rootfs image
for QEMU roughly following
instructions from Debian but instead using
Ubuntu 20.04 because Debian "Unstable" isn't intended for production use.
The whole build is wrapped in a Docker container, run using a wrapper script:
$ ./src/ci/docker/run.sh <CONTAINER>
<CONTAINER> is the architecture to build and test e.g.
When running the tests in the RISC-V emulator I found that many tests hang indefinitely. In general, these tests use multi-threading, multi-processing or depend upon stack unwinding on a panic. These tests need further work so I haven't upstreamed the RISC-V Linux testing support yet.
The state of Rust on RISC-V
The hanging tests indicate there's more work required to provide full language support on RISC-V. However, the compiler works well enough to build itself and most other crates, and tooling support is ready.
I had little experience working with upstream open source communities before this project. The Rust community have great documentation and have been both friendly and helpful - making this a perfect place to start.
While I haven't implemented anything technically complex or unusual, I hope my contributions can be useful to the community by getting much of the time consuming boilerplate CI and tooling work out of the way so that other contributors can work on the more exciting problems. I was surprised how much behind the scenes work is involved in providing CI, testing and tooling to give Rust its distinctive polish; and I am pleased to have the opportunity to contribute in a small way to that.
- Web app test automation with `cdt`
- FOSDEM Testing and Automation talk
- Protecting your project from dependency access problems
- Porting GNOME OS to Microchip's PolarFire Icicle Kit
- YAML Schemas: Validating Data without Writing Code
- Deterministic Construction Service
- Codethink becomes a Microchip Design Partner
- Hamsa: Using an NVIDIA Jetson Development Kit to create a fully open-source Robot Nano Hand
- Using STPA with software-intensive systems
- Codethink achieves ISO 26262 ASIL D Tool Certification
- RISC-V: running GNOME OS on SiFive hardware for the first time
- Automated Linux kernel testing
- Native compilation on Arm servers is so much faster now
- Higher quality of FOSS: How we are helping GNOME to improve their test pipeline
- RISC-V: A Small Hardware Project
- Why aligning with open source mainline is the way to go
- Build Meetup 2021: The BuildTeam Community Event
- A new approach to software safety
- Does the "Hypocrite Commits" incident prove that Linux is unsafe?
- ABI Stability in freedesktop-sdk
- Why your organisation needs to embrace working in the open-source ecosystem
- RISC-V User space access Oops
- Tracking Players at the Edge: An Overview
- What is Remote Asset API?
- Running a devroom at FOSDEM: Safety and Open Source
- Meet the codethings: Understanding BuildGrid and BuildBox with Beth White
- Streamlining Terraform configuration with Jsonnet
- Bloodlight: Designing a Heart Rate Sensor with STM32, LEDs and Photodiode
- Making the tech industry more inclusive for women
- Bloodlight Case Design: Lessons Learned
- Safety is a system property, not a software property
- RISC-V: Codethink's first research about the open instruction set
- Meet the Codethings: Safety-critical systems and the benefits of STPA with Shaun Mooney
- Why Project Managers are essential in an effective software consultancy
- FOSDEM 2021: Devroom for Safety and Open Source
- Meet the Codethings: Ben Dooks talks about Linux kernel and RISC-V
- Here we go 2021: 4 open source events for software engineers and project leaders
- Xmas Greetings from Codethink
- Call for Papers: FOSDEM 2021 Dev Room Safety and Open Source Software
- Building the abseil-hello Bazel project for a different architecture using a dynamically generated toolchain
- Advent of Code: programming puzzle challenges
- Improving performance on Interrogizer with the stm32
- Introducing Interrogizer: providing affordable troubleshooting
- Improving software security through input validation
- More time on top: My latest work improving Topplot
- Orchestrating applications by (ab)using Ansible's Network XML Parser
- My experience of the MIT STAMP workshop 2020
- Red Hat announces new Flatpak Runtime for RHEL
- How to keep your staff healthy in lockdown
- Bloodlight: A Medical PPG Testbed
- Bringing Lorry into the 2020s
- How to use Tracecompass to analyse kernel traces from LTTng
- Fixing Rust's test suite on RISC-V
- The challenges behind electric vehicle infrastructure
- Investigating kernel user-space access
- Consuming BuildStream projects in Bazel: the bazelize plugin
- Creating a Build toolkit using the Remote Execution API
- Trusting software in a pandemic
- The Case For Open Source Software In The Medical Industry
- My experiences moving to remote working
- Impact of COVID-19 on the Medical Devices Industry
- COVID-19 (Coronavirus) and Codethink
- Codethink develops Open Source drivers for Microsoft Azure Sphere MediaTek MT3620
- Codethink partners with Wirepas
- Testing Bazel's Remote Execution API
- Passing the age of retirement: our work with Fortran and its compilers
- Sharing technical knowledge at Codethink
- Using the REAPI for Distributed Builds
- An Introduction to Remote Execution and Distributed Builds
- Gluing hardware and software: Board Support Packages (BSPs)
- Engineering's jack of all trades: an intro to FPGAs
- Bust out your pendrives: Debian 10 is out!
- Why you should attend local open source meet-ups
- Acceptance, strife, and progress in the LGBTIQ+ and open source communities
- Codethink helps York Instruments to deliver world-beating medical brain-scanner
- Full archive