[PATHv11 26/43] configs/tbs2910_defconfig inc limit

Wed Dec 6 11:40:24 CET 2023

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

> On 05.12.23 21:00, Maxim Uvarov wrote:
>
> 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?
>>
> 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 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?
>
> 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 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
>>>>>
>>>>>
>>>
>>
>