From the diary of AArch64 porter — RISC-V

This post is part 15 of the "From the diary of AArch64 porter" series:

Wait, what? RISC-V? In ‘the diary of AArch64 porter’? WTH?

Yes, I started working on Fedora packaging for the 64-bit RISC-V architecture port.

All started with discussion about Mock

About a week ago, one of my work colleagues asked me about my old post about speeding up Mock. We had a discussion, I pointed him to the Mock documentation, and gave some hints.

It turned out that he was working on RISC-V related changes to Fedora packages. As I had some spare cycles, I decided to take a look. And I sank…

State of the RISC-V Fedora port

The 64-bit RISC-V port of Fedora Linux is going quite well. There are over 90% of Fedora packages already built for that architecture. And there are several packages with the riscv64 specific changes, such as:

patches adding RISC-V support
disabling some parts of test suites
disabling some build options due to bootstrapping of some languages being in progress (like Java)
disabling of debug information due to some toolchain issues (there is a work-in-progress now to solve them)

Note that these changes are temporary. There are people working on solving toolchain issues, languages are being bootstrapped (there was a review of Java changes earlier this week), patches are being integrated upstream and in Fedora, and so on.

There is the Fedora RISC-V tracker website showing the progress of the port:

package name
current status (new, triaged, patch posted, patch merged, done)
version in RISC-V port Koji
version in Fedora Koji (F43 release is tracked now)
version in CentOS Stream 10
notes

This is a simple way to check what to work on. And there are several packages, not built yet due to use of “ExclusiveArch” setting in them.

My work

The quick look at work needed reminded me of the 2012-2014 period, when I worked on the same stuff but for AArch64 ports (OpenEmbedded, Debian/Ubuntu, Fedora/RHEL). So I had a knowledge, I knew the tools and started working.

In the beginning, I went through entries in the tracker and tried to triage as many packages as possible, so it will be more visible which ones need work and which can be ignored (for now). The tracker went from seven to over eighty triaged packages in a few days.

Then I looked at changes done by current porters. Which usually meant David Abdurachmanov. I used his changes as a base for the changes needed for Fedora packaging, while trying to minimise the amount of them to the minimum required.

I did over twenty pull requests to Fedora packages during a week of work.

Hardware?

But which hardware did I use to run those hundreds of builds? Was it HiFive Premier P550? Or maybe Milk-V Titan or another RISC-V SBC?

Nope. I used my 80-core, Altra-based, AArch64 desktop to run all those builds. With the QEMU userspace helper.

You see, Mock allows to run builds for foreign architectures — all you need is the proper qemu-user-static-* package and you are ready to go:

$ fedpkg mockbuild -r fedora-43-riscv64

You can extract the “fedora-43-riscv64” Mock config from the mock-riscv64-configs.patch hosted on Fedora RISC-V port forge. I hope that these configuration files may be found in the “mock-core-configs” in Fedora soon.

At some point I had 337 qemu-user-static-riscv processes running at same time. And you know what? It was still faster than a native build on 64-bit RISC-V hardware.

But, to be honest, I only compared a few builds, so it may be better with other builders. Fedora RISC-V Koji uses wide list of SBCs to build on:

Banana Pi BPI-F3
Milk-V Jupiter
Milk-V Megrez
SiFive HiFive Premier P550
StarFive VisionFive 2

Also note that using QEMU is not a solution for building a distribution. I used it only to check if package builds, and then scrap the results.

Future

Will I continue working on the RISC-V port of Fedora Linux? Probably yes. And, at some point, I will move to integrating those changes into CentOS Stream 10.

For sure I do not want to invest in RISC-V hardware. Existing models are not worth the money (in my opinion), incoming ones are still old (RVA20/RVA22) and they are slow. Maybe in two, three years there will be something fast enough.

Marcin Juszkiewicz