On Tue, 2019-05-07 at 22:00 +0200, Simon Goldschmidt wrote:
On 07.05.19 19:25, Andreas Dannenberg wrote:
[...]
While I also have a working solution based on the existing FS loader framework this has its own challenges, namely by its very nature only addressing a subset of our use cases (no eMMC/SD RAW boot support for example),
IMO, it's actually not that hard to enhance RAW support, i think minimal changes are required. I have attached the patches about an example of loading RAW from QSPI that i have done locally last few week ago.
being heavier on resource usage (needing to use ENV to pass parameters),
ENV is optional, you can use DTS. For example loading FPGA bitstream from QSPI RAW:
/* DTS */ / { + aliases { + spi0 = &qspi; + }; + + fs_loader0: fs-loader { + u-boot,dm-pre-reloc; + compatible = "u-boot,fs-loader"; + sfconfig = <0 0 100000000 3>; + }; +}; + +&fpga_mgr { + u-boot,dm-pre-reloc; + firmware-loader = <&fs_loader0>; + altr,bitstream = "300000"; +};
and not addressing the need to probe the boot peripheral.
You can add more different probing method in function called "fs_loader_probe". Current fs_loader supports block(sdmmc, emmc, etc...) probing, and with the patches attached support QSPI probing.
Another idea come to mind, we can use fs_loader for loading FIT boot image into RAM, and boot from RAM with existing SPL loader framework, but i'm not sure this implementation fit to your use case?
This particular framework works well for use cases requiring to load firmware from FS-based media once DDR is up and U-Boot is in a more "initialized" state but it is not a one-fits all solution for very early use in SPL board_init_f() accross different boot modes.
And would it be an option to improve the loader (maybe dropping the "fs" from its name)? I think it's an "fs" loader because its idea has been copied from Linux. I think in U-Boot, it's more common to have things at a raw offset instead of a file system. Just thinking...
Current fs_loader only support filesystem, and i agree that it made sense to remove the "fs" once it supports the RAW offset as well.
Thanks.
Regards, TF
And the current state of that fs_loader is like it is because it fits its single user (socfpga stratix 10), I think.
Anyway, even if you do need yet another loader, would it make sense to create a common file instead of adding this in your arch/mach?
Regards, Simon
Andreas Dannenberg (10): mmc: k3_arasan: Allow driver to probe without PDs specified spl: Allow skipping clearing BSS during relocation spl: Make image loader infrastructure more universal arm: K3: Introduce System Firmware loader framework armV7R: K3: am654: Allow using SPL BSS pre-relocation armv7R: K3: am654: Use full malloc implementation in SPL armV7R: K3: am654: Load SYSFW binary and config from boot media configs: am65x_evm_r5: All sysfw to be loaded via MMC configs: am65x_hs_evm_r5: All sysfw to be loaded via MMC configs: am65x_hs_evm: Add Support for eMMC boot
Faiz Abbas (2): configs: am65x_evm: Add Support for eMMC boot am65x: README: Add eMMC layout and flash instructions
Lokesh Vutla (1): armv7R: dts: k3: am654: Update mmc nodes for loading sysfw
arch/arm/dts/k3-am654-r5-base-board.dts | 18 ++ arch/arm/lib/crt0.S | 3 + arch/arm/mach-k3/Kconfig | 40 +++ arch/arm/mach-k3/Makefile | 1 + arch/arm/mach-k3/am6_init.c | 34 ++- arch/arm/mach-k3/include/mach/sysfw-loader.h | 12 + arch/arm/mach-k3/sysfw-loader.c | 263 +++++++++++++++++++ board/ti/am65x/Kconfig | 1 + board/ti/am65x/README | 52 ++++ common/spl/Kconfig | 13 + common/spl/spl_fit.c | 14 + common/spl/spl_mmc.c | 76 ++++-- configs/am65x_evm_a53_defconfig | 2 + configs/am65x_evm_r5_defconfig | 7 +- configs/am65x_hs_evm_a53_defconfig | 2 + configs/am65x_hs_evm_r5_defconfig | 7 +- drivers/mmc/k3_arsan_sdhci.c | 16 +- include/configs/am65x_evm.h | 30 ++- include/spl.h | 26 ++ 19 files changed, 577 insertions(+), 40 deletions(-) create mode 100644 arch/arm/mach-k3/include/mach/sysfw-loader.h create mode 100644 arch/arm/mach-k3/sysfw-loader.c