As time goes on, more and more computer manufacturers are moving towards the ARM architecture and away from the bloated and outdated x86 instruction set. Apple is the most prominent producer to take this step, but plenty others are using ARM for its flexibility and efficiency. The only problem with ARM is that it’s licensed, so if you want to go even further down the open-source path the RISC-V instruction set is the next logical step. Now at least one mainline Linux distribution will officially support this architecture.
While Debian did have some support for RISC-V before this as a Debian port, which was not officially part of Debian. However, the official support will begin with the release of Debian 13, which is currently in the testing phase and hasn’t seen a stable release yet. To that end, the current state of this official version is extremely limited, being described as “almost empty” but with planned support for an initial 90 packages in the coming days. Most users working on a RISC-V platform will most likely to continue to use their Debian ports version.
It might be a little while before the RISC-V version is as full-featured as the ARM or x86 versions of this Linux distribution, but we are happy to see it move in this direction at all. And don’t think that RISC-V is limited to embedded systems or otherwise limited computing platforms, either. We’ve seen full Linux desktops with RISC-V processors since at least 2019.
Looking at the history of official Debian releases, Version 13, codename “Trixie” will be sometime during summertime 2025. Lots of time to get everything in good order. Hopefully on a shiny new longterm Linux Kernel one of which has historically been selected roughly every 12 months.
ref: https://en.wikipedia.org/wiki/Debian_version_history#Release_table
ref: https://kernel.org/category/releases.html
> I do not know the process, because I can’t find any details on the public Internet.
Sorry, the URL is a bit obscure.
https://riscv.org/membership/
Links to the membership agreement, RISC-V International Regulations, and Articles of Association are near the bottom of the page.
With regard to proposed extensions, each extension has a WIP public github repo, a publicly-readable mailing list, and the minutes of all meetings are publicly published.
(the site won’t let me reply to the original comment .. thread too long?)
This is where we will discover whether open-source hardware makes sense. A couple of years ago, someone at ARM was defending themselves against RISC-V, on the basis that anyone can take the RISC-V design and make arbitrary changes to it, adding or omitting features willy-nilly. They predicted that what we will see is a hopeless mess of RISC-V variants that no software distribution will be able to support. At the time, this sounded suspiciously like the same argument someone was making at Microsoft a couple of decades ago, asserting that open-source software will never be viable because different variants will be continually popping up, with no central authority to keep it all consistent.
I think the concerns have a kernel of truth to them, but once there’s a Linux distribution that supports a given configuration of the RISC-V design, that will become a de-facto standard, and at least for mid-range-and-up chips, will show us open-source hardware at its best. So having Debian take this giant step is very good news. We’re already seeing really low prices on RISC-V microcontrollers (although maybe not Linux-capable ones), due mainly to the lack of a single source monopoly on the architecture.
GNU/Linux distributions have currently selected to support RV64GC for this generation of RISC-V chips (G is shorthand for the IMAFDZicsr_Zifencei base and extensions).
I’m sure in the future once the ratified standard extension for vector operations (V 1.0) is common, and not binary and assembly language incompatible pre-ratified extension used in some of RISC-V chips (V 0.7.1) that it will be upgraded to support “RV64GCV”, or the newly Ratified riscv-profiles possibly something RVA22S64VH or RVA22S64VH
ref: https://github.com/riscv/riscv-profiles/releases
I was thinking RVA20S64 possibly might have support for V and H but they were only ratified in 2021, so after checking meant to say RVA22S64VH only but somehow I left the “or RVA22S64VH” instead of deleting it after I changed the first entry from RVA20 to RVA22 before I clicked on post.
ref: https://wiki.riscv.org/display/HOME/Recently+Ratified+Extensions
There is an aspect of difficulty to consider. Chip designs are difficult. Chip manufacturers are more likely to choose off the shelf designs, and even if they customize it, it would be because of a speed improvement in a new design. And then have that design made at the best node process for efficiency. Meaning an older design can become relevant again decades later because of being on a new node. Imagine a 486DX4 on 3nm? it would still be useful. People will buy the most supported and fastest RISCV designs, so the tendency to make something that is less well supported is negated. It will work out in the end.
Don’t confuse RISC-V with open source hardware. It’s an open ISA, however anything designed to actually implement RISC-V is still liable to be legally protected if the designers so wish.
Already the tools for designing a CPU can easily cost tens of millions, and that’s not even factoring in the manhours and experience required to actually use them skilfully (there’s work in China on open source EDA tools, but you would still have to pay for IP of actual building blocks). Getting it into production is again going to cost millions. Basically, I don’t think there’s a way a competitive open source CPU could materialize except with massive corporate support – but then again, why would they bother with open sourcing the design if it’s competitive?
I’m not sure if you noticed, but the OoO C910 CPU core in the two fastest RISC-V SoCs and boards you can buy right now — the quad core TH1520 (Sipeed Lichee Pi 4A, BeagleBoard BeagleV “Ahead”, others coming…) and the SIXTY FOUR core SG2042 (Milk-V Pioneer, dual- and quad-socket server boards from several companies coming soon) are open source.
https://github.com/T-head-Semi/openc910
They don’t have to … but they did.
It isn’t ARM vs. RISC-V architecture that matters. Both take advantage of RISC based architecture. ARM comes from “Acorn RISC Machine”.[1][2] And if it isn’t obvious from the name, a RISC-V machine also uses RISC based architecture.[3][4]
It is not the architecture that matters in ARM vs. RISC-V, both are RISC-based. Its the licensing (or lack-of) that matters. The ARM architecture (or Intellectual Property – IP) carrys a license burden (cost). RISC-V usually does not carry a licence burden. But there is nothing stopping someone from adding all sorts of burdens on a RISC-V based design anyway.
Simply put: Run a RISC open standard Instruction Set Architecture (ISA) and fire all the greedy MBAs and Lawyers. What’s left is a win-win for everyone else that’s still around, and it will look, feel, and taste like an unbudened RISC-V based machine. Note though, there’s nothing stopping you (or anyone else) from hiring back all the greedy MBAs and Lawyers and going the other direction with your nice RISC-V based design – but please don’t do that ;-)
* References:
1. Arm (company)
https://en.wikipedia.org/wiki/Arm_(company)
2. Acorn Computers
https://en.wikipedia.org/wiki/Acorn_Computers
3. Reduced instruction set computer
https://en.wikipedia.org/wiki/Reduced_instruction_set_computer
4. RISC-V
https://en.wikipedia.org/wiki/RISC-V
Excellent news! Moving towards fully open-source systems, both software and hardware.
I’m sorry but I really don’t understand how people make the connection between an open ISA spec and “open (source?) hardware” ?
RISC-V is an open ISA, but – pls correct me if I’m wrong here – there’s absolutely nothing that says any specific implementation of this ISA also need to be “open”, right?
And that’s just the CPU anyway. A “fully open-source system” would need an OSHW motherboard – with ideally all or most every single IC also “open” or at the very least available for common folks not behind NDAs etc. And well, open-source gfx card, monitors, printers, etc.
I sure wouldn’t mind such a future, but just don’t really see it happen anytime soon.
But hey, even ‘just’ an open CPU, sure, would be a small step on the path at least.
For now, I’d settle with any increased momentum away from x86, e.g. by way of high-performing Arm64 CPUs. These have a giant head start over RISC-V anyway, in terms of performance. Will be interesting to see if RV can catch up and approach reasonable desktop performance anytime soon.
LibreSoC will be the closest to that and it was initially was going to be RISC-V, but because NDAs were needed to add instructions***, all GPU and other planned instructions were migrated over to OpenPower where the process of adding new instructions is public, and not behind closed doors:
ref: https://www.phoronix.com/news/LibreSOC-2021
ref: https://www.crowdsupply.com/libre-risc-v/m-class/updates/nlnet-grants-approved-power-isa-under-consideration
*** https://www.crowdsupply.com/libre-risc-v/m-class/updates/modernising-1960s-computer-technology-learning-from-the-cdc-6600
Their plan looks good to me
see: “5 Products and pricing.”
https://libre-soc.org/business_plan/
Other interesting reads, which talk about the amount of money involved in having a bespoke IC manufactured, are:
https://libre-soc.org/180nm_Oct2020/
https://libre-soc.org/22nm_PowerPI/
My guess would be that for the third phase of their plan they will target a much smaller process node for more performance.
Agree with Sz, thanks for this info! Seriously interesting
Wow, thanks for those links! People, go read that last one, it’s fascinating on multiple levels (and is unrelated to the RISC-V mismanagement & cultural issue).
DOH – my bad I pasted the last two URL’s in the wrong order. Thanks for pointing it out.
>was going to be RISC-V, but because NDAs were needed to add instructions***
That’s a gross misrepresentation.
Anyone can add custom instructions to their own RISC-V CPU without asking or telling anyone about it.
What LibreSoC wanted to do was to force everyone else in the world to accept their HUGE set of untried and unproven instructions to be a STANDARD PART of the RISC-V spec forevermore — and they weren’t even willing to join RISC-V International, which is a very basic requirement to submit things for many reasons, not least to provide RISC-V protection from being sued over what you added later, whether by you or others.
If you didn’t have to sign the membership agreement before submitting new instructions then it would be very easy for someone with bad intentions to insert a trojan horse.
Two questions:
To find out what the process was would they have needed to sign a NDA ?
If they joined RISC-V International would need to sign a NDA ?
I do not know the process, because I can’t find any details on the public Internet.
The GPU instructions that they wanted to add as a Extension to the RISC-V instruction set, I personally would not see that as any weirder than J – Standard Extension for Dynamically Translated Languages.
Their GPU instructions could have been a part of a Extension for multicore RISC-V based GPUs that did ray-tracing I’m sure that Imagination, Intel, AMD, NVIDIA would be interested in joining a committee in implementing something like that. Although I’m sure some of them would join to just to slow down progress.
Openwrt has now a RISC-V port for some Sifive board in daily trunk snapshots, not releases yet, but i guess more boards will be added:
https://downloads.openwrt.org/snapshots/targets/sifiveu/generic/packages/
Gimme that Reform laptop with a SiFive P670 (RV64GC with “V”-ish)
Core announced November 2022. Expect mass-production SoCs on boards for retail sale around New Year 2027. Assuming someone has already licensed the core for an SBC/laptop-suitable SoC. Which might not have happened yet, or possibly ever. But it looks like a good core, so hopefully someone runs with it…