
14 Jun
2019
14 Jun
'19
8:57 a.m.
Marek Vasut marex@denx.de schrieb am Do., 13. Juni 2019, 23:08:
On 6/13/19 11:00 PM, Simon Goldschmidt wrote:
Marek Vasut <marex@denx.de mailto:marex@denx.de> schrieb am Do., 13. Juni 2019, 22:56:
On 6/13/19 10:55 PM, Simon Goldschmidt wrote: > > > Marek Vasut <marex@denx.de <mailto:marex@denx.de> <mailto:marex@denx.de <mailto:marex@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@gmail.com <mailto:simon.k.r.goldschmidt@gmail.com> > <mailto:simon.k.r.goldschmidt@gmail.com <mailto:simon.k.r.goldschmidt@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.
Regards, Simon
I hope I'll be working on SPL size after that... 64 KiB not being enough is just ridicculous...
Agreed
-- Best regards, Marek Vasut