public inbox for u-boot@lists.denx.de
 help / color / mirror / Atom feed
From: Simon Goldschmidt <simon.k.r.goldschmidt@gmail.com>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH v3] spl: add overall SPL size check
Date: Mon, 27 May 2019 21:28:44 +0200	[thread overview]
Message-ID: <e98b22c9-20f6-57fa-f879-32bfc588fcf5@gmail.com> (raw)
In-Reply-To: <20190527164811.GC20781@bill-the-cat>

Am 27.05.2019 um 18:48 schrieb Tom Rini:
> On Tue, May 28, 2019 at 01:35:52AM +0900, Masahiro Yamada wrote:
>> On Sat, May 25, 2019 at 5:07 AM Simon Goldschmidt
>> <simon.k.r.goldschmidt@gmail.com> 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>
>>> ---
>>
>> Some architectures have SPL size checks.
>> CONFIG_SPL_MAX_FOOTPRINT
>> CONFIG_SPL_MAX_SIZE
>> CONFIG_SPL_BSS_MAX_SIZE
>>
>> Will they be replaced by this new mechanism?
> 
> Yes, as the existing checks are only sufficient for final link time
> overflows and not final image overflows.

This patch builds on Heinrich Schuchardt's series that add 
CONFIG_SPL_SIZE_LIMIT to check maximum image size (after potentially 
adding image headers):

https://patchwork.ozlabs.org/patch/1074741/

I just now realize I have forgotton to add that dependency to the patch 
mail.

However, we do have numerous max size defines. This patch tries to bring 
a better calculation for the maximum SPL image size by taking SRAM size 
and subtracting what's required in addition to the binary size.

In general, the different max size defines could need a cleanup as well, 
I guess...

Regards,
Simon

  reply	other threads:[~2019-05-27 19:28 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-05-24 20:07 [U-Boot] [PATCH v3] spl: add overall SPL size check Simon Goldschmidt
2019-05-24 20:10 ` Simon Goldschmidt
2019-05-26 11:09   ` Tom Rini
2019-05-27 13:47   ` Jean-Jacques Hiblot
2019-05-27 14:54     ` Tom Rini
2019-05-27 15:15       ` Simon Goldschmidt
2019-05-28 15:18         ` Jean-Jacques Hiblot
2019-05-28 15:51           ` Simon Goldschmidt
2019-05-27 16:35 ` Masahiro Yamada
2019-05-27 16:48   ` Tom Rini
2019-05-27 19:28     ` Simon Goldschmidt [this message]
2019-06-07 22:05 ` Tom Rini

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=e98b22c9-20f6-57fa-f879-32bfc588fcf5@gmail.com \
    --to=simon.k.r.goldschmidt@gmail.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