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

[Andreas Dannenberg]

Hi Tom,

On Wed, May 15, 2019 at 11:16:43AM -0400, Tom Rini wrote:
> On Tue, May 07, 2019 at 12:25:29PM -0500, 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.
> [snip]
> > 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.
> 
> I think one thing that might help here is to post this alternative
> solution and provide the 'size' information for both series.  In
> addition, build something like am335x_evm and socfpga_stratix10 for both
> series and include their before/after 'size' info too.  Thanks!

I collected some data how this series extending the SPL framework affects
the size of the SPL, the increase is quite small nevertheless there is an
increase that may or may not be an issue on certain platforms:

                  |    SPL File    | v2019.07-rc2 | plus SYSFW loader series
------------------+----------------+--------------+-------------------------
am335x_evm        | MLO            | 109,884      | 109,964 (+120 bytes)
socfpga_stratix10 | u-boot-spl.bin |  78,760      |  78,872 (+112 bytes)


Then, I also collected some data comparing how the SYSFW loader based on
extending the SPL loader function (this patch series) stacks up against
a basic FS loader-based implementation of the SYSFW loader functionality
from an AM654 R5 SPL size POV:

 What                     | SPL (tiboot3.bin) | Solution Size (bytes)
--------------------------+-------------------+-----------------------
No SYSFW Loader           |      91,725       |     0 (base for comp)
SPL loader-based solution |      93,265       | 1,540
FS loader-based solution  |      95,417       | 3,692


Basically the FS loader-based solution is ~2x bigger than the SPL-loader
based solution, while also dropping eMMC/SD partition- and sector-based
RAW support. The difference between the solutions is 2,152 and will be
even larger once RAW boot support is added in. Will post the FS loader-
based solution for reference next.


One more word on why I am so concerned with memory. Below is a rough
memory map of our SPL running on an R5 core out of on-chip MCU SRAM
(512KB on AM654x). The stack during "pre-relocation" SPL is growing
down towards where the actual SPL image is. Inside board_init_f()
the SP currently sits at SP=0x41c25b10. The image size of an R5 SPL
with the SPL loader-based solution as proposed with this patch series
sits at 93,265 bytes, effectively leaving 61,119 bytes to be shared
between features that are yet to get added to tiboot3.bin (such as
board-detection EEPROM support, other early boot remote core loading,
additions to dtb), and what can be used as stack by board_init_f()
and its callees. Hence, every kilobyte really counts.

+-----------+  0x41c8 0000
|    BSS    |  CONFIG_SPL_BSS_MAX_SIZE=0x5000
+-----------+
|   malloc  |  CONFIG_SYS_MALLOC_F_LEN=0x55000
+-----------+
|    gd     |
+-----------+
|   Stack   |
+-----------+
|           |  \
~           ~   |== Room for stack growth
|           |  /   and R5 SPL feature
+-----------+      additions
|           |
|tiboot3.bin|
|   (SPL)   |
|           |
+-----------+  0x41c0 0000


--
Andreas Dannenberg
Texas Instruments Inc