Porting Fedora to RISC-V

In my previous article, I gave an introduction to the open architecture of RISC-V. This article looks at how I and a small team of Fedora users ported a large part of the Fedora package set to RISC-V. It was a daunting task, especially when there is no real hardware or existing infrastructure, but we were able to get there in a part-time effort over a year and a half or so.

How to bootstrap

The first question I'm usually asked is: How do you bootstrap Linux on a new architecture? We were lucky that most of the seriously hard work — adding support to the kernel and the compiler — was already done by the RISC-V Foundation about two years ago. However there's still the rather large problem that a .riscv64.rpm cannot be built using rpmbuild, because Fedora's RPM does not support cross-compilation, so we must use a Fedora/RISC-V machine. That led to another problem, of course: Fedora/RISC-V didn't exist.

The solution is to take a small Fedora x86-64 chroot environment, and remove all of the x86-64 binaries and libraries from it (everything else — data files, config files, directories and whatever else — can stay). After that, build a GCC cross-compiler that will run on the x86-64 host, cross-compile popular GNU tools and libraries for RV64GC (RISC-V 64-bit general purpose with compressed instructions) and install them into the chroot environment in place of the x86 programs that were just deleted. The last step is to mechanically construct a disk image from this chroot environment and to boot it under QEMU. After many attempts at that you will have a Fedora/RISC-V environment that can run rpmbuild. Build a few hundred RPMs, tediously, while manually resolving build problems and circular build dependencies, until there is enough to build a pristine disk image composed entirely of RPMs.

All of that does not complete the process by any means. Next up is to use an autobuilder to crunch several times through the 20,000+ packages that make up Fedora, again manually fixing compile problems and build dependencies. All of this is done on a $4,000 16-core Intel Xeon system with a pile of SSDs — and without a hint of irony.

After months of effort, over two-thirds of all Fedora packages are done and the rest is really a matter of waiting and fixing problems as they come up.

Myself, David Abdurachmanov, Stefan O'Rear, and others have been through this whole process three times. Back in September 2016 we started the effort and got most of Fedora done by Christmas. But glibc for RISC-V was not stable at that point and our work was broken by changes to the glibc ABI, which meant we had to re-bootstrap everything from scratch. The recent release of glibc 2.27 with stable ABI support for RISC-V means that our current bootstrap attempt will likely be the final one.

Freedom

Fedora's motto is "Freedom, Friends, Features, First". RISC-V may offer the first chance for real "Freedom" all the way down to the hardware. Like Intel and AMD, it has a "Machine Mode" (similar to Intel System Management Mode) running below the operating system but, unlike those, the RISC-V Machine Mode is all open source. Although it's likely that the highest performance chips will be proprietary, there will be a variety of open options, both for full custom ASICs and FPGAs, so where you really need assurance that the CPU is as designed and the freedom to tinker you can have it.

Right now, you can put an open RISC-V design such as the 64-bit Rocket core onto a reasonably priced FPGA, such as the Nexys 4 DDR, and with a certain amount of effort run Fedora on it. This is a fun learning project, and gives you a reasonable amount of assurance. Unfortunately the Xilinx chip and toolchain used on the Nexys are highly proprietary. In the future it is hoped that Project IceStorm will reverse-engineer a large enough FPGA to enable a 64-bit core to be developed using a completely free toolchain (currently only 32-bit embedded RISC-V cores can be run that way).

In a few months to a year there should be a selection of development boards with fully open cores (unfortunately mixed with proprietary memory interfaces and I/O) that will run Fedora out of the box.

Fedora/RISC-V will only be around as long as it stays relevant, so that raises a question: Will RISC-V succeed in the long term? I think it is assured a place as a research platform. CPU researchers always want something they can just download and use without licensing hassles; something that is simple to implement and integrate. There have already been (by my count) six research chips based on RISC-V that have actually been manufactured.

Another use case is manufacturers that want cores for specialized roles, but don't want to pay license fees to ARM or others. As mentioned in the previous article, Western Digital is planning to ship a billion RISC-V cores per year in its hard drives. Although most of the targets will be in the embedded space, having an off-the-shelf Linux distribution available may be helpful in higher-end designs such as in-car displays, single-purpose devices like fitness bands, heating controls, and satellite navigation systems — or even no-name phones and tablets.

My particular interest is in servers, and I think that realistically RISC-V is a very long way off; there are also many opportunities to mess things up along the way. Servers require multi-year or decades-long commitments to standards, specifications, ABIs, and the enterprise; it remains to be seen if RISC-V will provide that.

To try out Fedora on RISC-V, I recommend looking at the Fedora/RISC-V wiki page and grabbing bootable Fedora/RISC-V disk images that can be run under QEMU 2.12 on any Linux machine. Look at the readme.txt file for information on using those images with QEMU. The project has an IRC channel — #fedora-riscv on freenode. There are no mailing lists or special development forks because the aim is to get everything upstream and into the ordinary Fedora dist-git repositories. The aim is no less than feature parity with x86-64 and other Fedora architectures, eventually, and to provide downloadable disk images or installers for RISC-V hardware as it becomes available — turning RISC-V into a first-class Fedora architecture.