On Tue, 28 Nov 2023 at 03:20, Soeren Moch <sm...@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.uva...@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 > >