3 ms·

It's really depressing that no Risc-V hardware currently in production has completely open-source firmware. In this respect Risc-V is much, much more closed th

It's really depressing that no Risc-V hardware currently in production has completely open-source firmware. In this respect Risc-V is much, much more closed than Arm64, where we have the totally-blobless RK3399. Ultimately Risc-V is about vendor-freedom at all costs, even at the cost of owner-freedom.

krasin 3y ago
I agree with your sentiment, but I am more optimistic about the future of RISC-V. It considerably lowered the barrier of entry for vendors, and so there are more of them! Higher competition usually means that users win: they get lower prices, open-source toolchains and firmware, etc. For one, I am very excited about the tiny CH32V003 ([1], [2]), a RISC-V 48 MHz microcontroller that costs ~$0.10 and can be programmed with completely open-source tools, see [3] and [4]. I am reasonably sure the higher end of the spectrum of RISC-V chips will also get better in terms of user-friendliness. 1. https://www.youtube.com/watch?v=L9Wrv7nW-S8 https://www.youtube.com/watch?v=L9Wrv7nW-S8 2. http://www.wch-ic.com/products/CH32V003.html http://www.wch-ic.com/products/CH32V003.html 3. https://github.com/cnlohr/ch32v003fun https://github.com/cnlohr/ch32v003fun 4. https://github.com/aappleby/PicoRVD https://github.com/aappleby/PicoRVD
snvzz 3y ago
Regarding the VisionFive 2 this is about, there's some non-open firmware, but it is the GPU's and it is not required to boot. It is not even required for litting up the screen, as the HDMI controller is a separate hardware block, not is it required for video decoding acceleration, another separate hardware block.
CameronNemo 3y ago
Only reason rk3399 ended up blobless was because ChromiumOS team holds that standard. Any ARM SoC used in a Chromebook has to have open firmware. Tap that market, and doors will open! Un/fortunately nobody don't want a riscv laptop. The (currently available) cores just aren't good.
- the_panopticon 3y ago
  I believe the Qualcomm and Mediatek-based ARM Chromebooks have binary blobs.
  - CameronNemo 3y ago
    For WiFi or in the boot sequence? https://github.com/ARM-software/arm-trusted-firmware/tree/master/plat/mediatek https://github.com/ARM-software/arm-trusted-firmware/tree/ma... I guess Qualcomm has some pull.? Although they do have some code in Coreboot. https://doc.coreboot.org/soc/qualcomm/sc7180/index.html https://doc.coreboot.org/soc/qualcomm/sc7180/index.html https://elixir.bootlin.com/coreboot/latest/source/src/soc/qualcomm/sc7180 https://elixir.bootlin.com/coreboot/latest/source/src/soc/qu...
    - the_panopticon 3y ago
      I was looking just at the boot code. Rockchip has all open source silicon and board code, including the RK3399 https://github.com/coreboot/coreboot/blob/master/src/soc/rockchip/rk3399/sdram.c https://github.com/coreboot/coreboot/blob/master/src/soc/roc... for memory init. This is the logic typically held back by many other ARM vendors, like Mediatek and Qualcomm, as blobs. There's a pretty interesting diagram showing the blobs in Intel, AMD, Qualcomm, and Mediatek coreboot implementations in figure 5-4 of https://link.springer.com/chapter/10.1007/978-1-4842-7939-7_5 https://link.springer.com/chapter/10.1007/978-1-4842-7939-7_.... A more cartoonish variant of the figure (but one that's not behind a paywall) can be found in slide 2 of https://osfw.foundation/slides/SiliconInterfaceDesign/OSFF-Workstream-SiliconInterfaceDesign-Intro.pdf https://osfw.foundation/slides/SiliconInterfaceDesign/OSFF-W.... You're right. Coreboot has open source board code and some open source silicon code for all of the vendors w/ binary boot blobs. So it's not so completely closed. The blobs are usually SOC-specific, board-independent code flows that 'should' just drop in and work.
      - snvzz 3y ago
        Note that ram init in VisionFive 2 is done within u-boot SPL, which is loaded into cache-as-ram from the selected (microswitches on the board) boot device. The non-rewritable ROM inside the SoC does just take care of reading the microswitches and fetching u-boot SPL (or oreboot, an alternative early bootloader in the works). Remarkably, the boot selection can be UART. This small ROM has an XMODEM implementation for receiving the early bootloader. u-boot SPL does then check the microswitches again for where to fetch the next stage, which is usually opensbi with u-boot as bundled payload.

