News for hackers. Stuff that matters.
Re:XiangShan open-source 64-bit RISC-V processor to rival Ar... by ethbr0 on Monday July 05, 2021 @12:21PM (#27739497)
Are there higher level abstraction efforts in the linux kernel to prevent a hypothetical custom RISC-V diversity explosion from ending up quite as messily as custom ARM did?

Afaict, most of the ARM ugliness was around non-"CPU" SoC components. But it definitely seemed like kernel code organization wasn't ready for a 10x (or 100x) explosion of popular SoCs.

And the entire point of open sourced RISC-V cores is that they would enable even more chip diversity, no?

Re:XiangShan open-source 64-bit RISC-V processor to rival Ar... by stffrdhrn on Monday July 05, 2021 @10:23PM (#27743666)
The riscv kernel maintainer is not interested in maintaining many different configs for many different SoC. So that is one effort to avoid fragmentation. If you look at the riscv config tree we can see about 5 configs:

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...

Compare this to the ARM tree there are a few more:

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...

Source: https://github.com/esmil/linux/pull/6#issuecomment-844135991

Re:XiangShan open-source 64-bit RISC-V processor to rival Ar... by voakbasda on Monday July 05, 2021 @12:44PM (#27739725)
There have been discussions about this, and my conclusion is that there definitely could be a problem on the order of ARM’s. With luck, RISC-V will learn from history and not doom itself to repeat the same mistakes.
Re:XiangShan open-source 64-bit RISC-V processor to rival Ar... by Pet_Ant on Monday July 05, 2021 @02:17PM (#27740504)
Is there an existing standard that board implementations can rally around? Something like OpenBoot? Make it a defacto standard.
Re:XiangShan open-source 64-bit RISC-V processor to rival Ar... by swiley on Monday July 05, 2021 @10:19PM (#27743645)
We have device tree. The problem on ARM is

1) Qualcomm and other SoC vendors fighting interoperability

and

2) Users not understanding device tree.

Re:XiangShan open-source 64-bit RISC-V processor to rival Ar... by goodpoint on Monday July 05, 2021 @01:50PM (#27740252)
The RISC-V ISA specifically allows for custom extensions.

Unfortunately, the licensing model does require the implementations to be FLOSS. This encourages creating a lot of closed stuff with different and incompatible extensions.

Re:XiangShan open-source 64-bit RISC-V processor to rival Ar... by brucehoult on Tuesday July 06, 2021 @01:12AM (#27744453)
It doesn't matter. As long as they implement the core RV64GC instruction set correctly, standard software will run, and if they implement privileged architecture 1.10 or later correctly then the standard Linux kernel will run.

Vendors are free to use custom extensions to implement the bootloader and SBI. Normal code and even the OS won't see that. They can also use custom extensions in hardware drivers. Even in libc, if they want, though that gives more maintenance work.

Re:XiangShan open-source 64-bit RISC-V processor to rival Ar... by rjsw on Monday July 05, 2021 @02:57PM (#27740860)
Whether RISC-V ISA extensions are allowed or not is unrelated to the problems seen with ARM SoCs putting peripheral devices at different addresses.
Re:XiangShan open-source 64-bit RISC-V processor to rival Ar... by a9h74j on Monday July 05, 2021 @03:35PM (#27741169)
Could a device table [for on-chip peripherals] be put right on chip?
Re:XiangShan open-source 64-bit RISC-V processor to rival Ar... by formerly_proven on Monday July 05, 2021 @03:56PM (#27741314)
Yes, that's a devicetree. Those can be tacked onto the kernel image or dynamically loaded from the chip's firmware (which most likely gets it from the firmware flash).
Re:XiangShan open-source 64-bit RISC-V processor to rival Ar... by goodpoint on Monday July 05, 2021 @05:51PM (#27742162)
Sure, but the question was about diversity explosion in general.