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

Wed May 8 18:04:26 UTC 2019

Hi Simon,
comments inlined...

On Tue, May 07, 2019 at 10:00:03PM +0200, Simon Goldschmidt wrote:
> 
> 
> On 07.05.19 19:25, Andreas Dannenberg wrote:
> > TI K3 SoCs like the AM654x devices are fundamentally dependent on a
> > firmware called SYSFW (System Firmware) being loaded into the dedicated
> > DMSC (Device Management and Security Controller) processor to provide
> > various services via TISCI (Texas Instruments System Control Interface)
> > to manage device aspects such as core bringup, power, clocks, security,
> > and so on across the entire SoC.
> > 
> > Currently public U-Boot does not boot on an actual AM654x EVM due to
> > the missing loading and startup of SYSFW, with this being the only piece
> > missing preventing a successful boot from SD/MMC-type media. This gap
> > is addressed with this patch series.
> > 
> > Note that the loading and starting of SYSFW is done in the context of
> > board_init_f() in SPL which poses some unique challenges due to the very
> > constrained nature of this environment (minimal amount of SRAM, no DDR
> > yet available).
> > 
> > In order to be as lean as possible on resource use an approach was chosen
> > that extends the existing SPL loader framework to be usable beyond the
> > usual "loading U-Boot" use case. While this patch series only makes
> > changes to the MMC/SD card loader framework to support eMMC/MMC/SD FS-
> > and sector/partition-based RAW boot at this time we have this solution
> > in production today but extended to SPI/OSPI and Y-Modem without any
> > issues.
> > 
> > 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), being heavier on resource usage (needing to use ENV to pass
> > parameters), and not addressing the need to probe the boot peripheral.
> > 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...

Agreed this can be refactored and extended and would be useful - except for
some very memory-constrained situations, see below.

> 
> And the current state of that fs_loader is like it is because it fits its
> single user (socfpga stratix 10), I think.

What I needed was something very small as even with the here proposed
solution that heavily re-uses SPL loader code there is only about 61KB
left at the moment in the SRAM memory region SPL executes from, and some
of that 61KB will be used by the stack, and some will be used by other
features still needing to get added to the SPL image unrelated to the
loader functionality under discussion. So space is super tight, and
literally every KB counts. I wish the environment was less constrained
from a memory POV...

> 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?

Be careful not to be mislead from what I'm actually proposing here:

1) A method to load, start (via rproc) and configure the TI K3 System
   Firmware with the patch "arm: K3: Introduce System Firmware loader
   framework" under arch/mach. You can review this patch, 95% of this
   code is only applicable to TI K3 devices, and not any other device,
   platform, or vendor. The actual "loading" part you are concerned with
   is nothing more than a single call over to spl_mmc_load() located
   in the SPL framework. So the logical place for the "SYSFW Loader" is
   said arm/mach location.

2) A method to re-use most/all of the SPL loader code including
   peripheral init/probe functionality most commonly used for only
   loading U-Boot by exposing the core loader functions as an API.
   For MMC/SD, this is introduced with the patch "spl: Make image loader
   infrastructure more universal" and doesn't really add any code
   at all. This has the advantage of minimizing memory footprint and code
   duplication (FS loader replicates some of what the SPL loader does,
   and even more so if extended). I argue this method of opening up
   the SPL loader is actually orthogonal to the current FS loader
   framework, and the FS loader framework could as well tap into the
   SPL loader code as well as it extends and grows to avoid duplication.

--
Andreas Dannenberg
Texas Instruments Inc

> 
> 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
> > 