From mboxrd@z Thu Jan 1 00:00:00 1970 From: Simon Goldschmidt Date: Wed, 8 May 2019 20:57:55 +0200 Subject: [U-Boot] [PATCH 00/13] System Firmware Loader for TI K3 family SoCs In-Reply-To: <20190508180426.toc2fxufymixzlma@jiji> References: <20190507172542.31359-1-dannenberg@ti.com> <20190508180426.toc2fxufymixzlma@jiji> Message-ID: <2b784bd4-1a78-750b-4c3f-879e89c9162e@gmail.com> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de 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 >>>