krasin 3y ago

I agree with your sentiment, but I am more optimistic about the future of RISC-V. It considerably lowered the barrier of entry for vendors, and so there are more of them! Higher competition usually means that users win: they get lower prices, open-source toolchains and firmware, etc. For one, I am very excited about the tiny CH32V003 ([1], [2]), a RISC-V 48 MHz microcontroller that costs ~$0.10 and can be programmed with completely open-source tools, see [3] and [4]. I am reasonably sure the higher end of the spectrum of RISC-V chips will also get better in terms of user-friendliness. 1. https://www.youtube.com/watch?v=L9Wrv7nW-S8 https://www.youtube.com/watch?v=L9Wrv7nW-S8 2. http://www.wch-ic.com/products/CH32V003.html http://www.wch-ic.com/products/CH32V003.html 3. https://github.com/cnlohr/ch32v003fun https://github.com/cnlohr/ch32v003fun 4. https://github.com/aappleby/PicoRVD https://github.com/aappleby/PicoRVD

snvzz 3y ago

Regarding the VisionFive 2 this is about, there's some non-open firmware, but it is the GPU's and it is not required to boot. It is not even required for litting up the screen, as the HDMI controller is a separate hardware block, not is it required for video decoding acceleration, another separate hardware block.

CameronNemo 3y ago

Only reason rk3399 ended up blobless was because ChromiumOS team holds that standard. Any ARM SoC used in a Chromebook has to have open firmware. Tap that market, and doors will open! Un/fortunately nobody don't want a riscv laptop. The (currently available) cores just aren't good.

the_panopticon 3y ago
I believe the Qualcomm and Mediatek-based ARM Chromebooks have binary blobs.
- CameronNemo 3y ago
  For WiFi or in the boot sequence? https://github.com/ARM-software/arm-trusted-firmware/tree/master/plat/mediatek https://github.com/ARM-software/arm-trusted-firmware/tree/ma... I guess Qualcomm has some pull.? Although they do have some code in Coreboot. https://doc.coreboot.org/soc/qualcomm/sc7180/index.html https://doc.coreboot.org/soc/qualcomm/sc7180/index.html https://elixir.bootlin.com/coreboot/latest/source/src/soc/qualcomm/sc7180 https://elixir.bootlin.com/coreboot/latest/source/src/soc/qu...
  - the_panopticon 3y ago
    I was looking just at the boot code. Rockchip has all open source silicon and board code, including the RK3399 https://github.com/coreboot/coreboot/blob/master/src/soc/rockchip/rk3399/sdram.c https://github.com/coreboot/coreboot/blob/master/src/soc/roc... for memory init. This is the logic typically held back by many other ARM vendors, like Mediatek and Qualcomm, as blobs. There's a pretty interesting diagram showing the blobs in Intel, AMD, Qualcomm, and Mediatek coreboot implementations in figure 5-4 of https://link.springer.com/chapter/10.1007/978-1-4842-7939-7_5 https://link.springer.com/chapter/10.1007/978-1-4842-7939-7_.... A more cartoonish variant of the figure (but one that's not behind a paywall) can be found in slide 2 of https://osfw.foundation/slides/SiliconInterfaceDesign/OSFF-Workstream-SiliconInterfaceDesign-Intro.pdf https://osfw.foundation/slides/SiliconInterfaceDesign/OSFF-W.... You're right. Coreboot has open source board code and some open source silicon code for all of the vendors w/ binary boot blobs. So it's not so completely closed. The blobs are usually SOC-specific, board-independent code flows that 'should' just drop in and work.
    - snvzz 3y ago
      Note that ram init in VisionFive 2 is done within u-boot SPL, which is loaded into cache-as-ram from the selected (microswitches on the board) boot device. The non-rewritable ROM inside the SoC does just take care of reading the microswitches and fetching u-boot SPL (or oreboot, an alternative early bootloader in the works). Remarkably, the boot selection can be UART. This small ROM has an XMODEM implementation for receiving the early bootloader. u-boot SPL does then check the microswitches again for where to fetch the next stage, which is usually opensbi with u-boot as bundled payload.