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

[Stefano Babic]

Hi Everybody,

On 22/11/19 11:29, Soeren Moch wrote:
> 
> 
> 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.
> 

I come later to the discussion - anyway, I would like to search for a
"pragmatic" solution. I think we can discuss a lot about which code flew
in and why tbs2910 increases the size, but I do not know if this brings
some results. Several changes (see improvements about fdt handling, and
so on) are new features, and it is quite bad to surround any new change
with a lot of #ifdef just to fit. We cannot discuss if it is correct or
not that boards should switch to DM: this was decided a long time ago
and decision won't be changed.

We are not talking about big changes in the size: tbs2910 has a low
threshold for currrent U-Boot : 392192 and from a build to next build,
the size can exceed for "some" bytes. We are not facing a big change,
but the board is living on the edge with current U-Boot. I am then quite
of Heinrich's opinion, and that the environment should be moved
somewhere else to guarantee that board can be supported without fighting
any time with the size in future. Soeren has already dropped most of the
unused features, and I have no idea if there is something else he can do
in this way without dropping used features on the board.

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