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

Wed May 8 18:57:55 UTC 2019

Am 08.05.2019 um 20:04 schrieb Andreas Dannenberg:
> 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...

I can understand your point on memory usage, but fs_loader started by 
Intel is used in SPL, too. And while they obviously aren't as tight with 
memory there (although I think this is pre DDR, too), I still think we 
should come up with *one* solution, not two.

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

OK.

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

You're talking about 3/13 here? I think that's a good approach in 
general. Maybe the actual work left is making fs_loader use these 
loaders in SPL to deduplicate code?

Regards,
Simon

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