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

[Tom Rini]

On Fri, Dec 06, 2019 at 01:30:44PM +0100, Anatolij Gustschin wrote:
> Hi Stefano,
> 
> On Fri, 6 Dec 2019 12:41:47 +0100
> Stefano Babic sbabic at denx.de wrote:
> ...
> > 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.
> 
> I'm currently looking for ways to slightly reduce image size to convert
> this board to DM_VIDEO. Yesterday I've submitted two patches for video
> uclass, this is still not enough to be able to build the board with
> DM_VIDEO enabled. I'm currently trying to drop dead or useless code from
> mxc_ipuv3 driver and also tried to remove device tree nodes for stuff not
> used in U-Boot. This might give us a few kilobytes of image size reduction
> and DM_VIDEO could probably work (at least when using gcc-8.1). But I'm
> expecting new bloat when next merge window opens and new patches will
> be merged, this board will fail again. Moving the environment would
> help a lot.

I really want to not change the environment as I see it as a reminder
that no, we need to address some of the underlying problems.  The
constraints imposed by the platform aren't unreasonable.

That said, I would also be happy to see patches to re-work the buildman
toolchain logic to fetch the appropriate set of "builds something that
works" toolchains as while there are 8.1.0 toolchains from kernel.org we
need at least I believe 8.3 for both all ARM and x86 to work.

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