From mboxrd@z Thu Jan 1 00:00:00 1970 From: Michael Tremer To: development@lists.ipfire.org Subject: Re: Porting IPFire 2 to RISC-V Date: Wed, 10 Mar 2021 15:50:59 +0000 Message-ID: <0B24A594-14CD-4BAE-88D2-E4A856DC4828@ipfire.org> In-Reply-To: <1781cb83b14.d635789453109.7494558473140339091@fkardame.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============6957724941920495553==" List-Id: --===============6957724941920495553== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hello Furkan, Thank you very much for your thoughts. I think you might have misunderstood m= e on a few things. > On 10 Mar 2021, at 15:18, Furkan Salman wrote: >=20 > Hello, >=20 > RISC-V is too new to look into it, even I am waiting for some test board fr= om 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=E2=80=99t ready, yet and I = wasn=E2=80=99t 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 T= his 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 t= he 64 bit version that could potentially replace x86. I do not have any inter= est in small boards that even use the 32 bit instruction set because those ar= e 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 st= age, 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 pur= chase - or there are some remaining units on the shelves after a successor ha= s already come out. No vendor has tried to invest any of their time to help o= ut software developers. Teams of volunteers have reverse engineered and written drivers, cleaned up l= oads 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 =E2= =80=9Cspecial=E2=80=9D 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 denomi= nator 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=E2=80=99t learned and they a= re probably making their money by selling people loads of =E2=80=9Cname your = fruit=E2=80=9D Pis that are being collected in people=E2=80=99s draws - but p= robably not being used. > Adding RISC-V will be another burden on you. Another reason that can add bu= rden to Ipfire fire team is that Risc-V will also use DTS only and no UEFI su= pport 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 alr= eady. DTS isn=E2=80=99t 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 b= uild images for those, We can try to get the manufacturers ship IPFire as Def= ault OS instead on OpenWRT. Once we start getting more ARM user then we can p= romote RISC-V when RISC-V Hardware becomes openly available.=20 Serious questions: What is a =E2=80=9Cgood=E2=80=9D 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 S= oC. Instead it had to be added afterwards. RISC-V looks like it is designed to be more of an allrounder processor. The b= oards 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 suppor= t for the current available ARM Boards. I have been busy with other support w= ork so I have not got time to look into the newer IPFire where I can use late= st kernel and enable Most of the ARM SOC Support.=20 >=20 > I can try to get a RISC-V Board for you from Pine64 but again this is not y= et announced and it might take 2-3 months for production after being announce= d, It is XuanTie C906 processor sbc which should be equivalent to ARM A55 cor= e, no idea about how many cores will be used.=20 I googled the SoC and it seems to come with a single core clocked at 1 GHz. T= his 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 s= tuff upstream. There are various reasons why we cannot always be on the latest kernel. It ta= kes us a long time to get IPFire stable on a certain release and we cannot do= this too often. Just for reference, Arne=E2=80=99s development tree is here: https://git.ipfire.org/?p=3Dpeople/arne_f/ipfire-2.x.git;a=3Dshortlog;h=3Dr= efs/heads/kernel-5.10 I am sure he would be happy to accept patches - we have talked about this man= y times before. > In short we need to focus more on ARM for now until RISC-V hardware is avai= lable for testing. ARM Image build tool need to be enhanced to build device s= pecific images which will have a pre-flashed bootloader as done by most of th= e distro like Armbian, Manjaro ARM, LibreElec, OpnSense etc. Expecting a netw= ork engineer to flash a generic arm image to sd and then flash a bootloader i= s not practical as understanding how ARM/RISC-V works is not known to everyon= e who have never tried it. Having a ready to flash image can make things easy= for IPFire Users.=20 > 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 suppor= t 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 contr= ibutors and to get this we will need ready to flash images for well known net= work boards. I have already informed in forum that the boards that are curren= tly 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. Th= ings that worked before no longer work. The time that is lacking to add suppo= rt 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 suppo= rt 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 boa= rd 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 h= ardware? If it isn=E2=80=99t in mainline, we probably can=E2=80=99t support it. How la= rge 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 s= ituation 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 righ= t 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 i= s not a be task. >=20 > This is what I think from my experience of supporting ARM Devices support a= t Manjaro ARM project. >=20 > Regards, > Furkan K. >=20 >=20 >=20 >=20 > ---- On Mon, 08 Mar 2021 20:27:51 +0300 Michael Tremer wrote ---- >=20 > Hello,=20 >=20 > Apologies that this email comes a bit late and my changes have caused some = confusion on the list, but better late than never.=20 >=20 > 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 w= as =E2=80=9Cjust another architecture=E2=80=9D that could bring us 1% of user= s, or if it was different from ARM which we already support as an alternative= architecture to x86.=20 >=20 > To keep it short, RISC-V seems to be very different. In a good way. But it = is too soon.=20 >=20 > 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 is= sues in the toolchain, assembly errors or simply where a build process broken= because it didn=E2=80=99t recognise the architecture. The only exception was= that PCRE/PCRE2 do not have support for RISC-V for their JIT, yet.=20 >=20 > 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. T= his was a very nice experience. As a package maintainer, you probably just sw= itch on RISC-V and you are done.=20 >=20 > 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 = point in time. The development boards are too expensive and I didn=E2=80=99t = 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.=20 >=20 > 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.=20 >=20 > I have used QEMU to emulate the whole architecture and it can be built on a= ny machine that has qemu-system-riscv64 installed. Please do not forget to do= wnload the toolchain first. Although QEMU is fast, compiling it took about th= ree days on a 12-core Xeon processor that was a little bit dated actually.=20 >=20 > One of the biggest pain points is Rust which isn=E2=80=99t 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=E2=80=99t = be a problem for now, but probably further down the line.=20 >=20 > So, what we are going to do with it?=20 >=20 > I will probably compile it every once in a while just to check if it is sti= ll compiling. There is no point in uploading it to a server yet because nobod= y will be able to use it.=20 >=20 > I unfortunately have no connection to the (RISC-V) hardware industry. If so= meone does have such connection, please let me know. It would be great to hav= e 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 an= other architecture.=20 >=20 > Those are my thoughts on this :)=20 >=20 > -Michael >=20 >=20 --===============6957724941920495553==--