From mboxrd@z Thu Jan 1 00:00:00 1970 From: Michael Tremer To: development@lists.ipfire.org Subject: Porting IPFire 2 to RISC-V Date: Mon, 08 Mar 2021 17:27:51 +0000 Message-ID: <3DB72557-3F8B-4097-8A49-87EFA7C82C37@ipfire.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0265340276026981322==" List-Id: --===============0265340276026981322== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hello, Apologies that this email comes a bit late and my changes have caused some co= nfusion 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= =E2=80=9Cjust another architecture=E2=80=9D that could bring us 1% of users,= or if it was different from ARM which we already support as an alternative a= rchitecture 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 t= he first go. There were some issues with autotools, but no bigger linker issu= es in the toolchain, assembly errors or simply where a build process broken b= ecause it didn=E2=80=99t recognise the architecture. The only exception was t= hat 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 ma= in repository because there are no changes that will break anything else. Thi= s was a very nice experience. As a package maintainer, you probably just swit= ch on RISC-V and you are done. There are, however, a couple of downsides. The biggest one is that I didn=E2= =80=99t have hardware and that there isn=E2=80=99t much available at this poi= nt in time. The development boards are too expensive and I didn=E2=80=99t eve= n consider to buy one because even if I could compile IPFire for RISC-V in re= asonable time, literally nobody will be able to use it. With ARM, we were quite early and we can only conclude that that wasn=E2=80= =99t 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 down= load the toolchain first. Although QEMU is fast, compiling it took about thre= e days on a 12-core Xeon processor that was a little bit dated actually. One of the biggest pain points is Rust which isn=E2=80=99t available at all f= or RISC-V and therefore I could not build suricata. Due to the lack of real-w= orld application for this and our limited usage of Rust this won=E2=80=99t 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 some= one 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 re= quire some strong build power to not delay development because of adding anot= her architecture. Those are my thoughts on this :) -Michael --===============0265340276026981322==--