tl;dr: We have a new port for RISC-V, flavour riscv64 (64-bits little-endian) in Debian Ports.

And it's doing well.

Debian-Ports 2-week Graph, 2018-03-31

(PS: Despite the date still in some timezones... no, this is not an April-Fools-day type of post :-) ).

Ancient History

Almost a year ago I wrote a post announcing the availability of a Debian GNU/Linux port for RISC-V 64-bit (riscv64).

At the time it was an incomplete Debian system, with several of the most important pieces missing (toolchain: gcc, glibc, binutils), and with everything kept outside the Debian infrastructure.

The main reason for that was because support for the toolchain had not been submitted upstream, and the ABI was not very stable. It was changing often and in important and disruptive ways, without even as much of a public announcement before the breakage was noticed.

Last pieces of the toolchain upstreamed, at long last

Fortunately, over the last year, support has been merged in GNU binutils first (2.28), then GCC (7), then Linux 4.15 (pre-requisite for glibc), and finally in glibc 2.27, released in the first days of February.

Support is still not complete, for example riscv32 targets have not been merged in Linux mainline (but this is not important for us, unless someone else wants to start such a port), basic drivers are still missing from mainline, the support in GDB and Qemu is becoming available only now, there are many bugs that need shaking, etc.

Bootstrapping again, 2018 edition

Despite the very recent support, the ecosystem and software support is mature enough that we could, with the only help of qemu-system-riscv64, progress through the following steps:

1. Cross-compile a base set of packages

Dates: prior work for a few years (almost since the public announcement of RISC-V, in 2014); current bootstrapping since end of Feb until ~5th of March.

Apart from previous bootstrapping attempts, during the last months prior to proper starting this one I worked on clearing the path, for example by NMUing (Debian lingo for fixing without “ack” from maintainer, no reply in weeks/months, or “ack” agreeing that I went ahead) packages with patches proposed by Helmut and porters of other architectures (e.g. many from Daniel Schepler) and without any reply for a long time, or sometimes proposing new patches or new ways to solve the problems, etc.

After that, at the end of February and along with Karsten and Aurélien, we went through a round of cross-compiling, mostly with the help of Helmut Grohne's rebootstrap, but also solving additional problems like using gcc-8 rather than gcc-7 because it failed to work properly for a few days, also pulling parts of the toolchain from experimental instead of unstable and having different versions around causing conflicts, an experimental package of glibc 2.27 still not present in unstable at the time, which rendered packages such as GNU make unable to compile without patching, etc.

We also cross-compiled a significantly higher amount of packages than those considered by rebootstrap at the moment; some of them with crude hacks, like removing build-dependencies or avoiding to build man pages when they needed to run riscv64 native code for that. Sometimes is just faster to cross-compile and have many packages ready for when they are needed needed, even if sometimes cross-built packages don't work 100% correctly or not at all.

Many of those package are not essential to run a Debian system, but are needed later in the initial steps of “native” building. For example, the compiler/toolchain itself, which the rebootstrap script doesn't attempt to provide; or GNU make or cmake, which are often not needed to run a Linux system, but are required to build a great deal of software.

As a result of this phase, we have submitted bugs (or in some cases, uploads after a period of silence), with many still pending to send or apply, to try to sort these problems out in a clean way for other ports in the future (and better rebootstrapping and cross-compilation support in Debian overall), with the use of different tools like build profiles to avoid unwanted dependencies or to break dependency cycles, or moving the generation of documentation to an arch:all package, etc (so it's done once for all architectures, and riscv64 or any other arch-builders don't have to bother about it).

2. Use this set to launch “native” systems with qemu-system-riscv64

Dates: ~5th to ~13th of March.

Having built a “native” system from cross-built packages, we could compile packages natively that were difficult to cross-build, and also to run tests for packages providing them (so one can have some certainty that the package behaves sanely), and trying to have as much a clean native system as possible.

