Skip to content(if available)orjump to list(if available)

Ubuntu 25.10 Raises RISC-V Profile Requirements

shirro

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.

saurik

The original two generations of iPhone were armv6 with hardware floating point, so that always felt to me like the sane baseline. Android wasn't using hardware floating point on armv6, but I think that was only because the compilers they had sucked (an issue that didn't apply to Apple), and many/most of the devices in fact shipped with the same hardware. I dunno... like, I don't know exactly what went into Debian's decision there, but I could see it having been made for the wrong reasons: looking at what software had been deployed rather than what hardware was common?

sanxiyn

You can look at Debian's reasoning here: https://wiki.debian.org/ArmHardFloatPort. As I understand, the decision was mostly based on hardware.

saurik

I might be missing it, but, after going through that entire page, the only things I am seeing that are relevant are the following four sentences, and none of them provide a rationale?

> Currently the Debian armhf port requires at least an Armv7 CPU with Thumb-2 and VFP3D16.

> It might make sense for such a new port -- which would essentially target newer hardware -- to target newer CPUs. For instance, it could target Armv6 or Armv7 SoCs, and VFPv2, VFPv3-D16 or NEON.

> In practice armel will be used for older CPUs (armv4t, armv5, armv6), and armhf for newer CPUs (armv7+VFP).

> Some concern for fast-enough, pretty awesome (600MHz+) Armv6 + VFPv2 processors here - i.MX37 etc. - which will not be supported by armhf default flavour, but.. we will have to live with that

stingraycharles

I just read it, seems like an unfortunate chain of events. They tried to look forward a little bit by looking at the current generation of hardware that’s out there, and didn’t anticipate an older chip to become that massively popular.

somanyphotons

RVA23 is actually a decent ISA for linux machines for the long term, RVA20 was not.

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?

mosura

> RVA23 is actually a decent ISA for linux machines for the long term, RVA20 was not.

This is setting it all up to happen again with whatever is found to be wrong with RVA23.

boredatoms

RVA20 was missing generally expected features, RVA23 isnt

RVA30 is N+1, presumably we wont see shipping devices for that until the early 2030s

kragen

Seems unlikely.

snvzz

>Does this line up with what riscv android will also require?

AIUI both Google and Microsoft selected RVA23 as baseline.

sanxiyn

Google quote from https://riscv.org/riscv-news/2024/10/risc-v-announces-ratifi...

> "Google is delighted to see the ratification of the RVA23 Profile," said Lars Bergstrom, Director of Engineering, Google. "This profile has been the result of a broad industry collaboration, and is now the baseline requirement for the Android RISC-V Application Binary Interface (ABI)."

dmitrygr

> that Ubuntu has early knowledge of.

They aren’t big enough to get advance notice of hardware from any serious SoC makers. So I bet not.

Levitating

I am really hoping there are is some unannounced hardware that Ubuntu is aware of.

csense

Can you write a kernel patch / driver to trap the unsupported instructions and provide software implementations?

karlgkk

Rva20 lacks vector support and hypervisor instructions, among other things.

You’re welcome to put a ton of effort in for dogshit performance on a bunch or $35 SBCs but the rest of us will just upgrade

And don’t worry, some vendor won’t come in and magically save you - fedora is eyeing rv22 as their baseline.

slyall

The Linux Kernel has math coprocessor emulation (mainly floating point stuff) that can be enabled if your CPU doesn't include it. This was common with consumer CPUs in the 1990s and some embedded CPUs today.

Link here, although I'm sure it existed well before 2.6.12

https://www.kernelconfig.io/config_math_emulation

CursedSilicon

Can you rephrase your answer in a way that isn't brutally and unnecessarily hostile?

cwillu

That's a lot of attitude for a reasonable question.

stefan_

That's the problem with open source, a bunch of people who once in their life want to "do it right" (right never comes). No adults in the room to say "this is what you got".

From a billion python packages in distribution package managers to broken screen sharing in Wayland, "right" isn't even what anyone wants.

fithisux

Still, no consumer based RV23 mini-ITX or micro-ATX or ATX form factor devices.

And Orange PI 2 has a GFX blob issue.

ojn

It's worse than that -- there is not a single piece of hardware that implements RVA23 available to be bought on the market today.

There are SoCs on the market that implement RVV (Vector extensions), and SoCs on the market that implement H (Hypervisor extensions).

There are no SoCs on the market that implement both at the same time. And both are mandatory for RVA23.

I'd love to be proven wrong on the hardware availability. If there's hardware to be bought in western countries that implements both RVV and H, please let me know.

dietr1ch

> It's worse than that -- there is not a single piece of hardware that implements RVA23 available to be bought on the market today.

I think that's fine, as an outsider without any RISC-V board around, alignment in the future seems better than a board out today given performance is AFAIK still awfully subpar.

As a potential consumer all I want is that by the time RISC-V really hits the market people don't start hitting edge cases like toes on furniture with missing extensions that ended up being critical to properly run the software they need. I don't want another shitshow like USB-C fast-charging where consumers can't easily tell if a cable will work fine or end up in a slow charge fallback.

I'd rather see RISC-V for the more general public coming out later than starting with the wrong foot.

snvzz

>Still, no consumer based RV23 mini-ITX or micro-ATX or ATX form factor devices.

Sure. But there are RVA22+V such devices. RVA23 will eventually succeed these.

Many IP vendors announced RVA23 cores, but understand that the process from having a core design available for licensing to having a chip is very long, measured in years.

Among the designs that are further down in the pipeline of development, a highlight is Tenstorrent's Ascalon. According to them, a tapeout is "imminent". This was in the RISC-V Summit EU a few weeks ago. That'd mean RVA23 chips competitive with Zen5 in early 2026.

dmitrygr

> That'd mean RVA23 chips competitive with Zen5 in early 2026

allegedly competitive, according to the vendor who is not impartial and with no actual benchmarks in existence to prove anything.

null

[deleted]