5 ms·

Will RISCV have the same mess that ARM ecosystem has of not standardising or having a single BIOS or similar system... such that you have to compile a custom im

Will RISCV have the same mess that ARM ecosystem has of not standardising or having a single BIOS or similar system... such that you have to compile a custom image for every board? One thing PC has going for it, is that you can install one Linux distro into any PC board. This is not the same for ARM boards.

rwmj 5y ago
Well that's a very good question. At the moment the reality is something of a mess, because someone looked at Arm and though that must be a good idea. Plus the RISC-V Foundation has even less control over implementers than Arm does (which doesn't have a lot). The good news is that the foundation is defining various platform specs. For servers it'll include a standard firmware spec plus open source firmware implementation and a few other bits. Maybe working UEFI one day. (https://lists.riscv.org/g/tech-unixplatformspec https://lists.riscv.org/g/tech-unixplatformspec https://github.com/riscv/riscv-platform-specs https://github.com/riscv/riscv-platform-specs https://github.com/riscv-non-isa/riscv-sbi-doc https://github.com/riscv-non-isa/riscv-sbi-doc)
- dlojudice 5y ago
  I'm sure this mess could be avoided if instead of a doc only there would have a test suit exercising the implementation. This should be true for many foundations and their specs.
xvilka 5y ago
PC BIOS and UEFI are a mess as well. They are proprietary blobs guarded by Intel and alike. At least ARM had most bootloading open with uBoot, for example. Also PC firmware code on modern platforms is often bigger than Linux kernel. Hardly a good example. I sincerely hope RISC-V will avoid relying on UEFI and opt out for something more sensible.
- rwmj 5y ago
  Not really. Arm boards only work with uBoot because of a vast behind-the-scenes effort to integrate all the crappy forks and out of tree kernel drivers into Linux distros.
- potiuper 5y ago
  GPU resizable bar requires UEFI.
  - zamadatix 5y ago
    It has no hard requirement to be on UEFI rather it isn't compatible with legacy BIOS.
    - potiuper 5y ago
      "Hard requirement" is a vague. At this moment in time no commercially available non-UEFI hardware exists to run GPUs supporting resizable bar.
- zamadatix 5y ago
  There are solid open implementations of UEFI, one has actually been ported to the Pis and can boot Windows and Linux and so on.
- aseipp 5y ago
  Many PC UEFI builds from mega manufacturers are heavily customized, but a lot of them are also just based on TianoCore, including the modern RPi UEFI firmware builds. Nothing very strange about it. More specifically, the distinguishing thing here for RISC-V is the standardization of SBI, which will be a requirement for either UEFI or U-Boot to target it. U-Boot works on the million ARM devices it does today thanks to absurd effort from many people, not because ARM made it especially easy; with SBI in theory that can be made easier. Aside from that people can argue whether UEFI is bloated and how their favorite is the perfect alternative, but as a user who would want to boot a RISC-V based desktop platform (and someone who has supported RISC-V, implemented their own designs, etc) I don't care and it doesn't matter; it actually does the job, and is a known quantity to aim for i.e. familiar and at least nominally understood by developers, users, and manufacturers. And I say that as someone who actually likes U-Boot and has patched it on a few occasions myself for my own targets.
  - mistrial9 5y ago
    > I don't care and it doesn't matter you can not care, but it does matter
ncmncm 5y ago
The complete lack of standardization of which ISA "extensions" each chip has means you will want a build targeting the chip you have, anyway.
- rwmj 5y ago
  This isn't true. The required extensions are specified in the Unix platform spec, and any additional extensions are detected and used at runtime (exactly how things work on x86 in fact).
- davidlt 5y ago
  There are Profiles specs and Platforms specs, that will be regularly updated. This means software has a fixed target on which it can depend.
zibzab 5y ago
Unpopular opinion: it will be much worse. RISC-V is meant to be flexible and you can create CPUs that look very very different. Furthermore, some early chips used own solutions in some areas as a standard way of doing things was yet not available (e.g. memory protection). So we have a hardware landscape with extreme fragmentation. If people cannot agree on the hardware, I have hard time seeing them agreeing on the firmware.
- IshKebab 5y ago
  I don't think that's an unpopular opinion. It's more of an unfortunate truth.