For example, one of the first packages needed and that we built natively is Perl (which is pretty basic for any Debian systems, and that we couldn't get to cross-compile easily).

We recompiled all (or almost all) packages that we got cross-built “natively”, and by running tests when possible, we uncovered some latent bugs in the toolchain and qemu, and in some packages.

The result was a set of packages (that we named “native-1”) enough to run systems equivalent to those installed in machines acting as automatic builders for other architectures, capable of building and running native "sbuild", "schroot", etc. We had to cut some unimportant dependency or feature here and there, but those changes did not affect the packages of the next set, or only marginally.

3. Build “native-2” to import to debian-ports

Dates: ~13th to ~23rd of March.

With systems installed from “native-1”, we have built again a restricted set of packages for a very basic Debian system, to act as “seed”, with as few differences as possible with the current state of Debian unstable, with the aim to import them in the Debian-ports infrastructure as cleanly as possible.

Intentionally, we built as few packages as possible, so most of the packages would go through the standard mechanisms.

A few packages have been built with the help of build-profiles support, for example to avoid dependencies on Java's default-jdk (openjdk-9-jdk at the moment), because we do not have that one yet.

Another typical case is disabling tests, after attemping to pass them, because a few cases failed among hundreds of them passed, often due to timeouts (system emulation being quite slow, this happens very often).

But most packages have been built completely unmodified; and those who were, will be rebuilt later when their dependencies are satisfied.

4. Import the base set “native-2” as “seed” and set-up automatic systems

Dates: ~23rd to ~25th of March.

Set everything up to build the whole archive in as much of a standard and unattended way as possible.

5. Currently, solve problems like breaking dependency cycles

Dates: ~25th of March, still on it.

In the current phase, the process as a whole is not “unattended”, because we have to build packages with a reduced set of features or build-dependencies, to break cycles (e.g. cmake depending on qt for its GUI tool, qt ecosystem depending on cmake).

To get close to 100% of the archive built, there are many important dependency cycles yet to break, some packages need patches specific to the architecture, etc.

Nevertheless, thousands of packages have been built by now, most of them completely unattended and in the same way as the other architectures available in Debian.

Current Status

In last few days and weeks, status was sometimes changing by the hour. That, along with -ENOTIME, are the main reasons why this post has been delayed until now, and the news have not been publicised widely.

We just focused on getting things done :-)

But to give a general idea of where we are now:

• Over 4100 packages (> 30% of the source-packages of the whole archive that are not arch-independent) have been built by now.
  • Since arch-independent packages can be installed in this architecture (e.g. many modules of languages like Python, documentation, etc.), about 65 to 70% of the Debian archive is available to use.
  • As explained before, most of the packages have been built completely unattended and in the same way as the other architectures available in Debian.
  • Progress of automatic builds as it happens: https://buildd.debian.org/status/architecture.php?a=riscv64&suite=sid
• All of this work is not tested on real hardware yet.
  • Outside of FPGA implementations, the first hardware publicly/easily available will only surface in the next few weeks, only in small quantities and expensive). We hope, and in particular I have a great deal of confidence, that the software will basically work, but... yeah.
• We find still fairly often tests that fail to pass or get locked-up in qemu, etc.
  • It's difficult to know if these are bugs in the software, compiler/toolchain, emulation, or a combination of them.
  • Still, since we got over 30% of the arch-dependent packages of a huge collection like Debian built, passing tests for most of them when available, things do not look too bad.
• We still are breaking dependency cycles that prevent many packages to be built.
  • For example we do not have almost any software depending on complex GUI (think of KDE, GNOME, browsers), there is still no support for languages such as Java, etc.

Who

Listing people working on different areas and at different times:

• Karsten Merker and I for a long time, participating in RISC-V mailing lists and some events
• Karsten Merker and I cross-building and using rebootstrap, Karsten is still focusing on that area
• Aurélien Jarno helping more actively since the preparation of pre-releases of glibc 2.27, and other parts of the tool-chain during cross-compilation
• Aurélien Jarno and I working closely together in the last phase of cross-compilation and fine-tuning of the toolchain; then to build the native sets of packages to bring riscv64 to debian-ports, setting-up buildds, etc.
• Additional support by Kurt Keville of the MIT RV128 team for a couple of years now
• Bytemark, one of the big sponsors of Debian (and other FOSS projects), sponsored a machine where I did most of the work during the previous years and up to the packages built to import into Debian ports

Apart from these people/resources, we have on our side:

• all the people working on cross-compilation and multi-arch over the years (Standing on the Shoulders of Giants, as if it were)
• Helmut Grohne's focus and tenacity on rebootstrap over the years, fixing problems all along (already mentioned previously)
• many maintainers adding support eagerly to their packages (sometimes not trivial at all)
• people starting to submit patches and requests to have packages with RISC-V support ready to install, e.g. qemu-system-riscv64
• and various people offering help and giving support along the way, too many to list here and for my poor brain to remember.

How to Use

Download packages or create your own image from: https://wiki.debian.org/RISC-V#Package_repositories

We will try to provide pre-built images or easier ways to test in the near future.

How to Help

Please refer to:

• wiki page for RISC-V
• the list of open bugs
• the list of packages that fail to build for one reason or another, analyse, submit fixes or patches

Future Work

Usual stuff for other ports, like:

1. Be able to build most of the archive
2. Create images to install or ready to use in qemu, etc.
3. Make it a first-class, full-supported architecture in future Debian Stable releases