| Message ID | 20231127125726.3735-27-maxim.uvarov@linaro.org |
|---|---|
| State | New |
| Headers | show |
| Series | net/lwip: add lwip library for the network stack | expand |
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@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. 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.
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@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
On Tue, 28 Nov 2023 at 03:20, Soeren Moch <smoch@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@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 > >
I think I solved the size issue on all the boards. Key changes: 1. remove compilation of original ping.c and tftp.c (tftp had also server code, so I will partially bring it back.) 2. LTO=y 3. CONFIG_LOGLEVEL=3 instead of 4. 4. CONFIG_CMD_DATE is not set 5. CONFIG_CMD_LICENSE is not set 6. CONFIG_CMD_PING (if 1-6 did not help). And these changes were enough for CI tagrets to build. I also tested that Raspberry PI 4B works fine (dhcp, ping). Looking for other boards to test. For example for this tbs2910 board changes are: --- a/configs/tbs2910_defconfig +++ b/configs/tbs2910_defconfig @@ -18,6 +18,7 @@ CONFIG_SYS_MEMTEST_END=0x2f400000 CONFIG_LTO=y CONFIG_HAS_BOARD_SIZE_LIMIT=y CONFIG_BOARD_SIZE_LIMIT=392192 +CONFIG_TIMESTAMP=y (this was added by savedefconfig) # CONFIG_BOOTSTD is not set CONFIG_SUPPORT_RAW_INITRD=y CONFIG_BOOTDELAY=3 @@ -26,6 +27,7 @@ CONFIG_BOOTCOMMAND="mmc rescan; if run bootcmd_up1; then run bootcmd_up2; else r CONFIG_USE_PREBOOT=y CONFIG_PREBOOT="echo PCI:; pci enum; pci 1; usb start" CONFIG_DEFAULT_FDT_FILE="imx6q-tbs2910.dtb" +CONFIG_LOGLEVEL=3 CONFIG_PRE_CONSOLE_BUFFER=y CONFIG_HUSH_PARSER=y CONFIG_SYS_PROMPT="Matrix U-Boot> " @@ -52,7 +54,7 @@ CONFIG_CMD_DHCP=y CONFIG_CMD_MII=y CONFIG_CMD_PING=y CONFIG_CMD_CACHE=y -CONFIG_CMD_TIME=y +# CONFIG_CMD_DATE is not set CONFIG_CMD_SYSBOOT=y # CONFIG_CMD_VIDCONSOLE is not set CONFIG_CMD_EXT2=y BR, Maxim. On Tue, 28 Nov 2023 at 13:09, Maxim Uvarov <maxim.uvarov@linaro.org> wrote: > > > On Tue, 28 Nov 2023 at 03:20, Soeren Moch <smoch@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@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 >> >>
On Tue, 5 Dec 2023 at 21:49, Soeren Moch <smoch@web.de> wrote: > On 05.12.23 14:15, Maxim Uvarov wrote: > > I think I solved the size issue on all the boards. > > Key changes: > 1. remove compilation of original ping.c and tftp.c (tftp had also server > code, so I will partially bring it back.) > > Interesting. > @Tom: Is there other server code in u-boot, that is enabled by default > (and can be used to reclaim code space)? > Fur sure I do not need u-boot to act as server for tftp (maye nfs, others). > Maybe I need to be more clear about this. reference to code from tftp.c and ping.c exist in net.c, test/image/spl_load_net.c, test.dm/dsa.c, test/dm/eth.c. And even if that code is not used (replaced with lwip calls to the same commands in my case) it adds additional size. Even enabled LTO does not see direct difference. > 2. LTO=y > 3. CONFIG_LOGLEVEL=3 instead of 4. > 4. CONFIG_CMD_DATE is not set > 5. CONFIG_CMD_LICENSE is not set > 6. CONFIG_CMD_PING (if 1-6 did not help). > > And these changes were enough for CI tagrets to build. > I also tested that Raspberry PI 4B works fine (dhcp, ping). Looking for > other boards to test. > > For example for this tbs2910 board changes are: > > Disabling CMD_DATE is unfortunate. This can help to debug RTC problems > (already used it for this purpose). > And, if we are that close to the size limit, than maybe we can get away > for this series, but for sure will run into trouble for every other small > change to u-boot core/driver code. > > Regards, > Soeren > The problem is that for many targets the limit is 1MB. U-Boot in some minimal configuration is about 500kb. But U-boot with EFI, USB, Eth drivers, MMC, RTC, and all the commands is 900+ kb and very close to 1MB. Most of the new features are enabled by default. I.e. they do not exist in _defconfig and appear in the resulting .config automatically. I would say that for some small targets things like EFI, Secure boot, TPM, Updates and many others are not needed. But if new features will appear by default very soon we will see limits. BR, Maxim. > > --- a/configs/tbs2910_defconfig > +++ b/configs/tbs2910_defconfig > @@ -18,6 +18,7 @@ CONFIG_SYS_MEMTEST_END=0x2f400000 > CONFIG_LTO=y > CONFIG_HAS_BOARD_SIZE_LIMIT=y > CONFIG_BOARD_SIZE_LIMIT=392192 > +CONFIG_TIMESTAMP=y (this was added by savedefconfig) > # CONFIG_BOOTSTD is not set > CONFIG_SUPPORT_RAW_INITRD=y > CONFIG_BOOTDELAY=3 > @@ -26,6 +27,7 @@ CONFIG_BOOTCOMMAND="mmc rescan; if run bootcmd_up1; then > run bootcmd_up2; else r > CONFIG_USE_PREBOOT=y > CONFIG_PREBOOT="echo PCI:; pci enum; pci 1; usb start" > CONFIG_DEFAULT_FDT_FILE="imx6q-tbs2910.dtb" > +CONFIG_LOGLEVEL=3 > CONFIG_PRE_CONSOLE_BUFFER=y > CONFIG_HUSH_PARSER=y > CONFIG_SYS_PROMPT="Matrix U-Boot> " > @@ -52,7 +54,7 @@ CONFIG_CMD_DHCP=y > CONFIG_CMD_MII=y > CONFIG_CMD_PING=y > CONFIG_CMD_CACHE=y > -CONFIG_CMD_TIME=y > +# CONFIG_CMD_DATE is not set > CONFIG_CMD_SYSBOOT=y > # CONFIG_CMD_VIDCONSOLE is not set > CONFIG_CMD_EXT2=y > > BR, > Maxim. > > > On Tue, 28 Nov 2023 at 13:09, Maxim Uvarov <maxim.uvarov@linaro.org> > wrote: > >> >> >> On Tue, 28 Nov 2023 at 03:20, Soeren Moch <smoch@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@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 >>> >>> >
On Wed, 6 Dec 2023 at 00:25, Soeren Moch <smoch@web.de> wrote: > > > On 05.12.23 17:25, Maxim Uvarov wrote: > > > > On Tue, 5 Dec 2023 at 21:49, Soeren Moch <smoch@web.de> wrote: > >> On 05.12.23 14:15, Maxim Uvarov wrote: >> >> I think I solved the size issue on all the boards. >> >> Key changes: >> 1. remove compilation of original ping.c and tftp.c (tftp had also server >> code, so I will partially bring it back.) >> >> Interesting. >> @Tom: Is there other server code in u-boot, that is enabled by default >> (and can be used to reclaim code space)? >> Fur sure I do not need u-boot to act as server for tftp (maye nfs, >> others). >> > > Maybe I need to be more clear about this. reference to code from tftp.c > and ping.c exist in net.c, test/image/spl_load_net.c, test.dm/dsa.c, > test/dm/eth.c. > And even if that code is not used (replaced with lwip calls to the same > commands in my case) it adds additional size. Even enabled LTO does not see > direct difference. > > So 'server code' does not mean u-boot acting as network server, you mean > this code is referenced by something else? And things in test do increase > image size? > > > > >> 2. LTO=y >> 3. CONFIG_LOGLEVEL=3 instead of 4. >> 4. CONFIG_CMD_DATE is not set >> 5. CONFIG_CMD_LICENSE is not set >> 6. CONFIG_CMD_PING (if 1-6 did not help). >> >> And these changes were enough for CI tagrets to build. >> I also tested that Raspberry PI 4B works fine (dhcp, ping). Looking for >> other boards to test. >> >> For example for this tbs2910 board changes are: >> >> Disabling CMD_DATE is unfortunate. This can help to debug RTC problems >> (already used it for this purpose). >> And, if we are that close to the size limit, than maybe we can get away >> for this series, but for sure will run into trouble for every other small >> change to u-boot core/driver code. >> >> Regards, >> Soeren >> > > The problem is that for many targets the limit is 1MB. > > For tbs2910 it is 383kBytes. And there was plenty of free space when I > introduced mainline u-boot support. But yes, space got tighter over time. > Hm, orig: -rw-r--r-- 1 uboot uboot 371K Dec 5 19:54 u-boot.bin lwip: -rw-r--r-- 1 uboot uboot 380K Dec 5 19:55 u-boot.bin Then if I just enable CMD_DATE: u-boot.imx exceeds file size limit: limit: 0x5fc00 bytes actual: 0x60c00 bytes excess: 0x1000 bytes make: *** [Makefile:1240: u-boot.imx] Error 1 make: *** Deleting file 'u-boot.imx' uboot@3eebd85985c8:~/uboot-size$ ls -lh u-boot.bin -rw-r--r-- 1 uboot uboot 382K Dec 5 19:58 u-boot.bin So limit for your board is: (gdb) p 0x5fc00/1024 $1 = 383 383k. Where do you see the space? BR, Maxim. > U-Boot in some minimal configuration is about 500kb. But U-boot with EFI, > USB, Eth drivers, MMC, RTC, and all the commands is 900+ kb and very close > to 1MB. Most of the new features are enabled by default. > > No. Tom does a very good job to ensure that there is no (not much) > additional space required for unrelated boards that do not need new > features. > > I.e. they do not exist in _defconfig and appear in the resulting .config > automatically. I would say that for some small targets things like EFI, > Secure boot, TPM, Updates and many others are not needed. But if new > features will appear by default very soon we will see limits. > > New features will not be enabled for old space constrained boards. In your > series you did not offer to keep the old implementation instead, this is > different and the reason why we discuss image size constraints. > > Regards, > Soeren > > > BR, > Maxim. > >> >> --- a/configs/tbs2910_defconfig >> +++ b/configs/tbs2910_defconfig >> @@ -18,6 +18,7 @@ CONFIG_SYS_MEMTEST_END=0x2f400000 >> CONFIG_LTO=y >> CONFIG_HAS_BOARD_SIZE_LIMIT=y >> CONFIG_BOARD_SIZE_LIMIT=392192 >> +CONFIG_TIMESTAMP=y (this was added by savedefconfig) >> # CONFIG_BOOTSTD is not set >> CONFIG_SUPPORT_RAW_INITRD=y >> CONFIG_BOOTDELAY=3 >> @@ -26,6 +27,7 @@ CONFIG_BOOTCOMMAND="mmc rescan; if run bootcmd_up1; >> then run bootcmd_up2; else r >> CONFIG_USE_PREBOOT=y >> CONFIG_PREBOOT="echo PCI:; pci enum; pci 1; usb start" >> CONFIG_DEFAULT_FDT_FILE="imx6q-tbs2910.dtb" >> +CONFIG_LOGLEVEL=3 >> CONFIG_PRE_CONSOLE_BUFFER=y >> CONFIG_HUSH_PARSER=y >> CONFIG_SYS_PROMPT="Matrix U-Boot> " >> @@ -52,7 +54,7 @@ CONFIG_CMD_DHCP=y >> CONFIG_CMD_MII=y >> CONFIG_CMD_PING=y >> CONFIG_CMD_CACHE=y >> -CONFIG_CMD_TIME=y >> +# CONFIG_CMD_DATE is not set >> CONFIG_CMD_SYSBOOT=y >> # CONFIG_CMD_VIDCONSOLE is not set >> CONFIG_CMD_EXT2=y >> >> BR, >> Maxim. >> >> >> On Tue, 28 Nov 2023 at 13:09, Maxim Uvarov <maxim.uvarov@linaro.org> >> wrote: >> >>> >>> >>> On Tue, 28 Nov 2023 at 03:20, Soeren Moch <smoch@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@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 >>>> >>>> >> >
On Wed, 6 Dec 2023 at 13:06, Soeren Moch <smoch@web.de> wrote: > On 05.12.23 21:00, Maxim Uvarov wrote: > > On Wed, 6 Dec 2023 at 00:25, Soeren Moch <smoch@web.de> wrote: > >> On 05.12.23 17:25, Maxim Uvarov wrote: >> >> On Tue, 5 Dec 2023 at 21:49, Soeren Moch <smoch@web.de> wrote: >> >>> On 05.12.23 14:15, Maxim Uvarov wrote: >>> >>> I think I solved the size issue on all the boards. >>> >>> Key changes: >>> 1. remove compilation of original ping.c and tftp.c (tftp had also >>> server code, so I will partially bring it back.) >>> >>> Interesting. >>> @Tom: Is there other server code in u-boot, that is enabled by default >>> (and can be used to reclaim code space)? >>> Fur sure I do not need u-boot to act as server for tftp (maye nfs, >>> others). >>> >> >> Maybe I need to be more clear about this. reference to code from tftp.c >> and ping.c exist in net.c, test/image/spl_load_net.c, test.dm/dsa.c, >> test/dm/eth.c. >> And even if that code is not used (replaced with lwip calls to the same >> commands in my case) it adds additional size. Even enabled LTO does not see >> direct difference. >> >> So 'server code' does not mean u-boot acting as network server, you mean >> this code is referenced by something else? And things in test do increase >> image size? >> > This was my question to understand possible options to save space. > > >> >> >>> 2. LTO=y >>> 3. CONFIG_LOGLEVEL=3 instead of 4. >>> 4. CONFIG_CMD_DATE is not set >>> 5. CONFIG_CMD_LICENSE is not set >>> 6. CONFIG_CMD_PING (if 1-6 did not help). >>> >>> And these changes were enough for CI tagrets to build. >>> I also tested that Raspberry PI 4B works fine (dhcp, ping). Looking for >>> other boards to test. >>> >>> For example for this tbs2910 board changes are: >>> >>> Disabling CMD_DATE is unfortunate. This can help to debug RTC problems >>> (already used it for this purpose). >>> And, if we are that close to the size limit, than maybe we can get away >>> for this series, but for sure will run into trouble for every other small >>> change to u-boot core/driver code. >>> >>> Regards, >>> Soeren >>> >> >> The problem is that for many targets the limit is 1MB. >> >> For tbs2910 it is 383kBytes. And there was plenty of free space when I >> introduced mainline u-boot support. But yes, space got tighter over time. >> > > Hm, > orig: > -rw-r--r-- 1 uboot uboot 371K Dec 5 19:54 u-boot.bin > lwip: > -rw-r--r-- 1 uboot uboot 380K Dec 5 19:55 u-boot.bin > > Then if I just enable CMD_DATE: > u-boot.imx exceeds file size limit: > limit: 0x5fc00 bytes > actual: 0x60c00 bytes > excess: 0x1000 bytes > make: *** [Makefile:1240: u-boot.imx] Error 1 > make: *** Deleting file 'u-boot.imx' > uboot@3eebd85985c8:~/uboot-size$ ls -lh u-boot.bin > -rw-r--r-- 1 uboot uboot 382K Dec 5 19:58 u-boot.bin > > So limit for your board is: > (gdb) p 0x5fc00/1024 > $1 = 383 > > 383k. Where do you see the space? > > Here I do not understand what you want to ask. > > As I wrote earlier, yes, tbs2910 limit is 383k, for u-boot.imx, the number > you tried to change in this patch to 408k, but this change is not possible. > > Without your changes there is some space left (not as much as 2014 when I > introduced tbs2910 support in u-boot), but enough to make further u-boot > development with unavoidable small image size increases possible. (size of > v2024.01-rc4 u-boot.imx for tbs2910 is 375k). > > Regards, > Soeren > Soeren, this patch which changes the limit will not be applied. I will send another patch which modies defconfig and makes room for lwip stack. If you want to keep CMD_DATE that is fine, probably we can disable EFI for this board or something else. BR, Maxim. > > BR, > Maxim. > > > >> U-Boot in some minimal configuration is about 500kb. But U-boot with EFI, >> USB, Eth drivers, MMC, RTC, and all the commands is 900+ kb and very close >> to 1MB. Most of the new features are enabled by default. >> >> No. Tom does a very good job to ensure that there is no (not much) >> additional space required for unrelated boards that do not need new >> features. >> >> I.e. they do not exist in _defconfig and appear in the resulting .config >> automatically. I would say that for some small targets things like EFI, >> Secure boot, TPM, Updates and many others are not needed. But if new >> features will appear by default very soon we will see limits. >> >> New features will not be enabled for old space constrained boards. In >> your series you did not offer to keep the old implementation instead, this >> is different and the reason why we discuss image size constraints. >> >> Regards, >> Soeren >> >> >> BR, >> Maxim. >> >>> >>> --- a/configs/tbs2910_defconfig >>> +++ b/configs/tbs2910_defconfig >>> @@ -18,6 +18,7 @@ CONFIG_SYS_MEMTEST_END=0x2f400000 >>> CONFIG_LTO=y >>> CONFIG_HAS_BOARD_SIZE_LIMIT=y >>> CONFIG_BOARD_SIZE_LIMIT=392192 >>> +CONFIG_TIMESTAMP=y (this was added by savedefconfig) >>> # CONFIG_BOOTSTD is not set >>> CONFIG_SUPPORT_RAW_INITRD=y >>> CONFIG_BOOTDELAY=3 >>> @@ -26,6 +27,7 @@ CONFIG_BOOTCOMMAND="mmc rescan; if run bootcmd_up1; >>> then run bootcmd_up2; else r >>> CONFIG_USE_PREBOOT=y >>> CONFIG_PREBOOT="echo PCI:; pci enum; pci 1; usb start" >>> CONFIG_DEFAULT_FDT_FILE="imx6q-tbs2910.dtb" >>> +CONFIG_LOGLEVEL=3 >>> CONFIG_PRE_CONSOLE_BUFFER=y >>> CONFIG_HUSH_PARSER=y >>> CONFIG_SYS_PROMPT="Matrix U-Boot> " >>> @@ -52,7 +54,7 @@ CONFIG_CMD_DHCP=y >>> CONFIG_CMD_MII=y >>> CONFIG_CMD_PING=y >>> CONFIG_CMD_CACHE=y >>> -CONFIG_CMD_TIME=y >>> +# CONFIG_CMD_DATE is not set >>> CONFIG_CMD_SYSBOOT=y >>> # CONFIG_CMD_VIDCONSOLE is not set >>> CONFIG_CMD_EXT2=y >>> >>> BR, >>> Maxim. >>> >>> >>> On Tue, 28 Nov 2023 at 13:09, Maxim Uvarov <maxim.uvarov@linaro.org> >>> wrote: >>> >>>> >>>> >>>> On Tue, 28 Nov 2023 at 03:20, Soeren Moch <smoch@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@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 >>>>> >>>>> >>> >> >
On Tue, Dec 05, 2023 at 04:49:47PM +0100, Soeren Moch wrote: > On 05.12.23 14:15, Maxim Uvarov wrote: > > I think I solved the size issue on all the boards. > > > > Key changes: > > 1. remove compilation of original ping.c and tftp.c (tftp had also > > server code, so I will partially bring it back.) > Interesting. > @Tom: Is there other server code in u-boot, that is enabled by default > (and can be used to reclaim code space)? > Fur sure I do not need u-boot to act as server for tftp (maye nfs, others). Note that we disabled NFS for everyone recently (I think it will be default off in v2024.01), and CMD_TFTPSRV isn't enabled by default for anyone. At this point, anything which could have an impact on size should be in Kconfig so examining the whole .config file might give other suggestions on what could be disabled for size. > > 2. LTO=y > > 3. CONFIG_LOGLEVEL=3 instead of 4. > > 4. CONFIG_CMD_DATE is not set > > 5. CONFIG_CMD_LICENSE is not set > > 6. CONFIG_CMD_PING (if 1-6 did not help). > > > > And these changes were enough for CI tagrets to build. > > I also tested that Raspberry PI 4B works fine (dhcp, ping). Looking > > for other boards to test. > > > > For example for this tbs2910 board changes are: > Disabling CMD_DATE is unfortunate. This can help to debug RTC problems > (already used it for this purpose). > And, if we are that close to the size limit, than maybe we can get away > for this series, but for sure will run into trouble for every other > small change to u-boot core/driver code. In general, I would suggest disabling CMD_LICENSE before disabling CMD_DATE as well. But I see that's already done here. The same would be with CONFIG_BOOTM_VXWORKS, but that's also off here. Maybe disable the memtest command? It's not that good of a tester as it is. Or maybe CONFIG_MMC_VERBOSE=y can be turned off?
On Tue, Dec 05, 2023 at 07:25:15PM +0100, Soeren Moch wrote: > > > On 05.12.23 17:25, Maxim Uvarov wrote: [snip] > > The problem is that for many targets the limit is 1MB. > For tbs2910 it is 383kBytes. And there was plenty of free space when I > introduced mainline u-boot support. But yes, space got tighter over time. And I do not want to say "minimum flash size for U-Boot is 1MB", either. Nor 512kB. We're never going to be as tiny as we used to be, but I will be unhappy if we can't keep something like tbs2910 and a limit of almost-384kB functional and useful. > > U-Boot in some minimal configuration is about 500kb. But U-boot with > > EFI, USB, Eth drivers, MMC, RTC, and all the commands is 900+ kb and > > very close to 1MB. Most of the new features are enabled by default. > No. Tom does a very good job to ensure that there is no (not much) > additional space required for unrelated boards that do not need new > features. > > I.e. they do not exist in _defconfig and appear in the resulting > > .config automatically. I would say that for some small targets things > > like EFI, Secure boot, TPM, Updates and many others are not needed. > > But if new features will appear by default very soon we will see limits. > New features will not be enabled for old space constrained boards. In > your series you did not offer to keep the old implementation instead, > this is different and the reason why we discuss image size constraints. So here is where things get tricky. I _really_ don't want to have two network stacks. And one of the remarks I believe you had made years ago Soeren was along the lines of "why does my platform need this new stuff?" to which I think this time, I have a good answer. Our homegrown networking stack is fragile and difficult to maintain. lwIP is well maintained and also open to feedback / improvements from U-Boot to make it more configurable (so, trimmed down further in size). So I really do want to replace our stack with something with better long term maintenance and less bugs, while not growing things too much either. And to that end, we aren't there just yet with lwIP merging in either. We're getting better than earlier iterations. And we will have old-or-new as at least a build time option for a few releases so it might be the case that we allow the new stack to come in with a note that it won't become the default stack until the final sets of size issues / functional configurability is done.
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
Increase allowed binary size to fit lwip code. Signed-off-by: Maxim Uvarov <maxim.uvarov@linaro.org> --- configs/tbs2910_defconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)