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
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
