Linux 5.14 Supports Some Exciting Features With RISC-V

[phoronix]

Phoronix: RISC-V Supports Some Exciting Features With Linux 5.14

The RISC-V architecture code supports more functionality with the in-development Linux 5.14 kernel...

https://www.phoronix.com/scan.php?page=news_item&px=RISC-V-More-With-Linux-5.14

[tildearrow]

The title and the text are very confusing. Linux is supporting more RISC-V features (and there is more RISC-V work), not the other way around.

[uid313]

RISC-V is a pipe dream that will never be. All boards and booted and initialized in their own quirky unique way, there is no standard for booting such as UEFI. There is no power management such as ACPI or sleep states.

There are no consumer demand for it, and there are no manufacturers interested in bringing forth any devices, hardware or products with it.

Any adoption of it would lead to fragmentation and incompatibility due to proprietary extensions.

A pure CPU has little appeal these days values being placed on integrated platforms where there is expectations of GPU, sound, network, 5G and AI accelerators.

[coder]

RISC-V is a pipe dream that will never be.

It's already being used in a lot of embedded contexts.

For other stuff, it's still early days.

All boards and booted and initialized in their own quirky unique way, there is no standard for booting such as UEFI. There is no power management such as ACPI or sleep states.

These seem like fixable problems.

Any adoption of it would lead to fragmentation and incompatibility due to proprietary extensions.

Yes, it's an issue. Not insurmountable, as we've seen with many iterations of other ISAs.

And runtime code generators like web assembly and JavaScript JIT compilers can use whatever extensions the host has available.

A pure CPU has little appeal these days values being placed on integrated platforms where there is expectations of GPU, sound, network, 5G and AI accelerators.

Imagination still exists as an independent GPU vendor, and AMD will probably license RDNA to someone big enough.

[tildearrow]

RISC-V is a pipe dream that will never be. All boards and booted and initialized in their own quirky unique way, there is no standard for booting such as UEFI. There is no power management such as ACPI or sleep states.

There are no consumer demand for it, and there are no manufacturers interested in bringing forth any devices, hardware or products with it.

Any adoption of it would lead to fragmentation and incompatibility due to proprietary extensions.

A pure CPU has little appeal these days values being placed on integrated platforms where there is expectations of GPU, sound, network, 5G and AI accelerators.

That's because RISC-V is just a specification for a processor architecture, just like Arm and POWER.
It does not specify how to boot a device.

The reason why is x86 so standardized is because in 1980 IBM chose the Intel 8088 for its PC, and when clones appeared, IBM encouraged the cloning process (instead of stopping it), which caused the BIOS architecture to become a standard in 100% of x86 computers.
EFI was developed by Intel only after seeing BIOS was the standard (but it was a flawed/dated standard), and even so several EFI implementations have a BIOS compatibility mode.

This lack of standardization irks me as well, but it applies to Arm and POWER too...

[Brane215]

RISC-V is a pipe dream that will never be.All boards and booted and initialized in their own quirky unique way, there is no standard for booting such as UEFI. There is no power management such as ACPI or sleep states.

Which is good. Both "established standards" are pile of cr*p.
New approach would freshen things a bit.

There are no consumer demand for it, and there are no manufacturers interested in bringing forth any devices, hardware or products with it.

Market always like cheaper, unlimited and unencumbered products.
RISC-V has no historic baggage, patent ownerships nor licence red tapes.

A pure CPU has little appeal these days values being placed on integrated platforms where there is expectations of GPU, sound, network, 5G and AI accelerators.

Pure CPU is foundation of everything else. Which is coming along.

[brucehoult]

The reason why is x86 so standardized is because in 1980 IBM chose the Intel 8088 for its PC, and when clones appeared, IBM encouraged the cloning process (instead of stopping it)

No, that's not right. IBM did everything they could to stop clones. However the motherboard was simple and used off-the-shelf parts and you can't protect an arrangement of standard parts. The only protection was that the BIOS was software and copyrighted. IBM sued a lot of companies that simply copied the BIOS code, and won.

Fortunately for the clone companies, the BIOS was small -- just a few KB -- and had well documented entry points, and was not all that well written. It was a relatively simple job to do a clean-room reimplementation with the same functionality. Both COMPAQ and Phoenix did this.

And then there was nothing that could be done to stop clones, except to change the PC architecture incompatibly. IBM tried this with the PS/2, but failed to take the market with them. Much like Intel a decade later with the Itanium attempt to make AMD's x86 license irrelevant.

[coder]

IBM tried this with the PS/2, but failed to take the market with them.

Ah, PS/2. MCA bus, VGA, and it was one of the early i386 machines. Not to mention those mini-DIN mouse & keyboard connectors. I'm reading you could even get it with OS/2 or AIX.

We had a PCs Limited, which was later renamed to Dell Computer Corp. Shoulda bought some stock in that one.

[eydee]

What a title. So it's the architecture supporting some Linux features, not the other way around. I wonder how they patch already manufactured units. What patch can rearrange transistors in a CPU?

[coder]

What patch can rearrange transistors in a CPU?

All joking aside, they usually they reserve some space, especially in the metal layer, so that respins don't have to redo the floorplan of a chip. Of course, there are also microcode-level fixes you can often deploy to units in the field.