Hello,
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 :)
-Michael
Hello everybody,
Since I have recently been submitting a toolchain update to the lists, I would like to update everyone on my efforts to port this all to RISC-V:
A new feature that we now have is to cross-compile toolchains everywhere with minimal requirements of the host system. We would need QEMU to emulate the target architecture and a working toolchain in the host architecture. The IPFire build system will take care of the rest. That enables everyone to build IPFire for any architecture with the slight caveat that compiling in an emulator is substantially slower.
Since I don’t own any RISC-V hardware at all, this was the only way to go and I was happy that I no longer need to run an entire VM which is emulated.
So, I built the toolchain and uploaded it to our toolchain server for everyone to download. I did this on my x86_64 Debian machine.
After that, I ran a build of the entire distribution which needed a couple of changes to go through:
* I added a kernel configuration (because we need *some* kernel)
* I added the Rust compiler for riscv64gc
* And there were some smaller bits (mainly updating autotools with our UPDATE_AUTOTOOLS macro)
I will push my patchset in the next couple of days for everyone to review and to merge into our main Git repository. So far it does not affect anything for the other architectures, so it won’t destroy anything. However, it is not very useful because of lack of hardware.
Regarding that and my other points from my previous email, I would say that things have not improved here at all. As far as I am aware, most developer boards are entirely unavailable now because of the whole supply crisis.
So I will do what I said earlier: Recompile IPFire on a regular basis and make sure that it builds fine on RISC-V and wait for some hardware.
Thanks for your time :)
-Michael
On 8 Mar 2021, at 17:27, Michael Tremer michael.tremer@ipfire.org wrote:
Hello,
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 :)
-Michael
-
Michael Tremer