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.goldschm...@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
signature.asc
Description: PGP signature
_______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
