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

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

[Heinrich Schuchardt]

Hello Soeren,

when trying to add support for function key support in the USB keyboard
driver u-boot.imx for the TBS2910 surpassed the maximum size for u-boot.imx.
https://travis-ci.org/marex/u-boot-usb/builds/614059004

Do you remember why on the TBS2910 board this size is limited to
0x5fc00? Other i.MX6 boards like the Wandboard allow a much larger
u-boot.imx.

The limit is defined here:
include/configs/tbs2910.h:80:
#define CONFIG_BOARD_SIZE_LIMIT 392192 /* (CONFIG_ENV_OFFSET - 1024) */

Could the value CONFIG_ENV_OFFSET=0x60000 be enlarged?

Many i.MX6 defconfigs use CONFIG_ENV_OFFSET=0xC0000.

Best regards

Heinrich

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

[Tom Rini]

On Thu, Nov 21, 2019 at 09:09:29PM +0100, Heinrich Schuchardt wrote:
> Hello Soeren,
> 
> when trying to add support for function key support in the USB keyboard
> driver u-boot.imx for the TBS2910 surpassed the maximum size for u-boot.imx.
> https://travis-ci.org/marex/u-boot-usb/builds/614059004
> 
> Do you remember why on the TBS2910 board this size is limited to
> 0x5fc00? Other i.MX6 boards like the Wandboard allow a much larger
> u-boot.imx.
> 
> The limit is defined here:
> include/configs/tbs2910.h:80:
> #define CONFIG_BOARD_SIZE_LIMIT 392192 /* (CONFIG_ENV_OFFSET - 1024) */
> 
> Could the value CONFIG_ENV_OFFSET=0x60000 be enlarged?
> 
> Many i.MX6 defconfigs use CONFIG_ENV_OFFSET=0xC0000.

The nature of these boards (aimed at end users) means that we just do
not want to / cannot really move the stored environment.  Thanks!

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20191121/d93def0a/attachment.sig>

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

[Heinrich Schuchardt]

On 11/21/19 9:12 PM, Tom Rini wrote:
> On Thu, Nov 21, 2019 at 09:09:29PM +0100, Heinrich Schuchardt wrote:
>> Hello Soeren,
>>
>> when trying to add support for function key support in the USB keyboard
>> driver u-boot.imx for the TBS2910 surpassed the maximum size for u-boot.imx.
>> https://travis-ci.org/marex/u-boot-usb/builds/614059004
>>
>> Do you remember why on the TBS2910 board this size is limited to
>> 0x5fc00? Other i.MX6 boards like the Wandboard allow a much larger
>> u-boot.imx.
>>
>> The limit is defined here:
>> include/configs/tbs2910.h:80:
>> #define CONFIG_BOARD_SIZE_LIMIT 392192 /* (CONFIG_ENV_OFFSET - 1024) */
>>
>> Could the value CONFIG_ENV_OFFSET=0x60000 be enlarged?
>>
>> Many i.MX6 defconfigs use CONFIG_ENV_OFFSET=0xC0000.
>
> The nature of these boards (aimed at end users) means that we just do
> not want to / cannot really move the stored environment.  Thanks!
>

Another possibility would be to reduce the image size by using
CONFIG_REGEX=n which should be fine for a board with only one supported
network interface.

Best regards

Heinrich

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

[Marek Vasut]

On 11/21/19 10:59 PM, Heinrich Schuchardt wrote:
> On 11/21/19 9:12 PM, Tom Rini wrote:
>> On Thu, Nov 21, 2019 at 09:09:29PM +0100, Heinrich Schuchardt wrote:
>>> Hello Soeren,
>>>
>>> when trying to add support for function key support in the USB keyboard
>>> driver u-boot.imx for the TBS2910 surpassed the maximum size for
>>> u-boot.imx.
>>> https://travis-ci.org/marex/u-boot-usb/builds/614059004
>>>
>>> Do you remember why on the TBS2910 board this size is limited to
>>> 0x5fc00? Other i.MX6 boards like the Wandboard allow a much larger
>>> u-boot.imx.
>>>
>>> The limit is defined here:
>>> include/configs/tbs2910.h:80:
>>> #define CONFIG_BOARD_SIZE_LIMIT 392192 /* (CONFIG_ENV_OFFSET - 1024) */
>>>
>>> Could the value CONFIG_ENV_OFFSET=0x60000 be enlarged?
>>>
>>> Many i.MX6 defconfigs use CONFIG_ENV_OFFSET=0xC0000.
>>
>> The nature of these boards (aimed at end users) means that we just do
>> not want to / cannot really move the stored environment.  Thanks!
>>
> 
> Another possibility would be to reduce the image size by using
> CONFIG_REGEX=n which should be fine for a board with only one supported
> network interface.

But the board was fine before your patchset got applied and this is just
a workaround for added bloat, which reduces functionality. I dislike
trading functionality for bloat, sorry.

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

[Tom Rini]

On Thu, Nov 21, 2019 at 11:01:43PM +0100, Marek Vasut wrote:
> On 11/21/19 10:59 PM, Heinrich Schuchardt wrote:
> > On 11/21/19 9:12 PM, Tom Rini wrote:
> >> On Thu, Nov 21, 2019 at 09:09:29PM +0100, Heinrich Schuchardt wrote:
> >>> Hello Soeren,
> >>>
> >>> when trying to add support for function key support in the USB keyboard
> >>> driver u-boot.imx for the TBS2910 surpassed the maximum size for
> >>> u-boot.imx.
> >>> https://travis-ci.org/marex/u-boot-usb/builds/614059004
> >>>
> >>> Do you remember why on the TBS2910 board this size is limited to
> >>> 0x5fc00? Other i.MX6 boards like the Wandboard allow a much larger
> >>> u-boot.imx.
> >>>
> >>> The limit is defined here:
> >>> include/configs/tbs2910.h:80:
> >>> #define CONFIG_BOARD_SIZE_LIMIT 392192 /* (CONFIG_ENV_OFFSET - 1024) */
> >>>
> >>> Could the value CONFIG_ENV_OFFSET=0x60000 be enlarged?
> >>>
> >>> Many i.MX6 defconfigs use CONFIG_ENV_OFFSET=0xC0000.
> >>
> >> The nature of these boards (aimed at end users) means that we just do
> >> not want to / cannot really move the stored environment.  Thanks!
> > 
> > Another possibility would be to reduce the image size by using
> > CONFIG_REGEX=n which should be fine for a board with only one supported
> > network interface.
> 
> But the board was fine before your patchset got applied and this is just
> a workaround for added bloat, which reduces functionality. I dislike
> trading functionality for bloat, sorry.

One persons "bloat" is another persons "added functionality".  I believe
the specific changes in question that once again push this board over
fall in to that grey area.  Whatever size-trimming the board maintainer
is fine with next is fine with me, but needs to get ack'd by someone.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20191121/8a8aa3f9/attachment.sig>

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

[Marek Vasut]

On 11/21/19 11:45 PM, Tom Rini wrote:
> On Thu, Nov 21, 2019 at 11:01:43PM +0100, Marek Vasut wrote:
>> On 11/21/19 10:59 PM, Heinrich Schuchardt wrote:
>>> On 11/21/19 9:12 PM, Tom Rini wrote:
>>>> On Thu, Nov 21, 2019 at 09:09:29PM +0100, Heinrich Schuchardt wrote:
>>>>> Hello Soeren,
>>>>>
>>>>> when trying to add support for function key support in the USB keyboard
>>>>> driver u-boot.imx for the TBS2910 surpassed the maximum size for
>>>>> u-boot.imx.
>>>>> https://travis-ci.org/marex/u-boot-usb/builds/614059004
>>>>>
>>>>> Do you remember why on the TBS2910 board this size is limited to
>>>>> 0x5fc00? Other i.MX6 boards like the Wandboard allow a much larger
>>>>> u-boot.imx.
>>>>>
>>>>> The limit is defined here:
>>>>> include/configs/tbs2910.h:80:
>>>>> #define CONFIG_BOARD_SIZE_LIMIT 392192 /* (CONFIG_ENV_OFFSET - 1024) */
>>>>>
>>>>> Could the value CONFIG_ENV_OFFSET=0x60000 be enlarged?
>>>>>
>>>>> Many i.MX6 defconfigs use CONFIG_ENV_OFFSET=0xC0000.
>>>>
>>>> The nature of these boards (aimed at end users) means that we just do
>>>> not want to / cannot really move the stored environment.  Thanks!
>>>
>>> Another possibility would be to reduce the image size by using
>>> CONFIG_REGEX=n which should be fine for a board with only one supported
>>> network interface.
>>
>> But the board was fine before your patchset got applied and this is just
>> a workaround for added bloat, which reduces functionality. I dislike
>> trading functionality for bloat, sorry.
> 
> One persons "bloat" is another persons "added functionality".

