RISC-V is addressing this issue quite directly. For things like desktops, laptops, SBCs and servers we have the RVA23 profile which defines quite specifically what features a chip must support to ensure code portability.
On top of this, there are platform specifications. For example, the server spec is about to finalize next month. It extends RVA23 which things like UEFI, SBI, and ACPI to ensure that your can take something like a Linux distro and easily install it on any RISC-V server, like you can in the world of x86-64.
> we have phones that are only good for landfill once their support lifetime is up
RISC-V will probably not solve that problem in general.
First, the ISA cannot really demand that your phone avoid a Broadcom wireless chip that requires proprietary firmware for example.
Also, the phone vendor can still lock down the devices to prevent running arbitrary code.
Thankfully, the RISC-V world is developing a culture of openness. If a company wants to create a fully “open” phone, they are quite likely to adopt RISC-V. And, because of RISC-V, even the SoC itself could be fully Open Source.
But your typical Android phone is not going to get more Open just because they contain a RISC-V CPU.
A great case study is the companies that implemented the pre-release vector standard in their chips.
The final version is different in a few key ways. Despite substantial similarities to the ratified version, very few people are coding SIMD for those chips.
If a proprietary extension does something actually useful to everyone, it’ll either be turned into an open standard or a new open standard will be created to replace it. In either case, it isn’t an issue.
The only place I see proprietary extensions surviving is in the embedded space where they already do this kind of stuff, but even that seems to be the exception with the RISCV chips I’ve seen. Using standard compilers and tooling instead of a crappy custom toolchain (probably built on an old version of Eclipse) is just nicer (And cheaper for chip makers).
Extensions allow you to address specific customer needs, evolve specific use cases, and experiment. AI is another perfect fit. And the hyperscaler market is another one where the hardware and software may come from the same party and be designed to work together. Compatibility with the standard is great for toolchains and off-the-shelf software but there is no need for a hyperscaler or AI specific extension to be implemented by anybody else. If something more universally useful is discovered by one party, it can be added to a future standard profile.
If you try to make your own extensions, the standard compiler flags won’t be supporting it and it’ll probably be limited to your own software. If it’s actually good, you’ll have to get everyone on board with a shared, open design, then get it added to a future RVA standard.
Some stuff like BRS (Boot and Runtime Services Specification)and SBI (Supervisor Binary Interface) already exist.
Is this really true? The computer ecosystem is more open now than ever. The original PC BIOS (which PC-compatible manufacturers needed to implement) was never an open, documented standard. It was a proprietary, closed system made by IBM. It's pretty fair to say that IBM didn't anticipate a PC/x86 ecosystem developing around their product. They even sued companies who made their own compatible BIOSes (like Corona). Intel didn't really have much to do with the success of the product at that point in time either, much less Microsoft.
In contrast, every widely-used modern system for hardware abstraction (UEFI/ACPI/DeviceTree/OpenSBI/etc) are open, royalty-free standards that anyone can use. Their implementation in ARM is newer, and inconsistent, but that's only because of how hugely diverse the ARM ecosystem is.
I think the issue is that desktop and server computing are “open” in the sense that you have full control over the software you run on them. So people interpret the dominant desktop and server platform architecture (the world of x86-64) as being open.
The embedded world is mostly closed, you are meant to run the software your hardware comes with. The platform’s popular there are considered less open (ARM and RISC-V).
Mobile devices like phones and tablets are historically closed devices, regardless of ISA. They are generally getting more closed in the name of security.
It is not the ISA that is “open” but the industry.
That said, in RISC-V, there is a sub-current of openness. I do not think that will overcome the industry tendencies in general, but there will be a small cadre of folks trying to create an open presence in every niche. The good news is that there is nothing to stop them. They will succeed eventually.
On the other hand, ARM sells the cores to SoC vendors (and doesn't care much what becomes of it), SoC vendors ducktape the ARM cores to a bunch of Synopsys peripherals and sell the resulting SoCs to smartphone and car makers (and doesn't care much for the product). System integrators throw Android on top and sell it to the customers. Then Google, who get all the cream via Play, hides all the mess behind a thousand layers of Java abstractions.
DeviceTree is an offshot of Sun's OpenFirmware (and it leaves out all the hard stuff - OpenFirmware had Forth, DeviceTree expects the kernel to support every single brand of fan switch). OpenSBI is a disaster. I'm sorry, but what kind of bright mind came up with the idea of hiding damn *timer* behind a privilege switch? Timers were enough of a pain point on x86 already, then it settled on userspace-accesable RDTSC. RISC-V SBI? Reproducing x86 one stupid decision at a time.
Sadly, yes. RISC-V vendors are repeating literally every single mistake that the ARM ecosystem made and then making even dumber ones.
One reason UNIX became widely adopted, besides being freely available versus the other OSes, was that allowed companies to abstract their hardware differences, offering some market differentiation, while keeping some common ground.
Those phones common ground is called Android with Java/Kotlin/C/C++ userspace, folks should stop seeing them as GNU/Linux.