[U-Boot] [PATCH 2/2] board: tbs2910: Remove FIT support in defconfig to reduce u-boot size

Thu Jan 10 08:11:53 UTC 2019

On Thu, Jan 10, 2019 at 9:00 AM Stefano Babic <sbabic at denx.de> wrote:
>
> Hi Tom, Soeren,
>
> On 09/01/19 23:39, Tom Rini wrote:
> > 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.
>
> I am not sure if we should point to EFI as responsible for the increased
> footprint or it is due to the sum of several components / factors. I
> just report my experience in last month : I had to port U-Boot for a
> customer from a not very old release (2017.01) to the current. 2017.01
> had already (apart of FIT support) all features the customer needed, but
> there are issues(NAND, UBI) and I kew that they were solved later.
> Processor was an old PowerPC 8308, a quite dead SOC. I have not changed
> a lot in board code, but of course I had to reconfigure a lot. At the
> end, everything worked but I was quite astonished about footprint. I had:
>
> 2017.01 u-boot.bin 443452
> 2018.11 u-boot.bin 654684
>
>  But the new footprint overwrote the space for the env, and I had to
> change the layout.It was not something that I could not manage and in
> this specific case, customer could handle it. I cannot say I did
> something pretty wrong to bloat the bootloader, so my feeling was that
> there is not a specific part responsible for the increased size, but
> each component is slightly bigger and they sizes sum at the end.
>
>
> >  Why default?  Well, "everyone"
> > agrees that defaulting to EFI application support means the widest
> > choice of out of the box software support.
>
> I am unsure about this - just my two cents.
>
> I agree with you if we are talking about evaluation boards and / or
> boards supposed to run different distros (or in any case, more flavour
> of software).
>
> But there are a lot of "custom" boards (maintained in U-Boot) that runs
> for a specific project and won't run any other kind of software. If a
> device is a navigation system, a network controller, or whatever, it
> will just do this job until its EOL.
>
> Specially for older boards, a new feature should not be activated as
> default. At the beginning, police in U-Boot was to set just what should
> be required in the bootloader, without setting what is not needed as
> default. So default was off instead of on.

I aslo think that would suit U-Boot better. For example, I have one
configuration where I need to squeeze U-Boot into 204 KiB. For me this
currently means I have to re-check the defconfig for every update to
disable new features that are now on by default. I think having those
default to off and enabling them via defconfig if required would be better.

Regards,
Simon

>
> >
> > 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.
> >
> >>> And all the shiny new driver model / OF features only bring
> >>> disadvantages for maintainers and users of existing boards.
> >>>
> >>> I totally understand the desire to convert the driver code to "something
> >>> better", which is easier to maintain long-term. But apparently new code
> >>> is only tested on a single platform, while constantly breaking support
> >>> for others without notice. But 'm complaining to the wrong person...
> >>
> >> Yes, I am not the right person ;-)
> >>
> >> I picked up your patches, I will run build tests and if everything is
> >> fine I will sent PR for 2019.01.
> >
> > In retrospect, I wish more people knew about enforcing a link time hard
> > limit on the binary and knew about it a lot longer ago.
> >  Because when
> > those failures pop up, I don't apply the new PR and I start talking to
> > the relevant parties to see what we can do.
>
> You're right - the check is mot a "nice to have", it is something that
> should be introduced and used. Also if we see in Soeren's case, because
> the first "saveenv" on his board had damaged the bootloader resulting in
> a bricked board.
>
> >
> > [1]: buildman --step 0 -SBCdevlk followed by --step 0 -SsBdevlk to see
> > how much and where, and yes, that's a few more flags than I _need_ for
> > that, and since it's in a script I never go and optimize it down.
> >
>
> Regards,
> Stefano
>
>
> --
> =====================================================================
> DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
> HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
> Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sbabic at denx.de
> =====================================================================
> _______________________________________________
> U-Boot mailing list
> U-Boot at lists.denx.de
> https://lists.denx.de/listinfo/u-boot