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

[Soeren Moch]

On 06.12.19 15:02, Tom Rini wrote:
> 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'm not at all against a pragmatic solution. Tom just added a patch to
further reduce binary size of this board.
>>> 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.
Agreed.
>>>  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.
My main concern is user experience.
So I very much like the idea of Marek and Tom, at least to think about
what can be done from the developers, before we break boards for users.

Moving the environment would brick the board for every updater, probably
nobody uses the default environment with modern linux kernels. There are
users that only access the environment from running linux. A special
serial adapter (sold separately) is necessary for this board, so
restoring a lost environment is not easy for everybody. (For me
personally there is no problem at all, besides the incoming bug reports
from other users about bricked boards.)

Before moving the environment I would consider disabling uncommon boot
options, like NFS boot, while leaving TFTP boot enabled in defconfig.
That at least would not break the boards for every user, only for
hopefully more experienced ones.
>>>  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.
There is something left, but if nobody cares about binary size, then
this will not last long.
But this discussion shows that we care about binary size again, great!
>> 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).
Thanks! Exactly such clean-up work is needed.

Besides that, binary size is not the main reason for the still pending
DM_VIDEO conversion. On my first attempt I ended up without video signal
at all. I haven't found time yet to investigate that further. Maybe
something wrong with the hdmidetect logic to enable HDMI only if a
monitor is connected, to not slow down the serial console, where we
sometimes loose characters when typing fast and video is enabled.
>> 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.
... for developers, while breaking support for users. And that's  the
target audience we maintain u-boot for, right?
<https://dict.leo.org/englisch-deutsch/target>
> 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.
I support that idea.

Thanks,
Soeren
> 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.
>