Hi Tom,
On 10/01/19 15:44, Tom Rini wrote:
On Thu, Jan 10, 2019 at 09:00:13AM +0100, Stefano Babic 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 I'm splitting my reply here into two emails. This here concerns the
heck out of me. But I don't see it on MPC8308RDB. There I see: powerpc: (for 1/1 boards) all -124241.0 bss -131040.0 data -48.0 text +6847.0 MPC8308RDB : all -124241 bss -131040 data -48 text +6847 u-boot: add: 108/-85, grow: 121/-49 bytes: 22672/-148318 (-125646)
Maybe I confuse you - this is a custom board, similar to MPC8308RDB, but it is not MPC8308RDB. But nevertheless, I could not understand the difference is sitze.
And in terms of .bins: -rwxrwxr-x 1 trini trini 337400 Jan 10 09:37 /tmp/MPC8308RDB/new/01_of_11922_g80d261881f93ee474d1c9188b5c2b5b42b0c4e6f_powerpc--T2080QDS--R/MPC8308RDB/u-boot.bin -rwxrwxr-x 1 trini trini 345804 Jan 10 09:37 /tmp/MPC8308RDB/new/11922_of_11922_g0157013f4a4945bbdb70bb4d98d680e0845fd784_Prepare-v2018.11/MPC8308RDB/u-boot.bin
I am doing all of mpc83xx now to see if something else trips such a large growth.
I will do the same here on this board and try to understand where the difference is coming from. I will report to you, then.
Regards, Stefano