From mboxrd@z Thu Jan 1 00:00:00 1970 From: Stefano Babic Date: Thu, 10 Jan 2019 15:51:51 +0100 Subject: [U-Boot] [PATCH 2/2] board: tbs2910: Remove FIT support in defconfig to reduce u-boot size In-Reply-To: <20190110144428.GS5463@bill-the-cat> References: <20190105083118.13491-1-smoch@web.de> <20190105083118.13491-2-smoch@web.de> <63e7db53-dcaa-35cf-0d0e-f7bf5483c5c8@web.de> <20190109223917.GA5463@bill-the-cat> <3077c9c2-5955-abbe-4adc-75ac7361457b@denx.de> <20190110144428.GS5463@bill-the-cat> Message-ID: List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de 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 -- ===================================================================== DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sbabic at denx.de =====================================================================