6 ms·

How does it boot? Or is RISC-V going to follow the same problems as the ARM SBC system where each board has an obscure and unique boot process meaning images n

How does it boot? Or is RISC-V going to follow the same problems as the ARM SBC system where each board has an obscure and unique boot process meaning images need to be carefully pre-built with who knows what installed for each board.

camel-cdr 3y ago
I'm not certain, but I think that's what opensbi is for: https://github.com/riscv-software-src/opensbi https://github.com/riscv-software-src/opensbi
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.
snvzz 3y ago
>is RISC-V going to follow the same problems as the ARM SBC system where each board has an obscure and unique boot process meaning images need to be carefully pre-built with who knows what installed for each board. No. Instead, RISC-V standardized the boot process early on, avoiding that situation.
- fellowmartian 3y ago
  That wasn’t actually true on the boards I’ve tried, MangoPi MQ-Pro being the most recent. Look here for more details: https://linux-sunxi.org/Allwinner_Nezha https://linux-sunxi.org/Allwinner_Nezha Maybe if it had a “standard” U-Boot flashed onto a SPI chip you could standardize the process, but then you can do the same with ARM (this is what TowBoot does), so RISC-V is not a benefit in this instance.
  - brucehoult 3y ago
    Things are still in a rapid development phase, especially for the new boards in the last four months (VF2, Star64, LicheePi4A), figuring out what things are actually necessary. The aim is definitely to get a board-specific (but standard interface) uboot and SBI in SPI flash on each board, and then have a single kernel + root FS image (for each distro) that can run on anything. One obstacle is that some people are resisting upstreaming support for the THead C906 and C910 cores "non standard" physical memory attributes and vector implementation into the toolchain and kernel. Both those things were 2 1/2 years away from standardisation in mid 2019 when THead designed their cores, and it takes 3 1/2 to 4 years to get a new core into cheap mass production SoCs and on to boards, so they really could not have done better (other than to simply not implement that kind of feature at all).
- numpad0 3y ago
  How did they handle implementation differences between SoCs? Do all RISC-V SoC have exact same memory maps and SFR behaviors?
  - rsaxvc 3y ago
    There are memory map and SFR differences. I bet it's similar to how Linux on Arm/PowerPC/MIPS handle it with device trees.

camel-cdr 3y ago

I'm not certain, but I think that's what opensbi is for: https://github.com/riscv-software-src/opensbi https://github.com/riscv-software-src/opensbi

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.

snvzz 3y ago

>is RISC-V going to follow the same problems as the ARM SBC system where each board has an obscure and unique boot process meaning images need to be carefully pre-built with who knows what installed for each board. No. Instead, RISC-V standardized the boot process early on, avoiding that situation.

fellowmartian 3y ago
That wasn’t actually true on the boards I’ve tried, MangoPi MQ-Pro being the most recent. Look here for more details: https://linux-sunxi.org/Allwinner_Nezha https://linux-sunxi.org/Allwinner_Nezha Maybe if it had a “standard” U-Boot flashed onto a SPI chip you could standardize the process, but then you can do the same with ARM (this is what TowBoot does), so RISC-V is not a benefit in this instance.
- brucehoult 3y ago
  Things are still in a rapid development phase, especially for the new boards in the last four months (VF2, Star64, LicheePi4A), figuring out what things are actually necessary. The aim is definitely to get a board-specific (but standard interface) uboot and SBI in SPI flash on each board, and then have a single kernel + root FS image (for each distro) that can run on anything. One obstacle is that some people are resisting upstreaming support for the THead C906 and C910 cores "non standard" physical memory attributes and vector implementation into the toolchain and kernel. Both those things were 2 1/2 years away from standardisation in mid 2019 when THead designed their cores, and it takes 3 1/2 to 4 years to get a new core into cheap mass production SoCs and on to boards, so they really could not have done better (other than to simply not implement that kind of feature at all).
numpad0 3y ago
How did they handle implementation differences between SoCs? Do all RISC-V SoC have exact same memory maps and SFR behaviors?
- rsaxvc 3y ago
  There are memory map and SFR differences. I bet it's similar to how Linux on Arm/PowerPC/MIPS handle it with device trees.