[U-Boot] [PATCH] arm: socfpga: provide default SPL_SIZE_LIMIT for gen5

[Marek Vasut]

On 6/14/19 8:57 AM, Simon Goldschmidt wrote:
> 
> 
> Marek Vasut <marex at denx.de <mailto:marex at denx.de>> schrieb am Do., 13.
> Juni 2019, 23:08:
> 
>     On 6/13/19 11:00 PM, Simon Goldschmidt wrote:
>     >
>     >
>     > Marek Vasut <marex at denx.de <mailto:marex at denx.de>
>     <mailto:marex at denx.de <mailto:marex at denx.de>>> schrieb am Do., 13.
>     > Juni 2019, 22:56:
>     >
>     >     On 6/13/19 10:55 PM, Simon Goldschmidt wrote:
>     >     >
>     >     >
>     >     > Marek Vasut <marex at denx.de <mailto:marex at denx.de>
>     <mailto:marex at denx.de <mailto:marex at denx.de>>
>     >     <mailto:marex at denx.de <mailto:marex at denx.de>
>     <mailto: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>
>     >     <mailto:simon.k.r.goldschmidt at gmail.com
>     <mailto:simon.k.r.goldschmidt at gmail.com>>
>     >     >     <mailto:simon.k.r.goldschmidt at gmail.com
>     <mailto:simon.k.r.goldschmidt at gmail.com>
>     >     <mailto: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 ?
>     >
>     >
>     > One of the reasons why I haven't sent the clk driver patches yet.
>     >
>     > Anyway, I'll be off for at least a week now, I just wanted to get this
>     > one in before the release.
> 
>     So is 0x200 bytes for stack before SPL relocs the stack enough ?
> 
> 
> For now it's enough, yes.

OK, applied.

-- 
Best regards,
Marek Vasut