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

[Simon Goldschmidt]

Tom Rini <trini at 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 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?
>

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

>