[PATHv11 26/43] configs/tbs2910_defconfig inc limit

Soeren Moch smoch at web.de
Mon Nov 27 22:20:54 CET 2023


On 27.11.23 14:11, Tom Rini wrote:
> On Mon, Nov 27, 2023 at 06:57:09PM +0600, Maxim Uvarov wrote:
>
>> Increase allowed binary size to fit lwip code.
>>
>> Signed-off-by: Maxim Uvarov <maxim.uvarov at linaro.org>
>> ---
>>   configs/tbs2910_defconfig | 2 +-
>>   1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/configs/tbs2910_defconfig b/configs/tbs2910_defconfig
>> index 8fbe84f1d2..ce40efa9ab 100644
>> --- a/configs/tbs2910_defconfig
>> +++ b/configs/tbs2910_defconfig
>> @@ -17,7 +17,7 @@ CONFIG_SYS_MEMTEST_START=0x10000000
>>   CONFIG_SYS_MEMTEST_END=0x2f400000
>>   CONFIG_LTO=y
>>   CONFIG_HAS_BOARD_SIZE_LIMIT=y
>> -CONFIG_BOARD_SIZE_LIMIT=392192
>> +CONFIG_BOARD_SIZE_LIMIT=417792
>>   # CONFIG_BOOTSTD is not set
>>   CONFIG_SUPPORT_RAW_INITRD=y
>>   CONFIG_BOOTDELAY=3
> This is another case where the binary size is a fairly hard limit. You
> forgot to cc the board maintainer here (and I assume the rest of the
> series too) for these config changes.
ThanksTom for sending a notification to me.

Yes, the CONFIG_BOARD_SIZE_LIMIT is a hard limit and this patch in its
current form will break tbs2910 support and even brick the board for
some configurations. So NAK for this patch.
> I think on this platform it's not
> impossible (like it is on am335x where I just replied) but really
> difficult. I'll let Soeren comment on if switching the network stack to
> lwip is the kind of feature enhancement that warrants the pain of
> dealing with the size change here or not.
Network boot is no important feature for this board and not used in
the default boot configuration. But network support always was part
of the config, may be used by some users, and is at least required
to communicate the ethernet address to linux.

So I'm not interested in a new network stack for this board, but
also cannot disable network support completely. This seems to be a
problem for this patch series, since networking support implies LWIP
now.

The question for me is, why is the new network stack consuming so
much space, with only a few enabled commands? Is the whole library
linked in with some unused features (the cover letter mentions much
more than what seems to be used in the converted commands). Or is
the old network stack linked in in parallel to the new one? Can
we save space here?

NFS support in the old networking code is quite big, enabled by default,
and probably still there in parallel to this new lwip library. If there
is really no other option to save space, and lwip in general is agreed
to be the way forward for U-Boot, and only tbs2910 is blocking that,
then from my point of view disabling NFS for tbs2910 could be a way
to stay within the size limit.

Regards,
Soeren



More information about the U-Boot mailing list