It would seem this board did not suffer from the lack of this particular
functionality before, and I would say that a board should stay at least
as functional as it was when it was added. Replacing existing
functionality with random unrelated new one makes no sense.

> I believe
> the specific changes in question that once again push this board over
> fall in to that grey area.  Whatever size-trimming the board maintainer
> is fine with next is fine with me, but needs to get ack'd by someone.

Or, the other option is, make these new extra features configurable and
disable them on this board. And so there should be no size problem.

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

[Tom Rini]

On Fri, Nov 22, 2019 at 01:23:56AM +0100, Marek Vasut wrote:
> On 11/21/19 11:45 PM, Tom Rini wrote:
> > On Thu, Nov 21, 2019 at 11:01:43PM +0100, Marek Vasut wrote:
> >> On 11/21/19 10:59 PM, Heinrich Schuchardt wrote:
> >>> On 11/21/19 9:12 PM, Tom Rini wrote:
> >>>> On Thu, Nov 21, 2019 at 09:09:29PM +0100, Heinrich Schuchardt wrote:
> >>>>> Hello Soeren,
> >>>>>
> >>>>> when trying to add support for function key support in the USB keyboard
> >>>>> driver u-boot.imx for the TBS2910 surpassed the maximum size for
> >>>>> u-boot.imx.
> >>>>> https://travis-ci.org/marex/u-boot-usb/builds/614059004
> >>>>>
> >>>>> Do you remember why on the TBS2910 board this size is limited to
> >>>>> 0x5fc00? Other i.MX6 boards like the Wandboard allow a much larger
> >>>>> u-boot.imx.
> >>>>>
> >>>>> The limit is defined here:
> >>>>> include/configs/tbs2910.h:80:
> >>>>> #define CONFIG_BOARD_SIZE_LIMIT 392192 /* (CONFIG_ENV_OFFSET - 1024) */
> >>>>>
> >>>>> Could the value CONFIG_ENV_OFFSET=0x60000 be enlarged?
> >>>>>
> >>>>> Many i.MX6 defconfigs use CONFIG_ENV_OFFSET=0xC0000.
> >>>>
> >>>> The nature of these boards (aimed at end users) means that we just do
> >>>> not want to / cannot really move the stored environment.  Thanks!
> >>>
> >>> Another possibility would be to reduce the image size by using
> >>> CONFIG_REGEX=n which should be fine for a board with only one supported
> >>> network interface.
> >>
> >> But the board was fine before your patchset got applied and this is just
> >> a workaround for added bloat, which reduces functionality. I dislike
> >> trading functionality for bloat, sorry.
> > 
> > One persons "bloat" is another persons "added functionality".
> 
> It would seem this board did not suffer from the lack of this particular
> functionality before, and I would say that a board should stay at least
> as functional as it was when it was added. Replacing existing
> functionality with random unrelated new one makes no sense.

Was it tho?  I believe we're talking about supporting some additional
keys via USB keyboard.  This board does in fact expect users to be at
the U-Boot prompt via USB keyboard.

> > I believe
> > the specific changes in question that once again push this board over
> > fall in to that grey area.  Whatever size-trimming the board maintainer
> > is fine with next is fine with me, but needs to get ack'd by someone.
> 
> Or, the other option is, make these new extra features configurable and
> disable them on this board. And so there should be no size problem.

But that direction leads to saying every slight bit of functionality
requires a new Kconfig entry.  Some levels of bugfixes as well.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20191121/bc6cdffd/attachment.sig>

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

[Marek Vasut]

On 11/22/19 1:32 AM, Tom Rini wrote:
> On Fri, Nov 22, 2019 at 01:23:56AM +0100, Marek Vasut wrote:
>> On 11/21/19 11:45 PM, Tom Rini wrote:
>>> On Thu, Nov 21, 2019 at 11:01:43PM +0100, Marek Vasut wrote:
>>>> On 11/21/19 10:59 PM, Heinrich Schuchardt wrote:
>>>>> On 11/21/19 9:12 PM, Tom Rini wrote:
>>>>>> On Thu, Nov 21, 2019 at 09:09:29PM +0100, Heinrich Schuchardt wrote:
>>>>>>> Hello Soeren,
>>>>>>>
>>>>>>> when trying to add support for function key support in the USB keyboard
>>>>>>> driver u-boot.imx for the TBS2910 surpassed the maximum size for
>>>>>>> u-boot.imx.
>>>>>>> https://travis-ci.org/marex/u-boot-usb/builds/614059004
>>>>>>>
>>>>>>> Do you remember why on the TBS2910 board this size is limited to
>>>>>>> 0x5fc00? Other i.MX6 boards like the Wandboard allow a much larger
>>>>>>> u-boot.imx.
>>>>>>>
>>>>>>> The limit is defined here:
>>>>>>> include/configs/tbs2910.h:80:
>>>>>>> #define CONFIG_BOARD_SIZE_LIMIT 392192 /* (CONFIG_ENV_OFFSET - 1024) */
>>>>>>>
>>>>>>> Could the value CONFIG_ENV_OFFSET=0x60000 be enlarged?
>>>>>>>
>>>>>>> Many i.MX6 defconfigs use CONFIG_ENV_OFFSET=0xC0000.
>>>>>>
>>>>>> The nature of these boards (aimed at end users) means that we just do
>>>>>> not want to / cannot really move the stored environment.  Thanks!
>>>>>
>>>>> Another possibility would be to reduce the image size by using
>>>>> CONFIG_REGEX=n which should be fine for a board with only one supported
>>>>> network interface.
>>>>
>>>> But the board was fine before your patchset got applied and this is just
>>>> a workaround for added bloat, which reduces functionality. I dislike
>>>> trading functionality for bloat, sorry.
>>>
>>> One persons "bloat" is another persons "added functionality".
>>
>> It would seem this board did not suffer from the lack of this particular
>> functionality before, and I would say that a board should stay at least
>> as functional as it was when it was added. Replacing existing
>> functionality with random unrelated new one makes no sense.
> 
> Was it tho?  I believe we're talking about supporting some additional
> keys via USB keyboard.  This board does in fact expect users to be at
> the U-Boot prompt via USB keyboard.

How did you reach this conclusion ? It seems to be some sort of devkit.

>>> I believe
>>> the specific changes in question that once again push this board over
>>> fall in to that grey area.  Whatever size-trimming the board maintainer
>>> is fine with next is fine with me, but needs to get ack'd by someone.
>>
>> Or, the other option is, make these new extra features configurable and
>> disable them on this board. And so there should be no size problem.
> 
> But that direction leads to saying every slight bit of functionality
> requires a new Kconfig entry.  Some levels of bugfixes as well.

The other option is, we will sink in bloat and suffer endless size problems.

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

[Tom Rini]

