Ubuntu 25.10 Raises RISC-V Profile Requirements

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 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?

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

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.

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

I was there when people were building a cross distro consensus, and the discussion was as I recall basically about hardware. By definition the software deployed was built using the previous set of distro baselines, and this being Linux the assumption is that you just recompile from source. (There was also ongoing work in parallel to add inline neon asm implementations where needed for feature/performance parity with x86.)

Android and iOS were not relevant at all, since for Android targets Google were free to pick whatever compiler config they liked and Apple is its own thing, and neither group of phones was on the table as targets for Linux distros.

The driver behind picking armv7 was:

- clearly we need some new baseline that isn't the lowest common denominator, so we take advantage of the FPU

- distros don't have the resources to want to build for lots of targets at once

- armv7 will work for new hardware, and there's not that much armv6 stuff out there, so it can live with continuing to use the armv5 builds

- there do seem to be deployed chips with only VFPv3d16 and no Neon (notably the Tegra chips), so we will not require Neon, so they can also use the new baseline

It's just really unfortunate that the rpi chose a trailing edge CPU for essentially "we happened to have this" reasons and then it blew up to become a super popular board because they got the price point and the ecosystem support right.

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.