3 ms·

>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 p

by 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.
  - snvzz 3y ago
    Device trees indeed. Note that newer SBCs have efforts implementing UEFI spec[0], and RISC-V is working on OS-A Platform spec[1], which further reduces basic peripheral and memory map differences. 0. https://github.com/riscv-non-isa/riscv-uefi/releases https://github.com/riscv-non-isa/riscv-uefi/releases 1. https://github.com/riscv/riscv-platform-specs/blob/main/riscv-platform-spec.adoc https://github.com/riscv/riscv-platform-specs/blob/main/risc...
- snvzz 3y ago
  For the higher end "Application" cores that do e.g. run Linux, there's a platform standardization effort. Refer to OS-A platform[0]. 0. https://github.com/riscv/riscv-platform-specs/blob/main/riscv-platform-spec.adoc https://github.com/riscv/riscv-platform-specs/blob/main/risc...

by snvzz 3y ago

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.
- snvzz 3y ago
  Device trees indeed. Note that newer SBCs have efforts implementing UEFI spec[0], and RISC-V is working on OS-A Platform spec[1], which further reduces basic peripheral and memory map differences. 0. https://github.com/riscv-non-isa/riscv-uefi/releases https://github.com/riscv-non-isa/riscv-uefi/releases 1. https://github.com/riscv/riscv-platform-specs/blob/main/riscv-platform-spec.adoc https://github.com/riscv/riscv-platform-specs/blob/main/risc...
snvzz 3y ago
For the higher end "Application" cores that do e.g. run Linux, there's a platform standardization effort. Refer to OS-A platform[0]. 0. https://github.com/riscv/riscv-platform-specs/blob/main/riscv-platform-spec.adoc https://github.com/riscv/riscv-platform-specs/blob/main/risc...