On Fri, Nov 22, 2019 at 02:27:16AM +0100, Marek Vasut wrote:
> On 11/22/19 1:32 AM, Tom Rini wrote:
> > On Fri, Nov 22, 2019 at 01:23:56AM +0100, Marek Vasut wrote:
> >> On 11/21/19 11:45 PM, Tom Rini wrote:
> >>> On Thu, Nov 21, 2019 at 11:01:43PM +0100, Marek Vasut wrote:
> >>>> On 11/21/19 10:59 PM, Heinrich Schuchardt wrote:
> >>>>> On 11/21/19 9:12 PM, Tom Rini wrote:
> >>>>>> On Thu, Nov 21, 2019 at 09:09:29PM +0100, Heinrich Schuchardt wrote:
> >>>>>>> Hello Soeren,
> >>>>>>>
> >>>>>>> when trying to add support for function key support in the USB keyboard
> >>>>>>> driver u-boot.imx for the TBS2910 surpassed the maximum size for
> >>>>>>> u-boot.imx.
> >>>>>>> https://travis-ci.org/marex/u-boot-usb/builds/614059004
> >>>>>>>
> >>>>>>> Do you remember why on the TBS2910 board this size is limited to
> >>>>>>> 0x5fc00? Other i.MX6 boards like the Wandboard allow a much larger
> >>>>>>> u-boot.imx.
> >>>>>>>
> >>>>>>> The limit is defined here:
> >>>>>>> include/configs/tbs2910.h:80:
> >>>>>>> #define CONFIG_BOARD_SIZE_LIMIT 392192 /* (CONFIG_ENV_OFFSET - 1024) */
> >>>>>>>
> >>>>>>> Could the value CONFIG_ENV_OFFSET=0x60000 be enlarged?
> >>>>>>>
> >>>>>>> Many i.MX6 defconfigs use CONFIG_ENV_OFFSET=0xC0000.
> >>>>>>
> >>>>>> The nature of these boards (aimed at end users) means that we just do
> >>>>>> not want to / cannot really move the stored environment.  Thanks!
> >>>>>
> >>>>> Another possibility would be to reduce the image size by using
> >>>>> CONFIG_REGEX=n which should be fine for a board with only one supported
> >>>>> network interface.
> >>>>
> >>>> But the board was fine before your patchset got applied and this is just
> >>>> a workaround for added bloat, which reduces functionality. I dislike
> >>>> trading functionality for bloat, sorry.
> >>>
> >>> One persons "bloat" is another persons "added functionality".
> >>
> >> It would seem this board did not suffer from the lack of this particular
> >> functionality before, and I would say that a board should stay at least
> >> as functional as it was when it was added. Replacing existing
> >> functionality with random unrelated new one makes no sense.
> > 
> > Was it tho?  I believe we're talking about supporting some additional
> > keys via USB keyboard.  This board does in fact expect users to be at
> > the U-Boot prompt via USB keyboard.
> 
> How did you reach this conclusion ? It seems to be some sort of devkit.

It came up in one of the previous threads about this board and what we
can / cannot do about the size constraint and the board maintainers
unhappiness about the overall size growth and broken releases (until
size growth became a link error on the platform).

> >>> I believe
> >>> the specific changes in question that once again push this board over
> >>> fall in to that grey area.  Whatever size-trimming the board maintainer
> >>> is fine with next is fine with me, but needs to get ack'd by someone.
> >>
> >> Or, the other option is, make these new extra features configurable and
> >> disable them on this board. And so there should be no size problem.
> > 
> > But that direction leads to saying every slight bit of functionality
> > requires a new Kconfig entry.  Some levels of bugfixes as well.
> 
> The other option is, we will sink in bloat and suffer endless size problems.

Yes, it is a hard balancing act.  Stepping back, perhaps a "minimal" or
"complete" choice for USB HID devices would make sense and allow us
further areas to reduce size, on the minimal portion.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20191121/203e2fc4/attachment.sig>

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

[Marek Vasut]

On 11/22/19 2:30 AM, Tom Rini wrote:
> On Fri, Nov 22, 2019 at 02:27:16AM +0100, Marek Vasut wrote:
>> On 11/22/19 1:32 AM, Tom Rini wrote:
>>> On Fri, Nov 22, 2019 at 01:23:56AM +0100, Marek Vasut wrote:
>>>> On 11/21/19 11:45 PM, Tom Rini wrote:
>>>>> On Thu, Nov 21, 2019 at 11:01:43PM +0100, Marek Vasut wrote:
>>>>>> On 11/21/19 10:59 PM, Heinrich Schuchardt wrote:
>>>>>>> On 11/21/19 9:12 PM, Tom Rini wrote:
>>>>>>>> On Thu, Nov 21, 2019 at 09:09:29PM +0100, Heinrich Schuchardt wrote:
>>>>>>>>> Hello Soeren,
>>>>>>>>>
>>>>>>>>> when trying to add support for function key support in the USB keyboard
>>>>>>>>> driver u-boot.imx for the TBS2910 surpassed the maximum size for
>>>>>>>>> u-boot.imx.
>>>>>>>>> https://travis-ci.org/marex/u-boot-usb/builds/614059004
>>>>>>>>>
>>>>>>>>> Do you remember why on the TBS2910 board this size is limited to
>>>>>>>>> 0x5fc00? Other i.MX6 boards like the Wandboard allow a much larger
>>>>>>>>> u-boot.imx.
>>>>>>>>>
>>>>>>>>> The limit is defined here:
>>>>>>>>> include/configs/tbs2910.h:80:
>>>>>>>>> #define CONFIG_BOARD_SIZE_LIMIT 392192 /* (CONFIG_ENV_OFFSET - 1024) */
>>>>>>>>>
>>>>>>>>> Could the value CONFIG_ENV_OFFSET=0x60000 be enlarged?
>>>>>>>>>
>>>>>>>>> Many i.MX6 defconfigs use CONFIG_ENV_OFFSET=0xC0000.
>>>>>>>>
>>>>>>>> The nature of these boards (aimed at end users) means that we just do
>>>>>>>> not want to / cannot really move the stored environment.  Thanks!
>>>>>>>
>>>>>>> Another possibility would be to reduce the image size by using
>>>>>>> CONFIG_REGEX=n which should be fine for a board with only one supported
>>>>>>> network interface.
>>>>>>
>>>>>> But the board was fine before your patchset got applied and this is just
>>>>>> a workaround for added bloat, which reduces functionality. I dislike
>>>>>> trading functionality for bloat, sorry.
>>>>>
>>>>> One persons "bloat" is another persons "added functionality".
>>>>
>>>> It would seem this board did not suffer from the lack of this particular
>>>> functionality before, and I would say that a board should stay at least
>>>> as functional as it was when it was added. Replacing existing
>>>> functionality with random unrelated new one makes no sense.
>>>
>>> Was it tho?  I believe we're talking about supporting some additional
>>> keys via USB keyboard.  This board does in fact expect users to be at
>>> the U-Boot prompt via USB keyboard.
>>
>> How did you reach this conclusion ? It seems to be some sort of devkit.
> 
> It came up in one of the previous threads about this board and what we
> can / cannot do about the size constraint and the board maintainers
> unhappiness about the overall size growth and broken releases (until
> size growth became a link error on the platform).

Link please ? It sounds relevant to this thread too.

>>>>> I believe
>>>>> the specific changes in question that once again push this board over
>>>>> fall in to that grey area.  Whatever size-trimming the board maintainer
>>>>> is fine with next is fine with me, but needs to get ack'd by someone.
>>>>
>>>> Or, the other option is, make these new extra features configurable and
>>>> disable them on this board. And so there should be no size problem.
>>>
>>> But that direction leads to saying every slight bit of functionality
>>> requires a new Kconfig entry.  Some levels of bugfixes as well.
>>
>> The other option is, we will sink in bloat and suffer endless size problems.
> 
> Yes, it is a hard balancing act.  Stepping back, perhaps a "minimal" or
> "complete" choice for USB HID devices would make sense and allow us
> further areas to reduce size, on the minimal portion.

Or maybe there is a way to help compiler optimize that USB key code
handling better.

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

[Tom Rini]

