[U-Boot] [U-Boot, v2] Enable expression support for CONFIG_BOARD_SIZE_LIMIT

[Tom Rini <trini@konsulko.com>]

On Wed, Mar 06, 2019 at 09:54:20PM +0100, Simon Goldschmidt wrote:
> Tom,
> 
> On Fri, Dec 14, 2018 at 8:16 PM Tom Rini <trini@konsulko.com> wrote:
> >
> > On Fri, Dec 07, 2018 at 08:27:51PM +0100, Wolfgang Denk wrote:
> >
> > > So far, the use of CONFIG_BOARD_SIZE_LIMIT would only work with
> > > plain numeric constants.  Extend it to allow for expressions, so one
> > > can for example use
> > >
> > >       #define CONFIG_BOARD_SIZE_LIMIT (768 << 10)
> > >
> > > in the board configuration.
> > >
> > > Signed-off-by: Wolfgang Denk <wd@denx.de>
> > > Tested-by: Fabio Estevam <festevam@gmail.com>
> > >
> > > Cc: Fabio Estevam <festevam@gmail.com>
> > > Cc: Stefano Babic <sbabic@denx.de>
> > > Cc: Vanessa Maegima <vanessa.maegima@nxp.com>
> > > Cc: Otavio Salvador <otavio@ossystems.com.br>
> > > Cc: John Weber <john.weber@technexion.com>
> > > Cc: Stefan Roese <sr@denx.de>
> > > ---
> > > v2: replace bashism for evaluating expressions in CONFIG_BOARD_SIZE_LIMIT
> > >     by another call to awk.
> > >
> > > Note 1: As gawk lacks an eval function and we don't want to rely on
> > >  bash being used as shell, we use another call to awk to evaluate the
> > >  expression. This has the disadvantage that we cannot use expressions
> > >  like "<<" which awk does not understand. OK, one could replace awk
> > >  by something better...
> > >
> > > Note 2: This patch focusses on enabling this new feature.  It does
> > >  not addres another issue that should be solved in a later
> > >  commit: the duplication of the same code in Makefile and
> > >  arch/arm/mach-imx/Makefile
> > >
> > > ---
> > >  Makefile                   | 17 ++++++++---------
> > >  arch/arm/mach-imx/Makefile | 17 ++++++++---------
> > >  2 files changed, 16 insertions(+), 18 deletions(-)
> > >
> > > diff --git a/Makefile b/Makefile
> > > index 0d11ff9797..87eb0fd2b1 100644
> > > --- a/Makefile
> > > +++ b/Makefile
> > > @@ -774,15 +774,14 @@ LDPPFLAGS += \
> > >
> > >  ifneq ($(CONFIG_BOARD_SIZE_LIMIT),)
> > >  BOARD_SIZE_CHECK = \
> > > -     @actual=`wc -c $@ | awk '{print $$1}'`; \
> > > -     limit=`printf "%d" $(CONFIG_BOARD_SIZE_LIMIT)`; \
> > > -     if test $$actual -gt $$limit; then \
> > > -             echo "$@ exceeds file size limit:" >&2 ; \
> > > -             echo "  limit:  $$limit bytes" >&2 ; \
> > > -             echo "  actual: $$actual bytes" >&2 ; \
> > > -             echo "  excess: $$((actual - limit)) bytes" >&2; \
> > > -             exit 1; \
> > > -     fi
> > > +     @(awk "END{print $$(echo $(CONFIG_BOARD_SIZE_LIMIT))}" /dev/null; wc -c $@ ) | \
> >
> > So this fails with awk being provided by mawk, not gawk:
> > $ mawk "END{print $(echo 0xE0000)}" /dev/null;
> > 0
> > $ gawk "END{print $(echo 0xE0000)}" /dev/null;
> > 917504
> >
> > And then things fail as mawk doesn't like hex.
> >
> > Now, at the end of the day, I'm now not sure I agree with this patch in
> > concept.  When CONFIG_BOARD_SIZE_LIMIT is moved to Kconfig it will be
> > taking I would assume a hex input and so we don't have to worry about <<
> > at all.
> 
> Sorry to warm up an old thread, but I have some slightly new input on this.
> 
> I can understand you disliking the concept of this patch regarding U-Boot
> proper size check (if CONFIG_BOARD_SIZE_LIMIT moves to Kconfig).
> 
> However, I think for SPL this is different: SPL often starts with one single
> small SRAM shared for code + data. In this case, the size available for the
> SPL binary often can be calculated like this:
> 
> CONFIG_SPL_MAX_SIZE = SRAM_SIZE - SYS_MALLOC_F_LEN -
> GENERATED_GBL_DATA_SIZE - STACKSIZE;
> 
> Being like that, it cannot just be moved to Kconfig and by definition is not
> a hardcoded single hex number but changes depending on other options.
> 
> I see two ways out here:
> a) continue the way of this patch until it works for all shells/awks or
> b) implement SPL binary size check using 4 constants instead of 1 (see above)
> 
> I'm willing to code this through, as I am hitting this limit on socfpga, so I
> could need a decision ;-)

OK, so a few thoughts here.
- What's the portable way to do hex-based math?  If we really need it?
- Really, CONFIG_{SPL,TPL}_MAX_SIZE is not user configurable, it's the
  SoC/design imposed limit.  CONFIG_BOARD_MAX_SIZE is somewhat
  configurable as that tends to also include "don't grow past X or we
  overwrite Y and break things".

Part of the problem area is that we need to take N values, which are
#defined, and use that to see if our final result is too large.  Prior
to needing device tree stuff, OK, we can get the linker on our side to
enforce this (well enough that we can fudge the rest, ie artificially
lower SRAM size a little and comment on why).  With DTBs and such, we
need to take a look at the final result too, of each stage.

So yes, I think we need to figure out some portable way to deal with
checking all constants.  And we'll Kconfig what we can/should Kconfig,
and #define what we need to define and (ugh) calculate and use what must
be done that way.  Thanks!

-- 
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/20190308/97e12096/attachment.sig>