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

[Anatolij Gustschin]

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.

--
Anatolij