On Fri, Nov 22, 2019 at 02:38:51AM +0100, Marek Vasut wrote:
> On 11/22/19 2:30 AM, Tom Rini wrote:
> > On Fri, Nov 22, 2019 at 02:27:16AM +0100, Marek Vasut wrote:
> >> On 11/22/19 1:32 AM, Tom Rini wrote:
> >>> On Fri, Nov 22, 2019 at 01:23:56AM +0100, Marek Vasut wrote:
> >>>> On 11/21/19 11:45 PM, Tom Rini wrote:
> >>>>> On Thu, Nov 21, 2019 at 11:01:43PM +0100, Marek Vasut wrote:
> >>>>>> On 11/21/19 10:59 PM, Heinrich Schuchardt wrote:
> >>>>>>> On 11/21/19 9:12 PM, Tom Rini wrote:
> >>>>>>>> On Thu, Nov 21, 2019 at 09:09:29PM +0100, Heinrich Schuchardt wrote:
> >>>>>>>>> Hello Soeren,
> >>>>>>>>>
> >>>>>>>>> when trying to add support for function key support in the USB keyboard
> >>>>>>>>> driver u-boot.imx for the TBS2910 surpassed the maximum size for
> >>>>>>>>> u-boot.imx.
> >>>>>>>>> https://travis-ci.org/marex/u-boot-usb/builds/614059004
> >>>>>>>>>
> >>>>>>>>> Do you remember why on the TBS2910 board this size is limited to
> >>>>>>>>> 0x5fc00? Other i.MX6 boards like the Wandboard allow a much larger
> >>>>>>>>> u-boot.imx.
> >>>>>>>>>
> >>>>>>>>> The limit is defined here:
> >>>>>>>>> include/configs/tbs2910.h:80:
> >>>>>>>>> #define CONFIG_BOARD_SIZE_LIMIT 392192 /* (CONFIG_ENV_OFFSET - 1024) */
> >>>>>>>>>
> >>>>>>>>> Could the value CONFIG_ENV_OFFSET=0x60000 be enlarged?
> >>>>>>>>>
> >>>>>>>>> Many i.MX6 defconfigs use CONFIG_ENV_OFFSET=0xC0000.
> >>>>>>>>
> >>>>>>>> The nature of these boards (aimed at end users) means that we just do
> >>>>>>>> not want to / cannot really move the stored environment.  Thanks!
> >>>>>>>
> >>>>>>> Another possibility would be to reduce the image size by using
> >>>>>>> CONFIG_REGEX=n which should be fine for a board with only one supported
> >>>>>>> network interface.
> >>>>>>
> >>>>>> But the board was fine before your patchset got applied and this is just
> >>>>>> a workaround for added bloat, which reduces functionality. I dislike
> >>>>>> trading functionality for bloat, sorry.
> >>>>>
> >>>>> One persons "bloat" is another persons "added functionality".
> >>>>
> >>>> It would seem this board did not suffer from the lack of this particular
> >>>> functionality before, and I would say that a board should stay at least
> >>>> as functional as it was when it was added. Replacing existing
> >>>> functionality with random unrelated new one makes no sense.
> >>>
> >>> Was it tho?  I believe we're talking about supporting some additional
> >>> keys via USB keyboard.  This board does in fact expect users to be at
> >>> the U-Boot prompt via USB keyboard.
> >>
> >> How did you reach this conclusion ? It seems to be some sort of devkit.
> > 
> > It came up in one of the previous threads about this board and what we
> > can / cannot do about the size constraint and the board maintainers
> > unhappiness about the overall size growth and broken releases (until
> > size growth became a link error on the platform).
> 
> Link please ? It sounds relevant to this thread too.

https://lists.denx.de/pipermail/u-boot/2019-April/365297.html

> >>>>> I believe
> >>>>> the specific changes in question that once again push this board over
> >>>>> fall in to that grey area.  Whatever size-trimming the board maintainer
> >>>>> is fine with next is fine with me, but needs to get ack'd by someone.
> >>>>
> >>>> Or, the other option is, make these new extra features configurable and
> >>>> disable them on this board. And so there should be no size problem.
> >>>
> >>> But that direction leads to saying every slight bit of functionality
> >>> requires a new Kconfig entry.  Some levels of bugfixes as well.
> >>
> >> The other option is, we will sink in bloat and suffer endless size problems.
> > 
> > Yes, it is a hard balancing act.  Stepping back, perhaps a "minimal" or
> > "complete" choice for USB HID devices would make sense and allow us
> > further areas to reduce size, on the minimal portion.
> 
> Or maybe there is a way to help compiler optimize that USB key code
> handling better.

Perhaps.  But my point is that every little functional change or
enhancement does not need a Kconfig option.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20191121/2883d756/attachment.sig>

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

[Marek Vasut]

On 11/22/19 3:53 AM, Tom Rini wrote:
> On Fri, Nov 22, 2019 at 02:38:51AM +0100, Marek Vasut wrote:
>> On 11/22/19 2:30 AM, Tom Rini wrote:
>>> On Fri, Nov 22, 2019 at 02:27:16AM +0100, Marek Vasut wrote:
>>>> On 11/22/19 1:32 AM, Tom Rini wrote:
>>>>> On Fri, Nov 22, 2019 at 01:23:56AM +0100, Marek Vasut wrote:
>>>>>> On 11/21/19 11:45 PM, Tom Rini wrote:
>>>>>>> On Thu, Nov 21, 2019 at 11:01:43PM +0100, Marek Vasut wrote:
>>>>>>>> On 11/21/19 10:59 PM, Heinrich Schuchardt wrote:
>>>>>>>>> On 11/21/19 9:12 PM, Tom Rini wrote:
>>>>>>>>>> On Thu, Nov 21, 2019 at 09:09:29PM +0100, Heinrich Schuchardt wrote:
>>>>>>>>>>> Hello Soeren,
>>>>>>>>>>>
>>>>>>>>>>> when trying to add support for function key support in the USB keyboard
>>>>>>>>>>> driver u-boot.imx for the TBS2910 surpassed the maximum size for
>>>>>>>>>>> u-boot.imx.
>>>>>>>>>>> https://travis-ci.org/marex/u-boot-usb/builds/614059004
>>>>>>>>>>>
>>>>>>>>>>> Do you remember why on the TBS2910 board this size is limited to
>>>>>>>>>>> 0x5fc00? Other i.MX6 boards like the Wandboard allow a much larger
>>>>>>>>>>> u-boot.imx.
>>>>>>>>>>>
>>>>>>>>>>> The limit is defined here:
>>>>>>>>>>> include/configs/tbs2910.h:80:
>>>>>>>>>>> #define CONFIG_BOARD_SIZE_LIMIT 392192 /* (CONFIG_ENV_OFFSET - 1024) */
>>>>>>>>>>>
>>>>>>>>>>> Could the value CONFIG_ENV_OFFSET=0x60000 be enlarged?
>>>>>>>>>>>
>>>>>>>>>>> Many i.MX6 defconfigs use CONFIG_ENV_OFFSET=0xC0000.
>>>>>>>>>>
>>>>>>>>>> The nature of these boards (aimed at end users) means that we just do
>>>>>>>>>> not want to / cannot really move the stored environment.  Thanks!
>>>>>>>>>
>>>>>>>>> Another possibility would be to reduce the image size by using
>>>>>>>>> CONFIG_REGEX=n which should be fine for a board with only one supported
>>>>>>>>> network interface.
>>>>>>>>
>>>>>>>> But the board was fine before your patchset got applied and this is just
>>>>>>>> a workaround for added bloat, which reduces functionality. I dislike
>>>>>>>> trading functionality for bloat, sorry.
>>>>>>>
>>>>>>> One persons "bloat" is another persons "added functionality".
>>>>>>
>>>>>> It would seem this board did not suffer from the lack of this particular
>>>>>> functionality before, and I would say that a board should stay at least
>>>>>> as functional as it was when it was added. Replacing existing
>>>>>> functionality with random unrelated new one makes no sense.
>>>>>
>>>>> Was it tho?  I believe we're talking about supporting some additional
>>>>> keys via USB keyboard.  This board does in fact expect users to be at
>>>>> the U-Boot prompt via USB keyboard.
>>>>
>>>> How did you reach this conclusion ? It seems to be some sort of devkit.
>>>
>>> It came up in one of the previous threads about this board and what we
>>> can / cannot do about the size constraint and the board maintainers
>>> unhappiness about the overall size growth and broken releases (until
>>> size growth became a link error on the platform).
>>
>> Link please ? It sounds relevant to this thread too.
> 
> https://lists.denx.de/pipermail/u-boot/2019-April/365297.html
> 
>>>>>>> I believe
>>>>>>> the specific changes in question that once again push this board over
>>>>>>> fall in to that grey area.  Whatever size-trimming the board maintainer
>>>>>>> is fine with next is fine with me, but needs to get ack'd by someone.
>>>>>>
>>>>>> Or, the other option is, make these new extra features configurable and
>>>>>> disable them on this board. And so there should be no size problem.
>>>>>
>>>>> But that direction leads to saying every slight bit of functionality
>>>>> requires a new Kconfig entry.  Some levels of bugfixes as well.
>>>>
>>>> The other option is, we will sink in bloat and suffer endless size problems.
>>>
>>> Yes, it is a hard balancing act.  Stepping back, perhaps a "minimal" or
>>> "complete" choice for USB HID devices would make sense and allow us
>>> further areas to reduce size, on the minimal portion.
>>
>> Or maybe there is a way to help compiler optimize that USB key code
>> handling better.
> 
> Perhaps.  But my point is that every little functional change or
> enhancement does not need a Kconfig option.

Except this leads to slow and steady accumulation of bloat, and as we
already see for quite a while, this is problematic for more and more boards.

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

[Tom Rini]

On Fri, Nov 22, 2019 at 03:56:14AM +0100, Marek Vasut wrote:
> On 11/22/19 3:53 AM, Tom Rini wrote:
> > On Fri, Nov 22, 2019 at 02:38:51AM +0100, Marek Vasut wrote:
> >> On 11/22/19 2:30 AM, Tom Rini wrote:
> >>> On Fri, Nov 22, 2019 at 02:27:16AM +0100, Marek Vasut wrote:
> >>>> On 11/22/19 1:32 AM, Tom Rini wrote:
> >>>>> On Fri, Nov 22, 2019 at 01:23:56AM +0100, Marek Vasut wrote:
> >>>>>> On 11/21/19 11:45 PM, Tom Rini wrote:
> >>>>>>> On Thu, Nov 21, 2019 at 11:01:43PM +0100, Marek Vasut wrote:
> >>>>>>>> On 11/21/19 10:59 PM, Heinrich Schuchardt wrote:
> >>>>>>>>> On 11/21/19 9:12 PM, Tom Rini wrote:
> >>>>>>>>>> On Thu, Nov 21, 2019 at 09:09:29PM +0100, Heinrich Schuchardt wrote:
> >>>>>>>>>>> Hello Soeren,
> >>>>>>>>>>>
> >>>>>>>>>>> when trying to add support for function key support in the USB keyboard
> >>>>>>>>>>> driver u-boot.imx for the TBS2910 surpassed the maximum size for
> >>>>>>>>>>> u-boot.imx.
> >>>>>>>>>>> https://travis-ci.org/marex/u-boot-usb/builds/614059004
> >>>>>>>>>>>
> >>>>>>>>>>> Do you remember why on the TBS2910 board this size is limited to
> >>>>>>>>>>> 0x5fc00? Other i.MX6 boards like the Wandboard allow a much larger
> >>>>>>>>>>> u-boot.imx.
> >>>>>>>>>>>
> >>>>>>>>>>> The limit is defined here:
> >>>>>>>>>>> include/configs/tbs2910.h:80:
> >>>>>>>>>>> #define CONFIG_BOARD_SIZE_LIMIT 392192 /* (CONFIG_ENV_OFFSET - 1024) */
> >>>>>>>>>>>
> >>>>>>>>>>> Could the value CONFIG_ENV_OFFSET=0x60000 be enlarged?
> >>>>>>>>>>>
> >>>>>>>>>>> Many i.MX6 defconfigs use CONFIG_ENV_OFFSET=0xC0000.
> >>>>>>>>>>
> >>>>>>>>>> The nature of these boards (aimed at end users) means that we just do
> >>>>>>>>>> not want to / cannot really move the stored environment.  Thanks!
> >>>>>>>>>
> >>>>>>>>> Another possibility would be to reduce the image size by using
> >>>>>>>>> CONFIG_REGEX=n which should be fine for a board with only one supported
> >>>>>>>>> network interface.
> >>>>>>>>
> >>>>>>>> But the board was fine before your patchset got applied and this is just
> >>>>>>>> a workaround for added bloat, which reduces functionality. I dislike
> >>>>>>>> trading functionality for bloat, sorry.
> >>>>>>>
> >>>>>>> One persons "bloat" is another persons "added functionality".
> >>>>>>
> >>>>>> It would seem this board did not suffer from the lack of this particular
> >>>>>> functionality before, and I would say that a board should stay at least
> >>>>>> as functional as it was when it was added. Replacing existing
> >>>>>> functionality with random unrelated new one makes no sense.
> >>>>>
> >>>>> Was it tho?  I believe we're talking about supporting some additional
> >>>>> keys via USB keyboard.  This board does in fact expect users to be at
> >>>>> the U-Boot prompt via USB keyboard.
> >>>>
> >>>> How did you reach this conclusion ? It seems to be some sort of devkit.
> >>>
> >>> It came up in one of the previous threads about this board and what we
> >>> can / cannot do about the size constraint and the board maintainers
> >>> unhappiness about the overall size growth and broken releases (until
> >>> size growth became a link error on the platform).
> >>
> >> Link please ? It sounds relevant to this thread too.
> > 
> > https://lists.denx.de/pipermail/u-boot/2019-April/365297.html
> > 
> >>>>>>> I believe
> >>>>>>> the specific changes in question that once again push this board over
> >>>>>>> fall in to that grey area.  Whatever size-trimming the board maintainer
> >>>>>>> is fine with next is fine with me, but needs to get ack'd by someone.
> >>>>>>
> >>>>>> Or, the other option is, make these new extra features configurable and
> >>>>>> disable them on this board. And so there should be no size problem.
> >>>>>
> >>>>> But that direction leads to saying every slight bit of functionality
> >>>>> requires a new Kconfig entry.  Some levels of bugfixes as well.
> >>>>
> >>>> The other option is, we will sink in bloat and suffer endless size problems.
> >>>
> >>> Yes, it is a hard balancing act.  Stepping back, perhaps a "minimal" or
> >>> "complete" choice for USB HID devices would make sense and allow us
> >>> further areas to reduce size, on the minimal portion.
> >>
> >> Or maybe there is a way to help compiler optimize that USB key code
> >> handling better.
> > 
> > Perhaps.  But my point is that every little functional change or
> > enhancement does not need a Kconfig option.
> 
> Except this leads to slow and steady accumulation of bloat, and as we
> already see for quite a while, this is problematic for more and more boards.

And "bloat" and "features" are interchangable terms.  I really am trying
to be more responsive than ever to size growth in common, rather than
board specific areas.  And I agree, some investigation in to ways that
might reduce the size of binary support for USB HID devices is good.
Figuring out if we can make this series:
http://patchwork.ozlabs.org/project/uboot/list/?series=135448
not also increase the overall size, or increase it less, is good.
Hiding the content of 2/5 behind a CONFIG option in turn brings us back
to "the code is too messy and full of #ifdef" lines.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20191121/a57fabc8/attachment.sig>

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

[Marek Vasut]

On 11/22/19 4:41 AM, Tom Rini wrote:
[...]
>>>>>>>>> I believe
>>>>>>>>> the specific changes in question that once again push this board over
>>>>>>>>> fall in to that grey area.  Whatever size-trimming the board maintainer
>>>>>>>>> is fine with next is fine with me, but needs to get ack'd by someone.
>>>>>>>>
>>>>>>>> Or, the other option is, make these new extra features configurable and
>>>>>>>> disable them on this board. And so there should be no size problem.
>>>>>>>
>>>>>>> But that direction leads to saying every slight bit of functionality
>>>>>>> requires a new Kconfig entry.  Some levels of bugfixes as well.
>>>>>>
>>>>>> The other option is, we will sink in bloat and suffer endless size problems.
>>>>>
>>>>> Yes, it is a hard balancing act.  Stepping back, perhaps a "minimal" or
>>>>> "complete" choice for USB HID devices would make sense and allow us
>>>>> further areas to reduce size, on the minimal portion.
>>>>
>>>> Or maybe there is a way to help compiler optimize that USB key code
>>>> handling better.
>>>
>>> Perhaps.  But my point is that every little functional change or
>>> enhancement does not need a Kconfig option.
>>
>> Except this leads to slow and steady accumulation of bloat, and as we
>> already see for quite a while, this is problematic for more and more boards.
> 
> And "bloat" and "features" are interchangable terms.

Nope, bloat is unhelpful growth of size, features are actually
helpful/useful.

> I really am trying
> to be more responsive than ever to size growth in common, rather than
> board specific areas.  And I agree, some investigation in to ways that
> might reduce the size of binary support for USB HID devices is good.

So we agree that's what this series should fix ?

> Figuring out if we can make this series:
> http://patchwork.ozlabs.org/project/uboot/list/?series=135448
> not also increase the overall size, or increase it less, is good.
> Hiding the content of 2/5 behind a CONFIG option in turn brings us back
> to "the code is too messy and full of #ifdef" lines.

Which might be somewhat better than if the code is sprinkled with tiny
chunks of random pieces of code which are never used, but in total add
up to a lot of unused code in the binary.

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

[Soeren Moch]

On 22.11.19 04:58, Marek Vasut wrote:
> On 11/22/19 4:41 AM, Tom Rini wrote:
> [...]
>>>>>>>>>> I believe
>>>>>>>>>> the specific changes in question that once again push this board over
>>>>>>>>>> fall in to that grey area.  Whatever size-trimming the board maintainer
>>>>>>>>>> is fine with next is fine with me, but needs to get ack'd by someone.
>>>>>>>>> Or, the other option is, make these new extra features configurable and
>>>>>>>>> disable them on this board. And so there should be no size problem.
>>>>>>>> But that direction leads to saying every slight bit of functionality
>>>>>>>> requires a new Kconfig entry.  Some levels of bugfixes as well.
>>>>>>> The other option is, we will sink in bloat and suffer endless size problems.
>>>>>> Yes, it is a hard balancing act.  Stepping back, perhaps a "minimal" or
>>>>>> "complete" choice for USB HID devices would make sense and allow us
>>>>>> further areas to reduce size, on the minimal portion.
>>>>> Or maybe there is a way to help compiler optimize that USB key code
>>>>> handling better.
>>>> Perhaps.  But my point is that every little functional change or
>>>> enhancement does not need a Kconfig option.
>>> Except this leads to slow and steady accumulation of bloat, and as we
>>> already see for quite a while, this is problematic for more and more boards.
>> And "bloat" and "features" are interchangable terms.
> Nope, bloat is unhelpful growth of size, features are actually
> helpful/useful.
>
>> I really am trying
>> to be more responsive than ever to size growth in common, rather than
>> board specific areas.  And I agree, some investigation in to ways that
>> might reduce the size of binary support for USB HID devices is good.
> So we agree that's what this series should fix ?
>
>> Figuring out if we can make this series:
>> http://patchwork.ozlabs.org/project/uboot/list/?series=135448
>> not also increase the overall size, or increase it less, is good.
>> Hiding the content of 2/5 behind a CONFIG option in turn brings us back
>> to "the code is too messy and full of #ifdef" lines.
> Which might be somewhat better than if the code is sprinkled with tiny
> chunks of random pieces of code which are never used, but in total add
> up to a lot of unused code in the binary.

What a long discussion over night, so only a general answer:

Once upon a time there was plenty of space for tbs2910 u-boot.
Then we had to convert everything to DM, for whatever reason. This
increased the binary size a lot, had absolutely no advantage for u-boot
users, was huge effort for board maintainers, and is still going on.
(DM_VIDEO conversion still pending for this board, probably more to
come, DM_SERIAL?). For all that additional space is required, apparently
nobody tries to cleanup the non-DM code for converted subsystems to
reclaim some of the space.

Several times I tried to disable unneeded functions to trim the binary
size. After a few weeks the gained space was eaten up, apparently nobody
cares about binary size anymore as long as there is no build failure.
Even worse, since imx format is padded, people claim to not increase the
binary size with there patches (what in fact is not true), and then some
simple change / tool update again breaks everything.

What is the solution to that? I don't see much what _I_ can do. If I
find some option to disable again, what is increasingly difficult, then
this removes the last opportunity for upcoming DM conversions.
For the "bloat" vs. "features" discussion: on long existing boards no
user expects new features in defconfig, especially if they only come
with reduced functionality somewhere else. And as hobbyist board
maintainer I don't know which features existing users actually use. I
only get bug reports about bricked boards when something is missing.

Soeren

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

[Heinrich Schuchardt]

On 11/22/19 11:29 AM, Soeren Moch wrote:
>
>
> On 22.11.19 04:58, Marek Vasut wrote:
>> On 11/22/19 4:41 AM, Tom Rini wrote:
>> [...]
>>>>>>>>>>> I believe
>>>>>>>>>>> the specific changes in question that once again push this board over
>>>>>>>>>>> fall in to that grey area.  Whatever size-trimming the board maintainer
>>>>>>>>>>> is fine with next is fine with me, but needs to get ack'd by someone.
>>>>>>>>>> Or, the other option is, make these new extra features configurable and
>>>>>>>>>> disable them on this board. And so there should be no size problem.
>>>>>>>>> But that direction leads to saying every slight bit of functionality
>>>>>>>>> requires a new Kconfig entry.  Some levels of bugfixes as well.
>>>>>>>> The other option is, we will sink in bloat and suffer endless size problems.
>>>>>>> Yes, it is a hard balancing act.  Stepping back, perhaps a "minimal" or
>>>>>>> "complete" choice for USB HID devices would make sense and allow us
>>>>>>> further areas to reduce size, on the minimal portion.
>>>>>> Or maybe there is a way to help compiler optimize that USB key code
>>>>>> handling better.
>>>>> Perhaps.  But my point is that every little functional change or
>>>>> enhancement does not need a Kconfig option.
>>>> Except this leads to slow and steady accumulation of bloat, and as we
>>>> already see for quite a while, this is problematic for more and more boards.
>>> And "bloat" and "features" are interchangable terms.
>> Nope, bloat is unhelpful growth of size, features are actually
>> helpful/useful.
>>
>>> I really am trying
>>> to be more responsive than ever to size growth in common, rather than
>>> board specific areas.  And I agree, some investigation in to ways that
>>> might reduce the size of binary support for USB HID devices is good.
>> So we agree that's what this series should fix ?
>>
>>> Figuring out if we can make this series:
>>> http://patchwork.ozlabs.org/project/uboot/list/?series=135448
>>> not also increase the overall size, or increase it less, is good.
>>> Hiding the content of 2/5 behind a CONFIG option in turn brings us back
>>> to "the code is too messy and full of #ifdef" lines.
>> Which might be somewhat better than if the code is sprinkled with tiny
>> chunks of random pieces of code which are never used, but in total add
>> up to a lot of unused code in the binary.
>
> What a long discussion over night, so only a general answer:
>
> Once upon a time there was plenty of space for tbs2910 u-boot.
> Then we had to convert everything to DM, for whatever reason. This
> increased the binary size a lot, had absolutely no advantage for u-boot
> users, was huge effort for board maintainers, and is still going on.
> (DM_VIDEO conversion still pending for this board, probably more to
> come, DM_SERIAL?). For all that additional space is required, apparently
> nobody tries to cleanup the non-DM code for converted subsystems to
> reclaim some of the space.
>
> Several times I tried to disable unneeded functions to trim the binary
> size. After a few weeks the gained space was eaten up, apparently nobody
> cares about binary size anymore as long as there is no build failure.
> Even worse, since imx format is padded, people claim to not increase the
> binary size with there patches (what in fact is not true), and then some
> simple change / tool update again breaks everything.
>
> What is the solution to that? I don't see much what _I_ can do. If I
> find some option to disable again, what is increasingly difficult, then
> this removes the last opportunity for upcoming DM conversions.
> For the "bloat" vs. "features" discussion: on long existing boards no
> user expects new features in defconfig, especially if they only come
> with reduced functionality somewhere else. And as hobbyist board
> maintainer I don't know which features existing users actually use. I
> only get bug reports about bricked boards when something is missing.
>
> Soeren
>
>
Hello Soeren,

what is your view on changing CONFIG_ENV_OFFSET=0x60000 to
CONFIG_ENV_OFFSET=0xC0000?

Best regards

Heinrich

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

[Marek Vasut]

On 11/22/19 11:29 AM, Soeren Moch wrote:
> 
> 
> On 22.11.19 04:58, Marek Vasut wrote:
>> On 11/22/19 4:41 AM, Tom Rini wrote:
>> [...]
>>>>>>>>>>> I believe
>>>>>>>>>>> the specific changes in question that once again push this board over
>>>>>>>>>>> fall in to that grey area.  Whatever size-trimming the board maintainer
>>>>>>>>>>> is fine with next is fine with me, but needs to get ack'd by someone.
>>>>>>>>>> Or, the other option is, make these new extra features configurable and
>>>>>>>>>> disable them on this board. And so there should be no size problem.
>>>>>>>>> But that direction leads to saying every slight bit of functionality
>>>>>>>>> requires a new Kconfig entry.  Some levels of bugfixes as well.
>>>>>>>> The other option is, we will sink in bloat and suffer endless size problems.
>>>>>>> Yes, it is a hard balancing act.  Stepping back, perhaps a "minimal" or
>>>>>>> "complete" choice for USB HID devices would make sense and allow us
>>>>>>> further areas to reduce size, on the minimal portion.
>>>>>> Or maybe there is a way to help compiler optimize that USB key code
>>>>>> handling better.
>>>>> Perhaps.  But my point is that every little functional change or
>>>>> enhancement does not need a Kconfig option.
>>>> Except this leads to slow and steady accumulation of bloat, and as we
>>>> already see for quite a while, this is problematic for more and more boards.
>>> And "bloat" and "features" are interchangable terms.
>> Nope, bloat is unhelpful growth of size, features are actually
>> helpful/useful.
>>
>>> I really am trying
>>> to be more responsive than ever to size growth in common, rather than
>>> board specific areas.  And I agree, some investigation in to ways that
>>> might reduce the size of binary support for USB HID devices is good.
>> So we agree that's what this series should fix ?
>>
>>> Figuring out if we can make this series:
>>> http://patchwork.ozlabs.org/project/uboot/list/?series=135448
>>> not also increase the overall size, or increase it less, is good.
>>> Hiding the content of 2/5 behind a CONFIG option in turn brings us back
>>> to "the code is too messy and full of #ifdef" lines.
>> Which might be somewhat better than if the code is sprinkled with tiny
>> chunks of random pieces of code which are never used, but in total add
>> up to a lot of unused code in the binary.
> 
> What a long discussion over night, so only a general answer:
> 
> Once upon a time there was plenty of space for tbs2910 u-boot.
> Then we had to convert everything to DM, for whatever reason. This
> increased the binary size a lot, had absolutely no advantage for u-boot
> users, was huge effort for board maintainers, and is still going on.
> (DM_VIDEO conversion still pending for this board, probably more to
> come, DM_SERIAL?). For all that additional space is required, apparently
> nobody tries to cleanup the non-DM code for converted subsystems to
> reclaim some of the space.
> 
> Several times I tried to disable unneeded functions to trim the binary
> size. After a few weeks the gained space was eaten up, apparently nobody
> cares about binary size anymore as long as there is no build failure.
> Even worse, since imx format is padded, people claim to not increase the
> binary size with there patches (what in fact is not true), and then some
> simple change / tool update again breaks everything.
> 
> What is the solution to that? I don't see much what _I_ can do. If I
> find some option to disable again, what is increasingly difficult, then
> this removes the last opportunity for upcoming DM conversions.
> For the "bloat" vs. "features" discussion: on long existing boards no
> user expects new features in defconfig, especially if they only come
> with reduced functionality somewhere else. And as hobbyist board
> maintainer I don't know which features existing users actually use. I
> only get bug reports about bricked boards when something is missing.

Thank you for spelling this out, I fully agree with these sentiments.

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

[Tom Rini]

On Fri, Nov 22, 2019 at 12:42:49PM +0100, Heinrich Schuchardt wrote:
> On 11/22/19 11:29 AM, Soeren Moch wrote:
> > 
> > 
> > On 22.11.19 04:58, Marek Vasut wrote:
> > > On 11/22/19 4:41 AM, Tom Rini wrote:
> > > [...]
> > > > > > > > > > > > I believe
> > > > > > > > > > > > the specific changes in question that once again push this board over
> > > > > > > > > > > > fall in to that grey area.  Whatever size-trimming the board maintainer
> > > > > > > > > > > > is fine with next is fine with me, but needs to get ack'd by someone.
> > > > > > > > > > > Or, the other option is, make these new extra features configurable and
> > > > > > > > > > > disable them on this board. And so there should be no size problem.
> > > > > > > > > > But that direction leads to saying every slight bit of functionality
> > > > > > > > > > requires a new Kconfig entry.  Some levels of bugfixes as well.
> > > > > > > > > The other option is, we will sink in bloat and suffer endless size problems.
> > > > > > > > Yes, it is a hard balancing act.  Stepping back, perhaps a "minimal" or
> > > > > > > > "complete" choice for USB HID devices would make sense and allow us
> > > > > > > > further areas to reduce size, on the minimal portion.
> > > > > > > Or maybe there is a way to help compiler optimize that USB key code
> > > > > > > handling better.
> > > > > > Perhaps.  But my point is that every little functional change or
> > > > > > enhancement does not need a Kconfig option.
> > > > > Except this leads to slow and steady accumulation of bloat, and as we
> > > > > already see for quite a while, this is problematic for more and more boards.
> > > > And "bloat" and "features" are interchangable terms.
> > > Nope, bloat is unhelpful growth of size, features are actually
> > > helpful/useful.
> > > 
> > > > I really am trying
> > > > to be more responsive than ever to size growth in common, rather than
> > > > board specific areas.  And I agree, some investigation in to ways that
> > > > might reduce the size of binary support for USB HID devices is good.
> > > So we agree that's what this series should fix ?
> > > 
> > > > Figuring out if we can make this series:
> > > > http://patchwork.ozlabs.org/project/uboot/list/?series=135448
> > > > not also increase the overall size, or increase it less, is good.
> > > > Hiding the content of 2/5 behind a CONFIG option in turn brings us back
> > > > to "the code is too messy and full of #ifdef" lines.
> > > Which might be somewhat better than if the code is sprinkled with tiny
> > > chunks of random pieces of code which are never used, but in total add
> > > up to a lot of unused code in the binary.
> > 
> > What a long discussion over night, so only a general answer:
> > 
> > Once upon a time there was plenty of space for tbs2910 u-boot.
> > Then we had to convert everything to DM, for whatever reason. This
> > increased the binary size a lot, had absolutely no advantage for u-boot
> > users, was huge effort for board maintainers, and is still going on.
> > (DM_VIDEO conversion still pending for this board, probably more to
> > come, DM_SERIAL?). For all that additional space is required, apparently
> > nobody tries to cleanup the non-DM code for converted subsystems to
> > reclaim some of the space.
> > 
> > Several times I tried to disable unneeded functions to trim the binary
> > size. After a few weeks the gained space was eaten up, apparently nobody
> > cares about binary size anymore as long as there is no build failure.
> > Even worse, since imx format is padded, people claim to not increase the
> > binary size with there patches (what in fact is not true), and then some
> > simple change / tool update again breaks everything.
> > 
> > What is the solution to that? I don't see much what _I_ can do. If I
> > find some option to disable again, what is increasingly difficult, then
> > this removes the last opportunity for upcoming DM conversions.
> > For the "bloat" vs. "features" discussion: on long existing boards no
> > user expects new features in defconfig, especially if they only come
> > with reduced functionality somewhere else. And as hobbyist board
> > maintainer I don't know which features existing users actually use. I
> > only get bug reports about bricked boards when something is missing.
> > 
> > Soeren
> > 
> > 
> Hello Soeren,
> 
> what is your view on changing CONFIG_ENV_OFFSET=0x60000 to
> CONFIG_ENV_OFFSET=0xC0000?

I am still against that move as we need to address the real underlying
problem of size growth.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20191122/f263ff3c/attachment.sig>

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

[Tom Rini]

On Fri, Nov 22, 2019 at 04:58:29AM +0100, Marek Vasut wrote:
> On 11/22/19 4:41 AM, Tom Rini wrote:
> [...]
> >>>>>>>>> I believe
> >>>>>>>>> the specific changes in question that once again push this board over
> >>>>>>>>> fall in to that grey area.  Whatever size-trimming the board maintainer
> >>>>>>>>> is fine with next is fine with me, but needs to get ack'd by someone.
> >>>>>>>>
> >>>>>>>> Or, the other option is, make these new extra features configurable and
> >>>>>>>> disable them on this board. And so there should be no size problem.
> >>>>>>>
> >>>>>>> But that direction leads to saying every slight bit of functionality
> >>>>>>> requires a new Kconfig entry.  Some levels of bugfixes as well.
> >>>>>>
> >>>>>> The other option is, we will sink in bloat and suffer endless size problems.
> >>>>>
> >>>>> Yes, it is a hard balancing act.  Stepping back, perhaps a "minimal" or
> >>>>> "complete" choice for USB HID devices would make sense and allow us
> >>>>> further areas to reduce size, on the minimal portion.
> >>>>
> >>>> Or maybe there is a way to help compiler optimize that USB key code
> >>>> handling better.
> >>>
> >>> Perhaps.  But my point is that every little functional change or
> >>> enhancement does not need a Kconfig option.
> >>
> >> Except this leads to slow and steady accumulation of bloat, and as we
> >> already see for quite a while, this is problematic for more and more boards.
> > 
> > And "bloat" and "features" are interchangable terms.
> 
> Nope, bloat is unhelpful growth of size, features are actually
> helpful/useful.
> 
> > I really am trying
> > to be more responsive than ever to size growth in common, rather than
> > board specific areas.  And I agree, some investigation in to ways that
> > might reduce the size of binary support for USB HID devices is good.
> 
> So we agree that's what this series should fix ?
> 
> > Figuring out if we can make this series:
> > http://patchwork.ozlabs.org/project/uboot/list/?series=135448
> > not also increase the overall size, or increase it less, is good.
> > Hiding the content of 2/5 behind a CONFIG option in turn brings us back
> > to "the code is too messy and full of #ifdef" lines.
> 
> Which might be somewhat better than if the code is sprinkled with tiny
> chunks of random pieces of code which are never used, but in total add
> up to a lot of unused code in the binary.

