[U-Boot] [PATCH 2/2] board: tbs2910: Remove FIT support in defconfig to reduce u-boot size

[Stefano Babic]

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.


> 
>>> 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