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

[Soeren Moch]

On 06.12.19 17:18, Soeren Moch wrote:
> 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>
Sorry, no idea where this link comes from...
>> 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.
>>
>