All of lore.kernel.org
 help / color / mirror / Atom feed
From: Joakim Tjernlund <Joakim.Tjernlund@infinera.com>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH 2/2] board: tbs2910: Remove FIT support in defconfig to reduce u-boot size
Date: Thu, 10 Jan 2019 08:09:14 +0000	[thread overview]
Message-ID: <66a762ef4b8432f736123107517f51f9a6bd34d2.camel@infinera.com> (raw)
In-Reply-To: <20190109223917.GA5463@bill-the-cat>

On Wed, 2019-01-09 at 17:39 -0500, Tom Rini wrote:
> CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.
> 
> 
> On Wed, Jan 09, 2019 at 05:01:37PM +0100, Stefano Babic wrote:
> > Hi Soeren,
> > 
> > On 08/01/19 12:03, Soeren Moch wrote:
> > > Hi Stefano,
> > > 
> > > On 08.01.19 11:24, Stefano Babic wrote:
> > > > Hi Soeren,
> > > > 
> > > > On 08/01/19 11:14, Soeren Moch wrote:
> > > > > Stefano,
> > > > > 
> > > > > can you apply this for v2019.01? This is really a important fix to avoid
> > > > >  environment and u-boot binary overwriting each other.
> > > > > It is also a small local fix which cannot hurt anybody else.
> > > > I will apply and I send a new PR. This is not the first fix in this
> > > > direction, u-boot becomes pretty large, it is becoming a common problem.
> > > > 
> > > Thank you very much.
> > > 
> > > Yes, "in the good old days (tm)" there was much effort put into not
> > > increasing the binary size for existing boards when adding new features.
> > 
> > Right, fully agree.
> > 
> > > Unfortunately this is not true anymore.
> > 
> > I get in the same trouble with more as one project. A previous rule of
> > thumb was to reserve 512KB to the bootloader because it was pretty
> > unthinkable that bootloader could be larger. Mhmmhh....this remember me
> > someone else who said that 640Kb is enough for everything.
> > 
> > Anyway, as you noted, this is a big problem in field and it makes
> > difficult an upgrade without returning back the device to factory, what
> > nobody wants.
> 
> So, this is more on me, so I should probably explain a little, and point
> at the biggest culprit too.  The biggest at times culprit and sometimes
> controversial thing is that we default to the EFI subsystem being on by
> default.  This is 50KiB on tbs2910.  Why default?  Well, "everyone"
> agrees that defaulting to EFI application support means the widest
> choice of out of the box software support.
> 
> And I do look at size changes, at least per push to master.  So most of
> the time it comes in "drips and drabs".  Right now I'm going to grow
> tbs2910 by 60 bytes[1].  Most of that is section re-alignment and 8 of it
> is the regression fix to mmc_startup() or non-DM MMC drivers.  But
> that's not super interesting, so lets look at v2018.09 to now.  That's
> 1800 bytes.  That's not too bad and looks like it's maybe half bug
> fixes, half working on various frameworks (sure, DM/DT stuff but also
> hash algos.  If we jump back to v2018.01, so more or less a year worth
> of changes, that's 19KiB.  Without trying to break down _everything_
> that's a good bit of EFI and a little bit everywhere else.

If you looking to save a few more bytes you could take a look at my old patch
for handling the env. without a lot of static variables:
  https://patchwork.ozlabs.org/patch/746419/

      parent reply	other threads:[~2019-01-10  8:09 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-01-05  8:31 [U-Boot] [PATCH 1/2] board: tbs2910: Add u-boot.imx size limit check Soeren Moch
2019-01-05  8:31 ` [U-Boot] [PATCH 2/2] board: tbs2910: Remove FIT support in defconfig to reduce u-boot size Soeren Moch
2019-01-08 10:14   ` Soeren Moch
2019-01-08 10:24     ` Stefano Babic
2019-01-08 11:03       ` Soeren Moch
2019-01-09 16:01         ` Stefano Babic
2019-01-09 22:39           ` Tom Rini
2019-01-10  1:28             ` Soeren Moch
2019-01-10  2:30               ` Tom Rini
2019-01-10 14:03                 ` Soeren Moch
2019-01-10 15:06                   ` Tom Rini
2019-01-11 13:11                     ` Soeren Moch
2019-01-11 14:32                       ` Tom Rini
2019-01-10  8:00             ` Stefano Babic
2019-01-10  8:11               ` Simon Goldschmidt
2019-01-10 15:56                 ` Tom Rini
2019-01-10 16:36                   ` Simon Goldschmidt
2019-01-10 16:54                     ` Tom Rini
2019-01-11  6:43                       ` Simon Goldschmidt
2019-01-11  7:22                       ` Simon Goldschmidt
2019-01-11 14:44                         ` Tom Rini
2019-01-10 14:44               ` Tom Rini
2019-01-10 14:51                 ` Stefano Babic
2019-01-10 15:12                   ` Tom Rini
2019-01-10 22:46                     ` Stefano Babic
2019-01-11  6:27                       ` Simon Goldschmidt
2019-01-10 15:53               ` Tom Rini
2019-01-11 13:11                 ` Sören Moch
2019-01-10  8:09             ` Joakim Tjernlund [this message]

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=66a762ef4b8432f736123107517f51f9a6bd34d2.camel@infinera.com \
    --to=joakim.tjernlund@infinera.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.