4 ms·

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 mark

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.

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.