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