3 ms·

Probably would be more accurate to say that TianoCore now supports the board. UEFI could be ported to more systems, but there's little incentive. Also, the main

Probably would be more accurate to say that TianoCore now supports the board. UEFI could be ported to more systems, but there's little incentive. Also, the main power of UEFI is the ability for an OS to get an early framebuffer and nice interface to USB/PCI/etc. without knowing the low-level details of the system you're booting, and that's a lot of work, especially in the embedded ecosystem where SoC vendors just rearrange memory layout and blocks between chip revisions (hey, we'll just update the Linux driver with the latest mappings, that's fine, right?)

snvzz 3y ago
>especially in the embedded ecosystem where SoC vendors just rearrange memory layout and blocks between chip revisions (hey, we'll just update the Linux driver with the latest mappings, that's fine, right?) This would not be compliant with RISC-V specifications. There's no boards in the market that I am aware of which run Linux and yet do not follow the boot specifications, which among other things require the use of device trees. >there's little incentive ... to deviate from the specifications, and opt out of all the benefits of being a compliant implementation. There's severe costs incurred by not leveraging the ecosystem.
- remexre 3y ago
  > require the use of device trees I think that's the case where it's easy for a vendor to do so; see, for example: - https://elixir.bootlin.com/linux/latest/source/arch/arm64/boot/dts/rockchip/rk3399-rockpro64.dts https://elixir.bootlin.com/linux/latest/source/arch/arm64/bo... - https://elixir.bootlin.com/linux/latest/source/arch/arm64/boot/dts/rockchip/rk3399-rockpro64-v2.dts https://elixir.bootlin.com/linux/latest/source/arch/arm64/bo... - https://elixir.bootlin.com/linux/latest/source/arch/arm64/boot/dts/rockchip/rk3399-rockpro64.dtsi https://elixir.bootlin.com/linux/latest/source/arch/arm64/bo...
- phendrenad2 3y ago
  > This would not be compliant with RISC-V specifications What? > the boot specifications Where? > There's severe costs incurred by not leveraging the ecosystem How?

snvzz 3y ago

>especially in the embedded ecosystem where SoC vendors just rearrange memory layout and blocks between chip revisions (hey, we'll just update the Linux driver with the latest mappings, that's fine, right?) This would not be compliant with RISC-V specifications. There's no boards in the market that I am aware of which run Linux and yet do not follow the boot specifications, which among other things require the use of device trees. >there's little incentive ... to deviate from the specifications, and opt out of all the benefits of being a compliant implementation. There's severe costs incurred by not leveraging the ecosystem.

remexre 3y ago
> require the use of device trees I think that's the case where it's easy for a vendor to do so; see, for example: - https://elixir.bootlin.com/linux/latest/source/arch/arm64/boot/dts/rockchip/rk3399-rockpro64.dts https://elixir.bootlin.com/linux/latest/source/arch/arm64/bo... - https://elixir.bootlin.com/linux/latest/source/arch/arm64/boot/dts/rockchip/rk3399-rockpro64-v2.dts https://elixir.bootlin.com/linux/latest/source/arch/arm64/bo... - https://elixir.bootlin.com/linux/latest/source/arch/arm64/boot/dts/rockchip/rk3399-rockpro64.dtsi https://elixir.bootlin.com/linux/latest/source/arch/arm64/bo...
phendrenad2 3y ago
> This would not be compliant with RISC-V specifications What? > the boot specifications Where? > There's severe costs incurred by not leveraging the ecosystem How?