public inbox for u-boot@lists.denx.de
 help / color / mirror / Atom feed
From: Tom Rini <trini@konsulko.com>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH v2] spl: add overall SPL size check
Date: Mon, 22 Apr 2019 17:10:10 -0400	[thread overview]
Message-ID: <20190422211010.GU4664@bill-the-cat> (raw)
In-Reply-To: <20190422202721.15892-1-simon.k.r.goldschmidt@gmail.com>

On Mon, Apr 22, 2019 at 10:27:21PM +0200, Simon Goldschmidt wrote:
> This adds a size check for SPL that can dynamically check generated
> SPL binaries (including devicetree) for a size limit that ensures
> this image plus global data, heap and stack fit in initial SRAM.
> 
> Since some of these sizes are not available to make, a new host tool
> 'spl_size_limit' is added that dumps the resulting maximum size for
> an SPL binary to stdout. This tool is used in toplevel Makefile to
> implement the size check on SPL binaries.
> 
> Signed-off-by: Simon Goldschmidt <simon.k.r.goldschmidt@gmail.com>
> ---
> 
> Changes in v2:
> - added missing tools/spl_size_limit.c
> 
>  Kconfig                |  8 --------
>  Makefile               |  2 +-
>  common/spl/Kconfig     | 36 ++++++++++++++++++++++++++++++++++++
>  tools/Makefile         |  2 ++
>  tools/spl_size_limit.c | 30 ++++++++++++++++++++++++++++++

Ah, now I get it, and why you said you depend on Heinrich's series now,
OK.  This isn't quite what I envisioned, but, maybe that's OK.  I was
thinking we could drop the whole of the shell function, stat() the file
and return 0/error.  But I guess on the whole we've got the shell
function portable and not too fragile looking, so maybe it's not worth
the extra work there.

I do have one problem I'd like to discuss, which is that to replicate
this for a TPL size limit (which we totally have and need to deal with),
we cp and sed spl_size_limit.c to tpl_size_limit.c.

I don't however see a clever way to avoid that.  CONFIG_IS_ENABLED()
would let us have the same #if test, but doing
size_limit -= CONFIG_SPL_FOO CONFIG_TPL_FOO;
is probably getting too clever.

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/20190422/6591b7b2/attachment.sig>

  reply	other threads:[~2019-04-22 21:10 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-04-22 20:27 [U-Boot] [PATCH v2] spl: add overall SPL size check Simon Goldschmidt
2019-04-22 21:10 ` Tom Rini [this message]
2019-04-23  5:47   ` Simon Goldschmidt
2019-05-11  1:55 ` Tom Rini
2019-05-13 12:45   ` Simon Goldschmidt
2019-05-23 20:08     ` Simon Goldschmidt
2019-05-23 20:16       ` Tom Rini
2019-05-27 16:25         ` Masahiro Yamada
2019-05-28 18:05           ` Simon Goldschmidt

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20190422211010.GU4664@bill-the-cat \
    --to=trini@konsulko.com \
    --cc=u-boot@lists.denx.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox