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