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

[Stefano Babic]

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.

> 
> 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
=====================================================================