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@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.