On 6/13/19 10:55 PM, Simon Goldschmidt wrote: > > > Marek Vasut <ma...@denx.de <mailto:ma...@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.goldschm...@gmail.com > <mailto:simon.k.r.goldschm...@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 _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot