[U-Boot] [PATCH] arm: socfpga: provide default SPL_SIZE_LIMIT for gen5
Marek Vasut
marex at denx.de
Thu Jun 13 20:56:55 UTC 2019
On 6/13/19 10:55 PM, Simon Goldschmidt wrote:
>
>
> Marek Vasut <marex at denx.de <mailto:marex at denx.de>> schrieb am Do., 13.
> Juni 2019, 22:40:
>
> On 6/13/19 10:26 PM, Simon Goldschmidt wrote:
> >
> >
> > On 13.06.19 22:14, Marek Vasut wrote:
> >> On 6/13/19 9:50 PM, Simon Goldschmidt wrote:
> >>> This provides an SPL_SIZE_LIMIT that makes the build check that
> the SPL
> >>> binary loaded from flash fits into the SRAM (64 KiB) and leaves
> enough
> >>> room for global data, heap and stack (512 bytes assumed stack
> usage).
> >>>
> >>> Signed-off-by: Simon Goldschmidt
> <simon.k.r.goldschmidt at gmail.com
> <mailto:simon.k.r.goldschmidt at gmail.com>>
> >>> ---
> >>>
> >>> arch/arm/mach-socfpga/Kconfig | 8 ++++++++
> >>> 1 file changed, 8 insertions(+)
> >>>
> >>> diff --git a/arch/arm/mach-socfpga/Kconfig
> >>> b/arch/arm/mach-socfpga/Kconfig
> >>> index 48f02f08d4..1d914648e3 100644
> >>> --- a/arch/arm/mach-socfpga/Kconfig
> >>> +++ b/arch/arm/mach-socfpga/Kconfig
> >>> @@ -3,6 +3,12 @@ if ARCH_SOCFPGA
> >>> config NR_DRAM_BANKS
> >>> default 1
> >>> +config SPL_SIZE_LIMIT
> >>> + default 65536 if TARGET_SOCFPGA_GEN5
> >>> +
> >>> +config SPL_SIZE_LIMIT_PROVIDE_STACK
> >>> + default 0x200 if TARGET_SOCFPGA_GEN5
> >>> +
> >>> config SPL_STACK_R_ADDR
> >>> default 0x00800000 if TARGET_SOCFPGA_GEN5
> >>> @@ -49,6 +55,8 @@ config TARGET_SOCFPGA_GEN5
> >>> bool
> >>> select SPL_ALTERA_SDRAM
> >>> imply FPGA_SOCFPGA
> >>> + imply SPL_SIZE_LIMIT_SUBTRACT_GD
> >>> + imply SPL_SIZE_LIMIT_SUBTRACT_MALLOC
> >>> imply SPL_STACK_R
> >>> imply SPL_SYS_MALLOC_SIMPLE
> >>> imply USE_TINY_PRINTF
> >>>
> >> 512 bytes for stack looks like it's too little. I think the SPL
> started
> >> misbehaving when it overgrew 50 kiB, no ?
> >
> > To 1: Well, I tested the stack usage once, booting from eMMC, and was
> > somewhere below that range. But yes, it's a problem for the
> future: once
> > we get a more stack-consuming function, we might be lost. Which size
> > would you suggest?
>
> Hmmm, now that I think about it, the stack gets relocated to DRAM quite
> early too, right ? So maybe we really don't need that much space for
> stack.
>
>
> Exactly. The only stack-consuming things before relocation are dts
> parsing and maybe the ddr driver. I implemented a stack usage check by
> filling the memory with 0xaa and checking it afterwards and if I
> remember correctly it resulted in about 400 bytes. It's even more or
> less independent of the boot type since the ski/mmc drivers are probed
> only after DDR is up. Same goes for file systems.
>
> Nevertheless, stack usage can increase in the future. That's why I'm not
> too happy about this constant. Otoh, DM_CLK makes me need every byte and
> right now I don't see how I can enable secure boot (fit signature check)
> due to this size limit...
Maybe before we add more bloat, we should consider how to trim the bloat
down first ?
--
Best regards,
Marek Vasut
More information about the U-Boot
mailing list