[U-Boot] Maximum size of u-boot.imx for TBS2910 board

[Soeren Moch]

On 22.11.19 04:58, Marek Vasut wrote:
> On 11/22/19 4:41 AM, Tom Rini wrote:
> [...]
>>>>>>>>>> I believe
>>>>>>>>>> the specific changes in question that once again push this board over
>>>>>>>>>> fall in to that grey area.  Whatever size-trimming the board maintainer
>>>>>>>>>> is fine with next is fine with me, but needs to get ack'd by someone.
>>>>>>>>> Or, the other option is, make these new extra features configurable and
>>>>>>>>> disable them on this board. And so there should be no size problem.
>>>>>>>> But that direction leads to saying every slight bit of functionality
>>>>>>>> requires a new Kconfig entry.  Some levels of bugfixes as well.
>>>>>>> The other option is, we will sink in bloat and suffer endless size problems.
>>>>>> Yes, it is a hard balancing act.  Stepping back, perhaps a "minimal" or
>>>>>> "complete" choice for USB HID devices would make sense and allow us
>>>>>> further areas to reduce size, on the minimal portion.
>>>>> Or maybe there is a way to help compiler optimize that USB key code
>>>>> handling better.
>>>> Perhaps.  But my point is that every little functional change or
>>>> enhancement does not need a Kconfig option.
>>> Except this leads to slow and steady accumulation of bloat, and as we
>>> already see for quite a while, this is problematic for more and more boards.
>> And "bloat" and "features" are interchangable terms.
> Nope, bloat is unhelpful growth of size, features are actually
> helpful/useful.
>
>> I really am trying
>> to be more responsive than ever to size growth in common, rather than
>> board specific areas.  And I agree, some investigation in to ways that
>> might reduce the size of binary support for USB HID devices is good.
> So we agree that's what this series should fix ?
>
>> Figuring out if we can make this series:
>> http://patchwork.ozlabs.org/project/uboot/list/?series=135448
>> not also increase the overall size, or increase it less, is good.
>> Hiding the content of 2/5 behind a CONFIG option in turn brings us back
>> to "the code is too messy and full of #ifdef" lines.
> Which might be somewhat better than if the code is sprinkled with tiny
> chunks of random pieces of code which are never used, but in total add
> up to a lot of unused code in the binary.

What a long discussion over night, so only a general answer:

Once upon a time there was plenty of space for tbs2910 u-boot.
Then we had to convert everything to DM, for whatever reason. This
increased the binary size a lot, had absolutely no advantage for u-boot
users, was huge effort for board maintainers, and is still going on.
(DM_VIDEO conversion still pending for this board, probably more to
come, DM_SERIAL?). For all that additional space is required, apparently
nobody tries to cleanup the non-DM code for converted subsystems to
reclaim some of the space.

Several times I tried to disable unneeded functions to trim the binary
size. After a few weeks the gained space was eaten up, apparently nobody
cares about binary size anymore as long as there is no build failure.
Even worse, since imx format is padded, people claim to not increase the
binary size with there patches (what in fact is not true), and then some
simple change / tool update again breaks everything.

What is the solution to that? I don't see much what _I_ can do. If I
find some option to disable again, what is increasingly difficult, then
this removes the last opportunity for upcoming DM conversions.
For the "bloat" vs. "features" discussion: on long existing boards no
user expects new features in defconfig, especially if they only come
with reduced functionality somewhere else. And as hobbyist board
maintainer I don't know which features existing users actually use. I
only get bug reports about bricked boards when something is missing.

Soeren