Tom Rini trini@konsulko.com schrieb am Fr., 22. März 2019, 21:50:
On Fri, Mar 22, 2019 at 09:47:06PM +0100, Simon Goldschmidt wrote:
Am 22.03.2019 um 14:03 schrieb Tom Rini:
On Fri, Mar 01, 2019 at 10:34:17PM +0100, Simon Goldschmidt wrote:
Current linker based size checks do not account for the devicetree, as this is added after linker stage.
This patch moves the logic behind U-Boot proper BOARD_SIZE_CHECK into a common function that is called for SPL, too.
For SPL, CONFIG_SPL_MAX_SIZE is used to check u-boot-spl-dtb.bin.
This is RFC for two reasons:
- scripts/Kbuild.include might not be the perfect place for this new function but was the only place I found included by both /Makefile and /scripts/Makefile.spl
- CONFIG_SPL_MAX_SIZE at least for some boards defines the size of the initially available SRAM. However, this check checks the SPL binary only. Initial SRAM must hold gd, heap and stack in addition to that.
Signed-off-by: Simon Goldschmidt simon.k.r.goldschmidt@gmail.com
So, a problem is that we need to get at values after they've been pre-processed: /bin/sh: 1: printf: (SRAM_SCRATCH_SPACE_ADDR - CONFIG_SPL_TEXT_BASE):
expected numeric value
spl/u-boot-spl-dtb.bin exceeds file size limit: limit: 0 bytes actual: 124970 bytes excess: 124970 bytes ../scripts/Makefile.spl:266: recipe for target 'spl/u-boot-spl-dtb.bin'
failed
Right. We could run the define through libt/asm-offsets.c (just like GENERATED_GBL_DATA_SIZE is created), but how would we get the result back into the Makefile?
I'm honestly not sure. I can only think of what I first want to call hacks such as having a C program do the check instead. But maybe that's not such a hack afterall?
Right. Given the problems we're having with a pure Makefile based approach, a C program doing this might indeed be a less fragile solution.
Regards, Simon