If, with your USB custodian hat on, your answer to Heinrich is that his
changes expose a more fundamental problem with the code that needs
addressing then no, I'm not overriding your objection.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20191122/10714276/attachment.sig>

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

[Marek Vasut]

On 11/22/19 4:44 PM, Tom Rini wrote:
> On Fri, Nov 22, 2019 at 04:58:29AM +0100, Marek Vasut wrote:
>> On 11/22/19 4:41 AM, Tom Rini wrote:
>> [...]
>>>>>>>>>>> I believe
>>>>>>>>>>> the specific changes in question that once again push this board over
>>>>>>>>>>> fall in to that grey area.  Whatever size-trimming the board maintainer
>>>>>>>>>>> is fine with next is fine with me, but needs to get ack'd by someone.
>>>>>>>>>>
>>>>>>>>>> Or, the other option is, make these new extra features configurable and
>>>>>>>>>> disable them on this board. And so there should be no size problem.
>>>>>>>>>
>>>>>>>>> But that direction leads to saying every slight bit of functionality
>>>>>>>>> requires a new Kconfig entry.  Some levels of bugfixes as well.
>>>>>>>>
>>>>>>>> The other option is, we will sink in bloat and suffer endless size problems.
>>>>>>>
>>>>>>> Yes, it is a hard balancing act.  Stepping back, perhaps a "minimal" or
>>>>>>> "complete" choice for USB HID devices would make sense and allow us
>>>>>>> further areas to reduce size, on the minimal portion.
>>>>>>
>>>>>> Or maybe there is a way to help compiler optimize that USB key code
>>>>>> handling better.
>>>>>
>>>>> Perhaps.  But my point is that every little functional change or
>>>>> enhancement does not need a Kconfig option.
>>>>
>>>> Except this leads to slow and steady accumulation of bloat, and as we
>>>> already see for quite a while, this is problematic for more and more boards.
>>>
>>> And "bloat" and "features" are interchangable terms.
>>
>> Nope, bloat is unhelpful growth of size, features are actually
>> helpful/useful.
>>
>>> I really am trying
>>> to be more responsive than ever to size growth in common, rather than
>>> board specific areas.  And I agree, some investigation in to ways that
>>> might reduce the size of binary support for USB HID devices is good.
>>
>> So we agree that's what this series should fix ?
>>
>>> Figuring out if we can make this series:
>>> http://patchwork.ozlabs.org/project/uboot/list/?series=135448
>>> not also increase the overall size, or increase it less, is good.
>>> Hiding the content of 2/5 behind a CONFIG option in turn brings us back
>>> to "the code is too messy and full of #ifdef" lines.
>>
>> Which might be somewhat better than if the code is sprinkled with tiny
>> chunks of random pieces of code which are never used, but in total add
>> up to a lot of unused code in the binary.
> 
> If, with your USB custodian hat on, your answer to Heinrich is that his
> changes expose a more fundamental problem with the code that needs
> addressing then no, I'm not overriding your objection.

The fundamental problem is that we are letting too much bloat in and now
it starts to take over useful functionality on existing devices. I am
strongly opposed to this, that's the fundamental problem we need to deal
with. Heinrichs' approach only underlined the problem.

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

[Stefano Babic]

Hi Everybody,

On 22/11/19 11:29, Soeren Moch wrote:
> 
> 
> On 22.11.19 04:58, Marek Vasut wrote:
>> On 11/22/19 4:41 AM, Tom Rini wrote:
>> [...]
>>>>>>>>>>> I believe
>>>>>>>>>>> the specific changes in question that once again push this board over
>>>>>>>>>>> fall in to that grey area.  Whatever size-trimming the board maintainer
>>>>>>>>>>> is fine with next is fine with me, but needs to get ack'd by someone.
>>>>>>>>>> Or, the other option is, make these new extra features configurable and
>>>>>>>>>> disable them on this board. And so there should be no size problem.
>>>>>>>>> But that direction leads to saying every slight bit of functionality
>>>>>>>>> requires a new Kconfig entry.  Some levels of bugfixes as well.
>>>>>>>> The other option is, we will sink in bloat and suffer endless size problems.
>>>>>>> Yes, it is a hard balancing act.  Stepping back, perhaps a "minimal" or
>>>>>>> "complete" choice for USB HID devices would make sense and allow us
>>>>>>> further areas to reduce size, on the minimal portion.
>>>>>> Or maybe there is a way to help compiler optimize that USB key code
>>>>>> handling better.
>>>>> Perhaps.  But my point is that every little functional change or
>>>>> enhancement does not need a Kconfig option.
>>>> Except this leads to slow and steady accumulation of bloat, and as we
>>>> already see for quite a while, this is problematic for more and more boards.
>>> And "bloat" and "features" are interchangable terms.
>> Nope, bloat is unhelpful growth of size, features are actually
>> helpful/useful.
>>
>>> I really am trying
>>> to be more responsive than ever to size growth in common, rather than
>>> board specific areas.  And I agree, some investigation in to ways that
>>> might reduce the size of binary support for USB HID devices is good.
>> So we agree that's what this series should fix ?
>>
>>> Figuring out if we can make this series:
>>> http://patchwork.ozlabs.org/project/uboot/list/?series=135448
>>> not also increase the overall size, or increase it less, is good.
>>> Hiding the content of 2/5 behind a CONFIG option in turn brings us back
>>> to "the code is too messy and full of #ifdef" lines.
>> Which might be somewhat better than if the code is sprinkled with tiny
>> chunks of random pieces of code which are never used, but in total add
>> up to a lot of unused code in the binary.
> 
> What a long discussion over night, so only a general answer:
> 
> Once upon a time there was plenty of space for tbs2910 u-boot.
> Then we had to convert everything to DM, for whatever reason. This
> increased the binary size a lot, had absolutely no advantage for u-boot
> users, was huge effort for board maintainers, and is still going on.
> (DM_VIDEO conversion still pending for this board, probably more to
> come, DM_SERIAL?). For all that additional space is required, apparently
> nobody tries to cleanup the non-DM code for converted subsystems to
> reclaim some of the space.
> 
> Several times I tried to disable unneeded functions to trim the binary
> size. After a few weeks the gained space was eaten up, apparently nobody
> cares about binary size anymore as long as there is no build failure.
> Even worse, since imx format is padded, people claim to not increase the
> binary size with there patches (what in fact is not true), and then some
> simple change / tool update again breaks everything.
> 
> What is the solution to that? I don't see much what _I_ can do. If I
> find some option to disable again, what is increasingly difficult, then
> this removes the last opportunity for upcoming DM conversions.
> For the "bloat" vs. "features" discussion: on long existing boards no
> user expects new features in defconfig, especially if they only come
> with reduced functionality somewhere else. And as hobbyist board
> maintainer I don't know which features existing users actually use. I
> only get bug reports about bricked boards when something is missing.
> 

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.

Best regards,
Stefano

-- 
=====================================================================
DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sbabic at denx.de
=====================================================================

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

[Anatolij Gustschin]

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

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

[Tom Rini]

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 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <https://lists.denx.de/pipermail/u-boot/attachments/20191206/62f0d4ad/attachment.sig>

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

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