On Thu, Jan 10, 2019 at 11:47 PM Stefano Babic <sba...@denx.de> wrote: > > Hi Tom, > > On 10/01/19 16:12, Tom Rini wrote: > > On Thu, Jan 10, 2019 at 03:51:51PM +0100, Stefano Babic wrote: > >> 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. > > > > Right, I understand, that's just the first MPC83xx board I spotted, and > > I wanted to see if all platforms had such unreasonable growth. You're > > showing your custom platform went up by _200_ kilobytes. > > I have found that one of the major reason is the different toolchain. > 2018.11 was built with the toolchain requested by customer, it was gcc > 6.4. I built 2017.01 with buildman and fetching the toolchain, that > means 7.3. The same U-Boot versione produces very different footprint, > much better with the newer toolchain. At least 50-60KB are due to the > toolchain. LibFDT + FIT image (new features I added) produces ~70Kb more > code. But then, yes, I want to have them. So at the end, one big > responsible is the toolchain. So partially I am responsible for new > footprint (new features), the rest is done by toolchain.
That looked promising, so I gave it a try as well: I'm normally using gcc 6.3 from Debian 9. Comparing the sizes of this and buildman-provided 7.3, I got a reduction of 100-200 Bytes only (both for SPL and U-Boot) with 7.3. So your 50 KiB reduction must have been a corner case I guess... Regards, Simon > > > > > >>> 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. > > > > Thanks! > > > > Regards, > Stefano _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
