Yeah, the RISC-V community itself didn't see it as sufficient to build a competitive chip with until RVA23. The relevant milestones have been worked on for years. A LOT of effort was spent to get them right because ISA standards are hard to undo.
RISC-V has been perfectly suitable for embedded use and RISC-V is killing in that market.
But none of the Linux capable hardware produced up to this point has been competitive with existing alternatives. No one was seriously thinking that the OrangePi was a better value than an RPi.
These computers were primarily useful as dev boards to start porting software. The manufacturers are trying to scale manufacturing and establish market share, not turn a big profit. They knew their v1 hardware would be buggy and short lived.
The CPUs themselves have been busy speed running the complexity levels that ARM and x86 had decades to develop.
The profile includes not just additional instructions but also architectural requirements that can't be emulated. The size of cache lines and reservation sets must be 64 bytes (there is no instruction to query it, like there is on ARM).
Data-independent execution latency is important for protecting cryptography against timing attacks.
Those were already in RVA22, and the difference from that to RVA23 could probably be emulated with traps though.
However, I think that some of the new instructions in RVA23 may potentially become very common in some binaries later on and could possibly trap so often that they would slow down those programs considerably.
> the difference from that to RVA23 could probably be emulated with traps though
There is no way you want to be trapping basic things such as `c.lb{u}` and `c.sb` and `c.{s,z}ext.{b,h,w}` which are going to be thoroughly mixed in all over the place.
Seems like a tough call for operating systems to do this when things are moving so fast. With risc-v its probably better to be future looking given current limitations but if a lower spec risc-v exploded in popularity you miss out.
Debian decided, probably very sensibly at the time, to set their minimum target for their 32 bit arm hardfloat distro to armv7. I guess hardly anyone used armv6 with hardware floating point apart from some obscure Broadcom chip. Then the original Raspberry Pi was released, moved an insane number of units, and Debian users would have been stuck with no hardware floating point. Fortunately Mike Thompson recompiled Debian for armv6 with hardfloat and that Debian fork (Raspbian) ended up becoming the basis for the official Raspberry Pi OS.
The Debian call seemed odd given the hardware on the market at the time - armv6 was on some very popular devices already.
In contrast, RISCV is still much more niche right now, & from the selection that is out there, DeepComputing FML13V01 & Pine64 both support Ubuntu 25 already, so they do seem to be banking on hardware that's already extant rather than pushing against the grain.
If your arbitrary scenario comes to pass, it's software, not a bridge, or a fleeting hype bubble to pull money out of. They can patch in what they need. This keeps the TODOs concrete for the team.
Missed opportunity in software does not have the same consequence long term as missing out a $2 million gain if only you'd held those stonks a bit longer.
Holy cow! Ubuntu really takes their hardware gatekeeping seriously.
Of course we'll hear from the apologists about how much extra work supporting "low end" systems is - think of the developers! think of Ubuntu's bottom line!
> Admittedly there is one big rub: the range of RISC-V devices with RVA23 support is, at the time or writing this, near non-existent.
They couldn't even wait for hardware to be available before doing this? So basically Ubuntu 25.10 only runs on hardware that doesn't yet exist. Nice.
> Focusing future Ubuntu support to devices that have more capable RISC-V profile sets will further position the distro as the de-facto OS on the platform.
...or everyone will move to something else - ANYTHING else - because we don't want to replace our brand new devices just to run Ubuntu.
Because new instructions such as `c.lb{u}` and `c.sb` and `c.{s,z}ext.{b,h,w}` are going to be thoroughly mixed in all over the place. Probably the (kinda) conditional move `czero.eqz` and `czero.nez` too.
22 comments
[ 0.26 ms ] story [ 57.7 ms ] threadAnd Orange PI 2 has a GFX blob issue.
Presumably there's going to be some hardware releases later this year that Ubuntu has early knowledge of.
Does this line up with what riscv android will also require?
RISC-V has been perfectly suitable for embedded use and RISC-V is killing in that market.
But none of the Linux capable hardware produced up to this point has been competitive with existing alternatives. No one was seriously thinking that the OrangePi was a better value than an RPi.
These computers were primarily useful as dev boards to start porting software. The manufacturers are trying to scale manufacturing and establish market share, not turn a big profit. They knew their v1 hardware would be buggy and short lived. The CPUs themselves have been busy speed running the complexity levels that ARM and x86 had decades to develop.
Those were already in RVA22, and the difference from that to RVA23 could probably be emulated with traps though.
However, I think that some of the new instructions in RVA23 may potentially become very common in some binaries later on and could possibly trap so often that they would slow down those programs considerably.
There is no way you want to be trapping basic things such as `c.lb{u}` and `c.sb` and `c.{s,z}ext.{b,h,w}` which are going to be thoroughly mixed in all over the place.
Debian decided, probably very sensibly at the time, to set their minimum target for their 32 bit arm hardfloat distro to armv7. I guess hardly anyone used armv6 with hardware floating point apart from some obscure Broadcom chip. Then the original Raspberry Pi was released, moved an insane number of units, and Debian users would have been stuck with no hardware floating point. Fortunately Mike Thompson recompiled Debian for armv6 with hardfloat and that Debian fork (Raspbian) ended up becoming the basis for the official Raspberry Pi OS.
In contrast, RISCV is still much more niche right now, & from the selection that is out there, DeepComputing FML13V01 & Pine64 both support Ubuntu 25 already, so they do seem to be banking on hardware that's already extant rather than pushing against the grain.
Missed opportunity in software does not have the same consequence long term as missing out a $2 million gain if only you'd held those stonks a bit longer.
Of course we'll hear from the apologists about how much extra work supporting "low end" systems is - think of the developers! think of Ubuntu's bottom line!
> Admittedly there is one big rub: the range of RISC-V devices with RVA23 support is, at the time or writing this, near non-existent.
They couldn't even wait for hardware to be available before doing this? So basically Ubuntu 25.10 only runs on hardware that doesn't yet exist. Nice.
> Focusing future Ubuntu support to devices that have more capable RISC-V profile sets will further position the distro as the de-facto OS on the platform.
...or everyone will move to something else - ANYTHING else - because we don't want to replace our brand new devices just to run Ubuntu.
Everyone now is nobody tomorrow.
Right now, the few RISC-V boards are in the hands of developers and enthusiasts.
In the future, RISC-V will continue to grow, into mass-market.
Ubuntu recognizes the importance of being able to fully take advantage of RVA23, a fully capable ISA comparable to x86-64v4 and ARMv9.
It is far better for software to run with a couple of percent slowdown on old cpus only than not run at all.
It can.
It's just this shim is out of scope for Ubuntu.
Refer to opensbi instruction emulation.
>It is far better for software to run with a couple of percent slowdown on old cpus only than not run at all.
With features like vector instructions or pointer masking, we're talking a non-trivial slowdown.
The difference on geekbench is 2x and not every benchmark has been optimized for RVV yet: https://browser.geekbench.com/v6/cpu/compare/10681749?baseli... (same hardware, one using the newer geekbench version that can take advantage of RVA22+V)