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

[Heinrich Schuchardt]

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

what is your view on changing CONFIG_ENV_OFFSET=0x60000 to
CONFIG_ENV_OFFSET=0xC0000?

Best regards

Heinrich