Hello Furkan,

Thank you very much for your thoughts. I think you might have misunderstood me on a few things.

On 10 Mar 2021, at 15:18, Furkan Salman tech@fkardame.com wrote:

Hello,

RISC-V is too new to look into it, even I am waiting for some test board from either BeagleBoard or SiFive. There are some other OEM doing it but it is not based on a powerful SOC which can be used to compile the packages.

Yes, this is what I was trying to say. RISC-V isn’t ready, yet and I wasn’t expecting it to be.

I wanted to do some research into this new architecture and nothing more, yet.

Pine64 have announced something but it is a RPI Zero type board under $15 This can be used to test things out but not for regular build process.

What I should have made clear is that when I say RISC-V, I am talking about the 64 bit version that could potentially replace x86. I do not have any interest in small boards that even use the 32 bit instruction set because those are not powerful enough for what we are doing with IPFire.

Currently due to silicon shortage no manufacturer is able to ship hardware as per their expectation. With this new architecture I do not expect anything to be usable at this stage, from my point of view it will take around 2 years for good support to be added to the linux kernel. I do not understand your desire to get IPFire to work on RISC-V when we do not even have ARM stable support for well known ARM based Network hardware.

Very good point. I have written in various places that I do not expect ARM to stabilise any time soon - if at all.

The boards that we currently support are basically no longer available to purchase - or there are some remaining units on the shelves after a successor has already come out. No vendor has tried to invest any of their time to help out software developers.

Teams of volunteers have reverse engineered and written drivers, cleaned up loads of code that was dropped by a vendor and after they were done, the next product came out which was entirely incompatible with its predecessor.

This is not an ecosystem that is sustainable for the software industry and I believe it is time that we admit that.

There is no major distribution that supports various modern ARM boards out of the box. Not Debian, not Fedora, not SuSE, not Gentoo. Instead there are “special” distributions doing this work with varying success.

RedHat has been trying to make ARM popular on servers and that does not seem to have been very popular either. They relied on UEFI to have a common denominator and they wanted to run the same image on all hardware. It worked - that is not what I want to dispute here, but that kind of hardware is not freely available to purchase, or if it is, simply too expensive that not many people will buy it.

I do not think this will be fixed. Vendors haven’t learned and they are probably making their money by selling people loads of “name your fruit” Pis that are being collected in people’s draws - but probably not being used.

Adding RISC-V will be another burden on you. Another reason that can add burden to Ipfire fire team is that Risc-V will also use DTS only and no UEFI support yet which means maintaining individual device support with its specific dts and bootloader is not easy task which can be seen in the ARM support already.

DTS isn’t a problem for us as long as the boot loader is initialising the hardware and sending the kernel the device tree.

I would request you to acquire some good ARM boards and create a ready to build images for those, We can try to get the manufacturers ship IPFire as Default OS instead on OpenWRT. Once we start getting more ARM user then we can promote RISC-V when RISC-V Hardware becomes openly available.

Serious questions: What is a “good” ARM board?

I do not know any that have good CPU performance, about four Gigabit Ethernet adapters and space for an SSD and a WiFi module that cost less than US$600. You get that for a lot less money if you use x86.

USB networking is not an option and a terrible problem coming from ARM being optimised for mobile use. There is no need for a PCI bus or Ethernet in the SoC. Instead it had to be added afterwards.

RISC-V looks like it is designed to be more of an allrounder processor. The boards that came out so far have proper networking which puts us in a totally different position than with ARM.

I am still waiting to try IPFire with a Linux Kernel which have good support for the current available ARM Boards. I have been busy with other support work so I have not got time to look into the newer IPFire where I can use latest kernel and enable Most of the ARM SOC Support.

I can try to get a RISC-V Board for you from Pine64 but again this is not yet announced and it might take 2-3 months for production after being announced, It is XuanTie C906 processor sbc which should be equivalent to ARM A55 core, no idea about how many cores will be used.

I googled the SoC and it seems to come with a single core clocked at 1 GHz. This is indeed more equivalent to the Raspberry Pi Zero which is not powerful enough to run IPFire.

Currently IPFire project is in need to move to latest Kernel so most of the ARM boards can get support while RISC-V board support is also getting merged. To support any new Architecture we will always have to use latest kernel to get the device support. I have tried backporting things to older kernel but that is just a waste of time when we can just use the latest kernel and fix stuff upstream.

There are various reasons why we cannot always be on the latest kernel. It takes us a long time to get IPFire stable on a certain release and we cannot do this too often.

Just for reference, Arne’s development tree is here:

https://git.ipfire.org/?p=people/arne_f/ipfire-2.x.git;a=shortlog;h=refs/hea...

I am sure he would be happy to accept patches - we have talked about this many times before.

In short we need to focus more on ARM for now until RISC-V hardware is available for testing. ARM Image build tool need to be enhanced to build device specific images which will have a pre-flashed bootloader as done by most of the distro like Armbian, Manjaro ARM, LibreElec, OpnSense etc. Expecting a network engineer to flash a generic arm image to sd and then flash a bootloader is not practical as understanding how ARM/RISC-V works is not known to everyone who have never tried it. Having a ready to flash image can make things easy for IPFire Users. IPFire supports ARM official still I do not see many community contributors on the mailing list or forum, while Freebsd and Opnsense doesn't even support ARM officially but still I see many contributors on their forum. i hope you understand what I am trying to compare here. We need more ARM user and contributors and to get this we will need ready to flash images for well known network boards. I have already informed in forum that the boards that are currently support have reached EOL and are no longer sold by the manufacturer plus those are not powerful enough.

Yes, see above. This is the game we are playing here.

It is actually ARM that is slowing down migrating to a new kernel release. Things that worked before no longer work. The time that is lacking to add support for more hardware is being spent to keep old hardware working.

I can also ask FriendlyARM to send you R4S sample but that is out of stock and they have no idea when it will be ready as there is no supply of DDR4 ram chips. If we can get Rk3399 & RK3328 board support then this will open support to many other boards based on these SOC, while we work on RK33xx support, Rockchip have already released RK35xx and I have already received RK3566 board for testing but there is no mainline linux support and I expect it to take around a year to get basic support for it which will be the same for RISC-V.

And the vendor is expecting us to simply patch our software to support this hardware?

If it isn’t in mainline, we probably can’t support it. How large should the team be? And looking at our user base, I am not sure if there are boards that have more than a hand full of users.

To repeat myself once again: I do not think that this is a very sustainable situation and I was curious to find out whether anything is different on RISC-V. The grass is always greener on the other side. Time will tell if I am right or wrong.

Best, -Michael

Let us work on using Latest Linux Kernel to get newer ARM SOC to work then we can look into RISC-V as from what I understand compiling pkgs for RISC-V is not a be task.

This is what I think from my experience of supporting ARM Devices support at Manjaro ARM project.

Regards, Furkan K.

---- On Mon, 08 Mar 2021 20:27:51 +0300 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