[U-Boot] spl: add size check including devicetree

[Tom Rini]

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 at 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?

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20190322/5a11542c/attachment.sig>