Hi Stefano, On Fri, 6 Dec 2019 12:41:47 +0100 Stefano Babic sba...@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
