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.
