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

[Tom Rini <trini@konsulko.com>]

On Fri, Nov 22, 2019 at 12:42:49PM +0100, Heinrich Schuchardt wrote:
> 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?

I am still against that move as we need to address the real underlying
problem of size growth.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20191122/f263ff3c/attachment.sig>