- hakfoo 5y ago
  I'm not worried about the "early designs used their own solutions." Expecting standards compliance before the existence of standards requires the Time Travel extensions to the architecture. :) The problem is that you need a moment where the market switches from "hardware drives software advancement" to "software drives hardware standardization." Think of the x86 architecture-- in 1979, if you were designing a new 8086 computer, you'd want to design the best disc controller, memory map, and graphics modes you could, and build software to show them off. By 1986, you wanted to design ones that looked exactly like an IBM 5150 so that Lotus 1-2-3 and Flight Simulator would run out of the box. What specifically would be the comparable trigger for ARM or RISC-V? You need killer apps that sit close to the hardware, and are closed-source. It can't just be something that runs on top of Linux/BSD/Android/etc. because then vendors will cheat by building an unsupportable hairball of custom bootcode and drivers to get you to an ABI-compatible OS and say "that's compatible enough." It can't be open-source because vendors will cheat by hacking it to fit into their custom hardware and firmware designs. I'm not sure it's feasible today. Today's killer apps are not built with the 70s/80s mindset of writing directly to device registers for 1% more speed.
mhh__ 5y ago
RISCV could end up being even worse if we ended up with a high performance fork of RV64
- one_off_comment 5y ago
  Why would that be worse?
  - mhh__ 5y ago
    All the issues ARM has but now with added ISA differences which may or may not be actually compliant with any standard let alone the one on the RISC-V website.
    - one_off_comment 5y ago
      I don't believe the ISA dictates the implementation, so theoretically someone could implement the D extension to get 64-bit precision floating point in a more performant way than other implementations. If someone altered the ISA in order to get performance, I don't think you could accurately call it RISC-V anymore.
      - IshKebab 5y ago
        Sometimes ISAs restrict possible implementations so you can't implement faster designs.
eschaton 5y ago
There’s some plan for a common bootstrap and firmware interface. Personally though I think they should standardize on IEEE 1275 Open Firmware. It’s a standard, there are multiple good open source implementations with reasonable licenses, it’s lightweight, and it’s extremely flexible. Who needs the complexity of UEFI?

rwmj 5y ago

Well that's a very good question. At the moment the reality is something of a mess, because someone looked at Arm and though that must be a good idea. Plus the RISC-V Foundation has even less control over implementers than Arm does (which doesn't have a lot). The good news is that the foundation is defining various platform specs. For servers it'll include a standard firmware spec plus open source firmware implementation and a few other bits. Maybe working UEFI one day. (https://lists.riscv.org/g/tech-unixplatformspec https://lists.riscv.org/g/tech-unixplatformspec https://github.com/riscv/riscv-platform-specs https://github.com/riscv/riscv-platform-specs https://github.com/riscv-non-isa/riscv-sbi-doc https://github.com/riscv-non-isa/riscv-sbi-doc)

dlojudice 5y ago
I'm sure this mess could be avoided if instead of a doc only there would have a test suit exercising the implementation. This should be true for many foundations and their specs.

xvilka 5y ago

PC BIOS and UEFI are a mess as well. They are proprietary blobs guarded by Intel and alike. At least ARM had most bootloading open with uBoot, for example. Also PC firmware code on modern platforms is often bigger than Linux kernel. Hardly a good example. I sincerely hope RISC-V will avoid relying on UEFI and opt out for something more sensible.

rwmj 5y ago
Not really. Arm boards only work with uBoot because of a vast behind-the-scenes effort to integrate all the crappy forks and out of tree kernel drivers into Linux distros.
potiuper 5y ago
GPU resizable bar requires UEFI.
- zamadatix 5y ago
  It has no hard requirement to be on UEFI rather it isn't compatible with legacy BIOS.
  - potiuper 5y ago
    "Hard requirement" is a vague. At this moment in time no commercially available non-UEFI hardware exists to run GPUs supporting resizable bar.
