3 ms·

I don't know about interrupts/device tree/etc. but at least for the boot process itself, UEFI/EDK2 was ported to RISC-V. (I actually learned this because I was

by jchw 3y ago

I don't know about interrupts/device tree/etc. but at least for the boot process itself, UEFI/EDK2 was ported to RISC-V. (I actually learned this because I was looking up information about the Windows PE format and was surprised to see relocations support for RISC-V; they needed to add support for it to the PE specification since PE is the native binary format of UEFI!)

snvzz 3y ago
UEFI/EDK2 has been demoed with the JH7110 on VisionFive2. It's not quite complete yet (e.g. lacks drivers for hdmi display and usb), but it boots Linux. The simpler u-boot SPL --> opensbi --> u-boot flow is mature, and patches have been submitted upstream.
mort96 3y ago
UEFI has also been ported to ARM, yet we still have all kinds of issues booting ARM boards with generic images.
- jchw 3y ago
  Yep, it's not the full story. For ARM, the standard for that is SystemReady. UEFI is nice, but it realistically only defines the boot process. Once the OS has taken over there's a ton of other stuff that it has to do that will be defined by not the ISA of the CPU but by the platform, like enumerate devices or coordinate interrupts. For those two things in particular, it looks like a form of ACPI may be supported by some RISC-V platforms, and there's PLIC and APLIC for interrupts. Undoubtedly there are more things that I'm not thinking of, but I think that's a good start, as those are two things that were in fact NOT standard on many ARM SBCs.
  - mort96 3y ago
    That seems correct to my understanding. So the question is, will RISC-C SBCs standardise on some set of technologies which makes it possible to make generic RV64 images which work across a host of machines? Or will those technologies stay niche, like SystemReady has in the ARM world?
    - jchw 3y ago
      Good question; I hope they choose the path of standards early on, but it's not clear yet. I wonder if there's a genuine cost-cutting reason to not implement standards like ACPI. I believe SiFive was involved in the ACPI-on-RISC-V work, so that's probably a good sign. But honestly? I think we'll just have to wait and see.
    - snvzz 3y ago
      Yes, and already done. For UEFI specifically, there's a relevant spec[0]. 0. https://github.com/riscv-non-isa/riscv-uefi/releases https://github.com/riscv-non-isa/riscv-uefi/releases
      - mort96 3y ago
        Oh, those technologies have already become non-niche? So if I survey the world of RISC-V SBCs, I will find that they can all pretty much just boot the same generic RV64 Linux distro images? No?
        snvzz 3y ago
        AIUI Sifive's most recent board and VisionFive2 have working EDK2 UEFI. VF2's is early (boots Linux, but only from mmc. No NVMe, USB or display yet), but being worked on by StarFive themselves. In the future, with OS-A Platform spec, you can expect RISC-V computers to be no different than PCs from a user perspective. Under the hood, the platform is modern, and carries none of the legacy x86 PCs do. The scope of standardization is also broader: It's not just interrupts, timers or memory map, but also things like the interfaces for Watchdogs, GPIOs are being standardized.

by jchw 3y ago

snvzz 3y ago

UEFI/EDK2 has been demoed with the JH7110 on VisionFive2. It's not quite complete yet (e.g. lacks drivers for hdmi display and usb), but it boots Linux. The simpler u-boot SPL --> opensbi --> u-boot flow is mature, and patches have been submitted upstream.

mort96 3y ago

UEFI has also been ported to ARM, yet we still have all kinds of issues booting ARM boards with generic images.

jchw 3y ago
Yep, it's not the full story. For ARM, the standard for that is SystemReady. UEFI is nice, but it realistically only defines the boot process. Once the OS has taken over there's a ton of other stuff that it has to do that will be defined by not the ISA of the CPU but by the platform, like enumerate devices or coordinate interrupts. For those two things in particular, it looks like a form of ACPI may be supported by some RISC-V platforms, and there's PLIC and APLIC for interrupts. Undoubtedly there are more things that I'm not thinking of, but I think that's a good start, as those are two things that were in fact NOT standard on many ARM SBCs.
- mort96 3y ago
  That seems correct to my understanding. So the question is, will RISC-C SBCs standardise on some set of technologies which makes it possible to make generic RV64 images which work across a host of machines? Or will those technologies stay niche, like SystemReady has in the ARM world?
  - jchw 3y ago
    Good question; I hope they choose the path of standards early on, but it's not clear yet. I wonder if there's a genuine cost-cutting reason to not implement standards like ACPI. I believe SiFive was involved in the ACPI-on-RISC-V work, so that's probably a good sign. But honestly? I think we'll just have to wait and see.
  - snvzz 3y ago
    Yes, and already done. For UEFI specifically, there's a relevant spec[0]. 0. https://github.com/riscv-non-isa/riscv-uefi/releases https://github.com/riscv-non-isa/riscv-uefi/releases
    - mort96 3y ago
      Oh, those technologies have already become non-niche? So if I survey the world of RISC-V SBCs, I will find that they can all pretty much just boot the same generic RV64 Linux distro images? No?
      - snvzz 3y ago
        AIUI Sifive's most recent board and VisionFive2 have working EDK2 UEFI. VF2's is early (boots Linux, but only from mmc. No NVMe, USB or display yet), but being worked on by StarFive themselves. In the future, with OS-A Platform spec, you can expect RISC-V computers to be no different than PCs from a user perspective. Under the hood, the platform is modern, and carries none of the legacy x86 PCs do. The scope of standardization is also broader: It's not just interrupts, timers or memory map, but also things like the interfaces for Watchdogs, GPIOs are being standardized.