[PATHv11 26/43] configs/tbs2910_defconfig inc limit

[Maxim Uvarov]

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 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
>>
>>