zamadatix 5y ago
There are solid open implementations of UEFI, one has actually been ported to the Pis and can boot Windows and Linux and so on.
aseipp 5y ago
Many PC UEFI builds from mega manufacturers are heavily customized, but a lot of them are also just based on TianoCore, including the modern RPi UEFI firmware builds. Nothing very strange about it. More specifically, the distinguishing thing here for RISC-V is the standardization of SBI, which will be a requirement for either UEFI or U-Boot to target it. U-Boot works on the million ARM devices it does today thanks to absurd effort from many people, not because ARM made it especially easy; with SBI in theory that can be made easier. Aside from that people can argue whether UEFI is bloated and how their favorite is the perfect alternative, but as a user who would want to boot a RISC-V based desktop platform (and someone who has supported RISC-V, implemented their own designs, etc) I don't care and it doesn't matter; it actually does the job, and is a known quantity to aim for i.e. familiar and at least nominally understood by developers, users, and manufacturers. And I say that as someone who actually likes U-Boot and has patched it on a few occasions myself for my own targets.
- mistrial9 5y ago
  > I don't care and it doesn't matter you can not care, but it does matter

ncmncm 5y ago

The complete lack of standardization of which ISA "extensions" each chip has means you will want a build targeting the chip you have, anyway.

rwmj 5y ago
This isn't true. The required extensions are specified in the Unix platform spec, and any additional extensions are detected and used at runtime (exactly how things work on x86 in fact).
davidlt 5y ago
There are Profiles specs and Platforms specs, that will be regularly updated. This means software has a fixed target on which it can depend.

zibzab 5y ago

Unpopular opinion: it will be much worse. RISC-V is meant to be flexible and you can create CPUs that look very very different. Furthermore, some early chips used own solutions in some areas as a standard way of doing things was yet not available (e.g. memory protection). So we have a hardware landscape with extreme fragmentation. If people cannot agree on the hardware, I have hard time seeing them agreeing on the firmware.

IshKebab 5y ago
I don't think that's an unpopular opinion. It's more of an unfortunate truth.
hakfoo 5y ago
I'm not worried about the "early designs used their own solutions." Expecting standards compliance before the existence of standards requires the Time Travel extensions to the architecture. :) The problem is that you need a moment where the market switches from "hardware drives software advancement" to "software drives hardware standardization." Think of the x86 architecture-- in 1979, if you were designing a new 8086 computer, you'd want to design the best disc controller, memory map, and graphics modes you could, and build software to show them off. By 1986, you wanted to design ones that looked exactly like an IBM 5150 so that Lotus 1-2-3 and Flight Simulator would run out of the box. What specifically would be the comparable trigger for ARM or RISC-V? You need killer apps that sit close to the hardware, and are closed-source. It can't just be something that runs on top of Linux/BSD/Android/etc. because then vendors will cheat by building an unsupportable hairball of custom bootcode and drivers to get you to an ABI-compatible OS and say "that's compatible enough." It can't be open-source because vendors will cheat by hacking it to fit into their custom hardware and firmware designs. I'm not sure it's feasible today. Today's killer apps are not built with the 70s/80s mindset of writing directly to device registers for 1% more speed.

mhh__ 5y ago

RISCV could end up being even worse if we ended up with a high performance fork of RV64

one_off_comment 5y ago
Why would that be worse?
- mhh__ 5y ago
  All the issues ARM has but now with added ISA differences which may or may not be actually compliant with any standard let alone the one on the RISC-V website.
  - one_off_comment 5y ago
    I don't believe the ISA dictates the implementation, so theoretically someone could implement the D extension to get 64-bit precision floating point in a more performant way than other implementations. If someone altered the ISA in order to get performance, I don't think you could accurately call it RISC-V anymore.
    - IshKebab 5y ago
      Sometimes ISAs restrict possible implementations so you can't implement faster designs.

eschaton 5y ago

There’s some plan for a common bootstrap and firmware interface. Personally though I think they should standardize on IEEE 1275 Open Firmware. It’s a standard, there are multiple good open source implementations with reasonable licenses, it’s lightweight, and it’s extremely flexible. Who needs the complexity of UEFI?