Porting IPFire 2 to RISC-V
michael.tremer at ipfire.org
Mon Mar 8 17:27:51 UTC 2021
Apologies that this email comes a bit late and my changes have caused some confusion on the list, but better late than never.
I have spent some time to port IPFire 2 to RISC-V. This is nothing that had a very high priority, but I wanted to get my hands on it to see whether it was “just another architecture” that could bring us 1% of users, or if it was different from ARM which we already support as an alternative architecture to x86.
To keep it short, RISC-V seems to be very different. In a good way. But it is too soon.
The bootstrap for ARM took many months whereas this port compiled almost on the first go. There were some issues with autotools, but no bigger linker issues in the toolchain, assembly errors or simply where a build process broken because it didn’t recognise the architecture. The only exception was that PCRE/PCRE2 do not have support for RISC-V for their JIT, yet.
Therefore I decided to merge the branch with all required changes into the main repository because there are no changes that will break anything else. This was a very nice experience. As a package maintainer, you probably just switch on RISC-V and you are done.
There are, however, a couple of downsides. The biggest one is that I didn’t have hardware and that there isn’t much available at this point in time. The development boards are too expensive and I didn’t even consider to buy one because even if I could compile IPFire for RISC-V in reasonable time, literally nobody will be able to use it.
With ARM, we were quite early and we can only conclude that that wasn’t a good thing. We ran into loads of problems with the architecture and we still have *very* limited choice of hardware available. At least RISC-V does not seem to cause these issues on the software development side, which might make support for it a lot less painful for us. Yay.
I have used QEMU to emulate the whole architecture and it can be built on any machine that has qemu-system-riscv64 installed. Please do not forget to download the toolchain first. Although QEMU is fast, compiling it took about three days on a 12-core Xeon processor that was a little bit dated actually.
One of the biggest pain points is Rust which isn’t available at all for RISC-V and therefore I could not build suricata. Due to the lack of real-world application for this and our limited usage of Rust this won’t be a problem for now, but probably further down the line.
So, what we are going to do with it?
I will probably compile it every once in a while just to check if it is still compiling. There is no point in uploading it to a server yet because nobody will be able to use it.
I unfortunately have no connection to the (RISC-V) hardware industry. If someone does have such connection, please let me know. It would be great to have some development hardware to use and make IPFire boot on it. We would also require some strong build power to not delay development because of adding another architecture.
Those are my thoughts on this :)
More information about the Development