Hi Tom,
Tom Rini trini@konsulko.com 於 2023年9月18日 週一 下午11:04寫道：
On Mon, Sep 18, 2023 at 08:11:36PM +0800, Randolph wrote:
Add SPL_LOAD_FIT_CONFIG for binman itb layout selection
Signed-off-by: Randolph randolph@andestech.com
arch/riscv/dts/ae350-u-boot.dtsi | 1 + arch/riscv/dts/ae350_32.dts | 1 - arch/riscv/dts/ae350_64.dts | 1 - board/AndesTech/ae350/Kconfig | 6 ++++++ configs/ae350_rv32_defconfig | 1 + configs/ae350_rv32_spl_defconfig | 1 + configs/ae350_rv32_spl_xip_defconfig | 1 + configs/ae350_rv32_xip_defconfig | 1 + configs/ae350_rv64_defconfig | 1 + configs/ae350_rv64_spl_defconfig | 1 + configs/ae350_rv64_spl_xip_defconfig | 1 + configs/ae350_rv64_xip_defconfig | 1 + 12 files changed, 15 insertions(+), 2 deletions(-)
So this is where I have a problem. It's not clear why you need to change anything here, as there's no example given for doing something other than what you do today, and there's no documentation about it either. From other contexts, it seems like you're trying to re-implement CONFIG_SPL_OS_BOOT but not explaining why you can't use the existing framework.
-- Tom
We want to add our binman.dtsi (very similar to SPL_OS_BOOT) in the future, but this may affect other vendors' code under arch/riscv. To take a step back and reduce the gap, we just want to rearrange our code now (in this patch).
We are not re-implementing SPL_OS_BOOT, the goal (skip loading u-boot proper) is the same, the method is different. For example, in ARM architecture, the Falcon mode (by enabling SPL_OS_BOOT), the boot flow is u-boot SPL jump to Linux kernel. In RISC-V architecture, most SOCs require OpenSBI, the boot flow should be u-boot SPL -> OpenSBI -> Linux kernel. Apart from the boot flow, the code flow is also different, "jump_to_image_linux" is not necessary and the names are not quite right in the RISC-V architecture. The CONFIG_SPL_ARGS_ADDR macro is also not required when building RISC-V u-boot. That's why we need to create another way for OpenSBI to do the actions like CONFIG_SPL_OS_BOOT.
Randolph Sincerely