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 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.
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
signature.asc
Description: PGP signature
