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/