[U-Boot] tbs2910 not buildable

[Soeren Moch]

On 23.04.19 01:19, Tom Rini wrote:
> On Sun, Apr 14, 2019 at 12:46:25PM +0200, Soeren Moch wrote:
>> Hi Stefano,
>>
>> On 14.04.19 11:52, stefano babic wrote:
>>> Hallo Soeren,
>>>
>>> after pulling from Tom and merging u-boot-imx, - next, your board is not
>>> buildable anymore. Better: it is buildable, but size exceeds:
>>>
>>>        arm:  +   tbs2910
>>> +u-boot.imx exceeds file size limit:
>>> +  limit:  392192 bytes
>>> +  actual: 396288 bytes
>>> +  excess: 4096 bytes
>>>
>>> Just dropping CONFIG_EFI_PARTITION (I supposed EFI is not used on this
>>> board), solves the issue. I can do myself in this way or let me know
>>> what is your preferred way.
>>>
>> Hm, the full name of this board is "TBS2910 Matrix ARM mini PC", so it
>> is supposed to provide a full PC environment. It supports booting from
>> SATA, and such disk may as well be partitioned with EFI. It is really
>> terrible to drop user visible features, just to support a new "driver
>> model" that is supposed to ease life for developers, but in fact is much
>> work and a real pain for maintainers of existing boards, and brings
>> exactly nothing for the board's users.
>>
>> So much for that. Now to your question.
>>
>> Would be OK for me to drop CONFIG_EFI_PARTITION for now since it is more
>> important to get this series merged, because other boards also depend on
>> the SATA patches. We can readd EFI_PARTITION support later. For sure
>> there will be more patches in this development cycle.
>> But if you can wait a few hours, I will look for a better solution, or
>> send a formal patch for this CONFIG_EFI_PARTITION removal.
> Now that I'm back from vacation, I do want to chime in here.  So, yes,
> this presents a difficult challenge.  I don't want to encourage people
> to take out functionality just to make the binary fit.  And I assume the
> binary size limit is so that we don't overwrite something else, so we
> can't just grow it either.  So what options do we have?  Taking out
> CONFIG_DM_WARN and CONFIG_MMC_VERBOSE gives us about 2KB.  Changing the
> loglevel from 4 to 3 saves another 2KB.  Dropping the memtest command
> (which is not helpful and discouraged) gives another 1KB.
>
> But these are also, well, stopgaps.  Is it all going to be worth it?
> Well, I hope so.  We can for example gain another 1KB back by disabling
> block cache, which does improve read speed from filesystems and thus
> something end users see.  But it could have been written without DM,
> it's just a new feature and "carrot" to move to DM.
>
> I don't even see any obvious-to-me cases of including big hunks of data
> that should be dropped, so that brings us to maybe-not-used
> functionality like bootelf/bootvx/nfs and so on.  Which I don't like.
>
> So, I'm trying to keep a harder still eye on size growth when pulling in
> functionality.  And I kinda wish LTO was easier to bring in as that
> might really save us some space.
>
Thanks, Tom, for your additional suggestions.
Disabling CMD_FDT in tbs2910_defconfig did the trick for this round, see
[1].

Regards,
Soeren

[1]
http://git.denx.de/?p=u-boot.git;a=commit;h=e0627f77f55ea8d606cd4b0902bc47ffaad220d0