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)
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.
--
Tom
signature.asc
Description: PGP signature
_______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
