On Wed, 6 Dec 2023 at 13:06, Soeren Moch <sm...@web.de> wrote: > On 05.12.23 21:00, Maxim Uvarov wrote: > > 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? >> > 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.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 >>>>> >>>>> >>> >> >