[PATHv11 26/43] configs/tbs2910_defconfig inc limit

[Maxim Uvarov]

On Tue, 28 Nov 2023 at 03:20, Soeren Moch <smoch at web.de> wrote:

> 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.
>
>
Thanks Soeren for the explanation. Then yes, something more advanced is
needed
to be done here.



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

Yes, the old code is still there. I decided to not touch it for the first
integration (arp.o, bootp.o, ping.o and
mostly all from net/Makefile).  Those files also have reference code in
net/net.c. Not compiling
and not linking this code will save some space, but It's larger than the
current version.
Like for EVM SPL code with usb+net+ext4 and etc have very minimal space for
network stack.
I will take a look at this more closely...


>
> 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.
>
> ok. I think that by default we need something very minimal (dhcp, tftp),
probably ping is even not needed.



> Regards,
> Soeren
>
>