3 ms·
>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
by snvzz 4y 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 4y 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?