There seems to be a RISC-V version of Arch, what would it take to bring EOS to RISC-V??
A few things:
- We would need to validate the upstream project was complete and well-maintained
- There would need to be a team member with the interest, skills, time and bandwidth required to not only create it, but maintain it on an ongoing basis
- That team member would need to have the hardware available
Well, even if you can purchase miniITX boards already that are based on a RISC-V.
Those aren’t really close in performance to nowadays x86-64 or the arm architectures.
In short, those are capable to achieve Core 2 Duo like performance levels as of 2009.
RISC-V may have it’s place within the SBC or IoT market for those who like tinkering.
Other than that, don’t forget the latest rant from Linus Thorvalds due to certain merge requests into the mainline kernel which have been related to RISC-V.
Furthermore, as an RISC-V version motherboard has been developed by DeepComputing that fits the chassis of the Framework 13 laptop, unfortunately that very specific CPU has been known for it’s abysmal numbers in terms of power efficiency which is mostly caused by the design decision to use a chiplet based design approach of the DC-ROMA RISC-V II CPU. And it’s also only capable to compete with an Raspberry Pi 4 in terms of performance. At a much higher price.
Sounds like quite effortful.
Just based on the status page on the porting effort of the Arch packages to the RISC-V architecture, it seems that there is a long way to go for that effort, if I’m not mistaken.
Based on the insights on the github repo, which already exists since 2021, I guess that there is still a long way to go to catch up with Arch Arm.
For RISC-V specifically, there is another complication due to it’s modular and extensible instruction set approach. Therefore, there are various profiles of the the RISC-V instruction set ( If you have lots of time to kill, take a look at the RISC-V Profiles documentation ). So the actual RISC-V
Long story short, as we say in Germany, Zu viele Köche verderben den Brei (Too many cooks spoil the broth), at least that is my impression. The specification for the RISC-V instruction set is still an ongoing effort (check here) and as it is not a single company which is driving the effort, but an non-profit organization with members out of different industries with different backgrounds, motivations and interests - it’s definitely not the flat hierarchy of a single company that has to push their product to the market to turn a profit.
They are developing the architecture essentially for all areas of application, from lean IoT devices over embedded systems up to desktop and server use-cases. Which may also explain the various profiles they’re specifying. Time will tell which impact Alibabas efforts in the development of RISC-V server chips will have in the future. But up so far, I’m not aware of any large scale deployments.
In my inbox, RISC-V mostly gets mentioned in the tinkering sections of news, such as:
and
The community-focused, RHEL/CentOS-derived AlmaLinux distribution announced its support today for the RISC-V CPU ISA
Performance
5 RISC-V SBC Group Test. 2025. https://www.youtube.com/watch?v=N7EIB8bDLLU (August 24, 2025).
https://www.eetimes.com/risc-v-pivots-from-academia-to-industrial-heavyweight/
I think, since we reliably spend money on AMD, Intel, AppleSilicon and other ARM, RISC-V gets more attention and spending from China and India, the Chinese like the cheapness, the Indians like the idea that they, too, are a semiconductor superpower (in the future).
I can’t really tell. At least for PC use cases (and data centers), the RISC-V architecture can’t compete with the well established x86-64 as well as the ARM architecture currently. I’m not saying that it’s impossible to catch up within these sectors of the market. But there are too many uncertainties to tell how much time it will take until we see a mature RISC-V chip for the consumer market which is driving more than an MCU within IoT applications.
Even for the ARM architecture, from my point of view, Qualcomms 1st Gen of Snapdragon X SoC didn’t really achieved significant adoption rates in the Notebook sector (less than 0.8% in the 3rd Quarter of 2024). And if they will reach a market share of 30-50% by 2029, that is still an ambitious goal that they have set for themselves. At least the reviews for the newer Snapdragon X2 SoC are favorable.
But If we’re looking into the sector of MCUs, I guess as the Raspberry Pico 2 which features a
Dual-core Arm Cortex-M33 and a Dual-core Hazard3 RISC-V, would be interesting to see which direction Raspberry Pi will go in the future. Espressif with the ESP32 MCUs are at least fully committed to RISC-V (32bit solely, mostly single core IoT applications).
I’m running BredOS on a OrangePi RV2. BredOS is based on Arch, but it sure does break all the time. I think RISC-V has great potential, but obviously it’s still quite ways away from a viable desktop platform. I’m hoping it’ll get there, which is why I got the SBC to tinker around with. Microcontroller market seems to have adopted it pretty well as well as NVIDIA, which is cool but also concentrates the development to those markets. But I’m still pretty sure we’ll get there. ARM wasn’t considered a viable desktop CPU until recently, so it’s not like it’s all or nothing.
It’s just a shame that RISC-V doesn’t do hardware reporting, which makes finding and writing drivers difficult. I’m not a coder myself, but a friend of mine has tried to port FreeBSD for the RV2 with little success because of the hardware obfuscation.
1 Like