[U-Boot] [PATCH 00/13] System Firmware Loader for TI K3 family SoCs

[Chee, Tien Fong <tien.fong.chee@intel.com>]

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
> > 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-misc-fs_loader-Add-QSPI-RAW-partition-loading-suppor.patch
Type: text/x-patch
Size: 6758 bytes
Desc: 0001-misc-fs_loader-Add-QSPI-RAW-partition-loading-suppor.patch
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20190508/9d780f88/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0004-ARM-dts-socfpga-Add-dts-support-for-QSPI-Arria-10-So.patch
Type: text/x-patch
Size: 19097 bytes
Desc: 0004-ARM-dts-socfpga-Add-dts-support-for-QSPI-Arria-10-So.patch
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20190508/9d780f88/attachment-0001.bin>