On Wed, 6 Dec 2023 at 00:25, Soeren Moch <sm...@web.de> wrote: > > > On 05.12.23 17:25, Maxim Uvarov wrote: > > > > On Tue, 5 Dec 2023 at 21:49, Soeren Moch <sm...@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.uva...@linaro.org> >> wrote: >> >>> >>> >>> 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 >>>> >>>> >> >