[PATHv11 26/43] configs/tbs2910_defconfig inc limit

[Maxim Uvarov]

On Wed, 6 Dec 2023 at 00:25, Soeren Moch <smoch at web.de> wrote:

>
>
> On 05.12.23 17:25, Maxim Uvarov wrote:
>
>
>
> On Tue, 5 Dec 2023 at 21:49, Soeren Moch <smoch at 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 at 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 at linaro.org>
>> wrote:
>>
>>>
>>>
>>> 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
>>>>
>>>>
>>
>