On 06.12.23 11:40, Maxim Uvarov wrote:
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
<http://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.
Random changes in board configs are usually not helpful. In general
board maintainers know constraints of there boards and required features.
For tbs2910 I already tried hard (with help of Tom and others) to
decrease image size as much as possible. Only in supported network
protocols and features I see possible options for further code space
savings. Since network stacks seem to be your area of expertise, any
hints or proposals to remove something here are welcome. You already
mentioned 'server code' that is probably not required for this board. I
would like to learn more about this.
Regards,
Soeren
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