4 ms·
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 cu
by ethbr0 5y ago
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?
- voakbasda 5y agoThere 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.
- Pet_Ant 5y agoIs there an existing standard that board implementations can rally around? Something like OpenBoot? Make it a defacto standard.
- swiley 5y agoWe have device tree. The problem on ARM is 1) Qualcomm and other SoC vendors fighting interoperability and 2) Users not understanding device tree.
- goodpoint 5y agoThe 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.
- rjsw 5y agoWhether RISC-V ISA extensions are allowed or not is unrelated to the problems seen with ARM SoCs putting peripheral devices at different addresses.
- a9h74j 5y agoCould a device table [for on-chip peripherals] be put right on chip?
- formerly_proven 5y agoYes, 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).
- goodpoint 5y agoSure, but the question was about diversity explosion in general.
- brucehoult 5y agoIt 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.
- stffrdhrn 5y agoThe 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/linux.git/tree/arch/riscv/configs?h=v5.13 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/linux.git/tree/arch/arm/configs?h=v5.13 https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin... Source: https://github.com/esmil/linux/pull/6#issuecomment-844135991 https://github.com/esmil/linux/pull/6#issuecomment-844135991