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

[Simon Goldschmidt]

Am 10.01.2019 um 16:56 schrieb Tom Rini:
> On Thu, Jan 10, 2019 at 09:11:53AM +0100, Simon Goldschmidt wrote:
>> On Thu, Jan 10, 2019 at 9:00 AM Stefano Babic <sbabic at denx.de> 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
>>>
>>>   But the new footprint overwrote the space for the env, and I had to
>>> change the layout.It was not something that I could not manage and in
>>> this specific case, customer could handle it. I cannot say I did
>>> something pretty wrong to bloat the bootloader, so my feeling was that
>>> there is not a specific part responsible for the increased size, but
>>> each component is slightly bigger and they sizes sum at the end.
>>>
>>>
>>>>   Why default?  Well, "everyone"
>>>> agrees that defaulting to EFI application support means the widest
>>>> choice of out of the box software support.
>>>
>>> I am unsure about this - just my two cents.
>>>
>>> I agree with you if we are talking about evaluation boards and / or
>>> boards supposed to run different distros (or in any case, more flavour
>>> of software).
>>>
>>> But there are a lot of "custom" boards (maintained in U-Boot) that runs
>>> for a specific project and won't run any other kind of software. If a
>>> device is a navigation system, a network controller, or whatever, it
>>> will just do this job until its EOL.
>>>
>>> Specially for older boards, a new feature should not be activated as
>>> default. At the beginning, police in U-Boot was to set just what should
>>> be required in the bootloader, without setting what is not needed as
>>> default. So default was off instead of on.
>>
>> I aslo think that would suit U-Boot better. For example, I have one
>> configuration where I need to squeeze U-Boot into 204 KiB. For me this
>> currently means I have to re-check the defconfig for every update to
>> disable new features that are now on by default. I think having those
>> default to off and enabling them via defconfig if required would be better.
> 
> Can SoCFPGA not set the option to make a link failure if you grow beyond
> 204KiB?  As part of this thread, the only new default y thing since
> v2018.01 at least is CRC16-CCITT support in "hash".

Well, this is a non-mainline config. Plus I keep having problems with 
the size check in that it does not account for the DTB. Wait, that was 
for SPL, how do you enable a size check for U-Boot?

Anyway, if new default y things aren't the problem, it's probably an 
increasement here and there, like Stefano said... :-(

Thanks,
Simon