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

Marek Vasut
2019-11-22T00:23:56Z

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.