News for hackers. Stuff that matters.
Re:ARM to prohibit proximity of CPU w 3rd-party modules in o... by throw827474737 on Tuesday November 01, 2022 @08:15AM (#33420150)
> RISC-V starting to explode.

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!

Re:ARM to prohibit proximity of CPU w 3rd-party modules in o... by BirAdam on Tuesday November 01, 2022 @08:54AM (#33420494)
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.
Re:ARM to prohibit proximity of CPU w 3rd-party modules in o... by stevefan1999 on Tuesday November 01, 2022 @09:29AM (#33420904)
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.

[1]: https://www.cnx-software.com/2022/07/08/risc-x-top-chinese-s...

Re:ARM to prohibit proximity of CPU w 3rd-party modules in o... by delfinom on Tuesday November 01, 2022 @09:02AM (#33420581)
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.

Re:ARM to prohibit proximity of CPU w 3rd-party modules in o... by snvzz on Wednesday November 02, 2022 @05:46AM (#33433347)
>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.

Re:ARM to prohibit proximity of CPU w 3rd-party modules in o... by stoplying1 on Tuesday November 01, 2022 @10:30AM (#33421708)
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.