I hope for that!! But will it be better in regards to not every instantiation needings its very own tiny Linux kernel patch and device trees? Or similar one level down into the embedded world, a true CMSIS like HAL that includes peripherals, not the half-assed attempt of ARM-CMSIS where you still always need to fiddle with vendor's peripheral driver SDKs? That would be so great!
I expect that some RISC-V implementations will always need patches, but as any ISA matures it tends to get standardized and the implementations start to look more and more similar. In the case of RISC-V, the costs for both the implementer and the customer will get better as it becomes more standardized, which will help to push both more implementation and more adoption. This in turn drives more standardization… it’s a feedback loop. Then, you will always have your one-off oddities. These are important. Sometimes, semi-custom platforms are for experimentation, and sometimes they’re just super niche use-cases. RISC-V is great in these situations due to zero license fees.
It is not necessarily zero license fee because you can theoretically spun-off RISC-V designs to your own proprietary ISA. Some Chinese scientists did a case study on this possibility by creating a new ISA called RISC-X [1], but they are not progressing to do any harm right now.
RISCV isn't that standardized that there won't be a plethora and mess of peripherals available from every manufacturer. It will be much like ARM.
In many ways it's a good thing. There's no point in more than one manufacturer existing if everything was standardized down to the literal register map. They all end up using the same fabs anyway.
>RISCV isn't that standardized that there won't be a plethora and mess of peripherals available from every manufacturer. It will be much like ARM.
Hardware, sure. Although not as much, as standarization goes further than ARM, with the platform profiles including e.g. standard serial ports, interrupt controllers and so on.
In practice, on the software side, it'll be closer to your usual IBM PC clone.
The boot process, with SBI and UEFI standarized, is also part of the relevant platform profiles. How to get to the point where a kernel loaded in memory is defined. The environment this kernel finds is also defined. The kernel does actually get a description of the hardware.
ARM did very little of that, and did it too late. RISC-V has it all in place before the hardware is even there, so it should be alright.
Signs so far point to a big fat no (as someone running a custom uboot build on visionfive that works better than the bsp from manufacturer). Plenty of blobs, still device trees, etc.
I hope for that!! But will it be better in regards to not every instantiation needings its very own tiny Linux kernel patch and device trees? Or similar one level down into the embedded world, a true CMSIS like HAL that includes peripherals, not the half-assed attempt of ARM-CMSIS where you still always need to fiddle with vendor's peripheral driver SDKs? That would be so great!