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