3 ms·

Developers should just stop putting up with this nonsense and start migrating to non proprietary RISC-V boards. We already have low cost options for developers

Developers should just stop putting up with this nonsense and start migrating to non proprietary RISC-V boards. We already have low cost options for developers who want to get their feet wet, the moment we start having a decent community around a RISC-V microcontroller, a RISC-V router and a RISC-V dev board then the ecosystem will be very desireable.

rjsw 4y ago
Most of the blog post described trying to use hardware features that are missing from RISC-V dev boards.
repiret 4y ago
Help me understand how RISC-V solves these problems? It doesn’t offer a standard way to enumerate hardware in the SoC, so you still need device trees; it’d not a GPU, so you still need to deal with proprietary GPU drivers; it doesn’t standardize clocking or DRAM controllers, so you still need uboot or some other first stage boot loader; AFAIK, it doesn’t standardize power management, so you still need secure firmware or equivalent. The need to PXE boot comes from only having one boot device supported by the board, which isn’t solved by RISC-V PCs (partially) solve these problems because the BIOS plays the role of secure firmware and first stage boot loader. Hardware enumeration is solved by having most things be PCI-attached and the bios providing ACPI to enumerate the rest.
- HidyBush 4y ago
  I was talking about non proprietary boards on the whole, not just the CPU. Also if everything is documented it's not a big deal to customize your bootloader to do all the needed stuff. Of course standards would be very welcome, but at least you wouldn't need some arcane knowledge to get things running
  - repiret 4y ago
    I don't think access to SoC documentation would have solved very many of the problems described in the article. The author still would have had to fiddle with device trees, secure firmware, u-boot, pxeboot, and getting a kernel with the right drivers built in. RISC-V also doesn't solve SoC documentation access. Most of Arm's CPU documentation is freely available, its all the other stuff SoC vendors bolt on that's hard to get access to. I don't see RISC-V changing that.
    - snvzz 4y ago
      Refer to profiles, specifically OS-A Profile. Firmware interface is a solved problem (opensbi), so is enumeration (dtb).
  - klelatti 4y ago
    Could you explain what you mean by ‘non proprietary’ boards. All open source software, open hardware. Would closed source RISC-V designs count?
the_duke 4y ago
All the interesting and complicated functionality isn't in the core CPU but in the peripherals and specialized computation. USB, WiFi, Bluetooth, GPU, memory/gpu interface, hardware media decoders, .... Most of which is proprietary IP and heavily patent encumbered. An open RISC chip won't help with that.

rjsw 4y ago

Most of the blog post described trying to use hardware features that are missing from RISC-V dev boards.

repiret 4y ago

Help me understand how RISC-V solves these problems? It doesn’t offer a standard way to enumerate hardware in the SoC, so you still need device trees; it’d not a GPU, so you still need to deal with proprietary GPU drivers; it doesn’t standardize clocking or DRAM controllers, so you still need uboot or some other first stage boot loader; AFAIK, it doesn’t standardize power management, so you still need secure firmware or equivalent. The need to PXE boot comes from only having one boot device supported by the board, which isn’t solved by RISC-V PCs (partially) solve these problems because the BIOS plays the role of secure firmware and first stage boot loader. Hardware enumeration is solved by having most things be PCI-attached and the bios providing ACPI to enumerate the rest.

HidyBush 4y ago
I was talking about non proprietary boards on the whole, not just the CPU. Also if everything is documented it's not a big deal to customize your bootloader to do all the needed stuff. Of course standards would be very welcome, but at least you wouldn't need some arcane knowledge to get things running
- repiret 4y ago
  I don't think access to SoC documentation would have solved very many of the problems described in the article. The author still would have had to fiddle with device trees, secure firmware, u-boot, pxeboot, and getting a kernel with the right drivers built in. RISC-V also doesn't solve SoC documentation access. Most of Arm's CPU documentation is freely available, its all the other stuff SoC vendors bolt on that's hard to get access to. I don't see RISC-V changing that.
  - snvzz 4y ago
    Refer to profiles, specifically OS-A Profile. Firmware interface is a solved problem (opensbi), so is enumeration (dtb).
- klelatti 4y ago
  Could you explain what you mean by ‘non proprietary’ boards. All open source software, open hardware. Would closed source RISC-V designs count?

the_duke 4y ago

All the interesting and complicated functionality isn't in the core CPU but in the peripherals and specialized computation. USB, WiFi, Bluetooth, GPU, memory/gpu interface, hardware media decoders, .... Most of which is proprietary IP and heavily patent encumbered. An open RISC chip won't help with that.