[U-Boot] SPL size issues on OMAP4

[U-Boot] SPL size issues on OMAP4

[Michael Cashwell]

Greetings,

I've been absent for a while and couldn't find a way to search the list archives so I apologize if this has already been discussed?

I've been fighting the SPL binary growing too large on OMAP4 (using custom configs and features). It's annoying that too large just fails to run with no build or runtime notice. But that's a different issue.

My main issue is that in looking through the map for SPL I've repeatedly found code that I don't need and have a pretty good handle on that. My issue is that code that is compiled but eliminated because it's not called leaves behind all of its anonymous strings ("like this"). In my latest build I have the following sections that are all anonymous strings:

0x4030b638      0x232 arch/arm/cpu/armv7/omap-common/libomap-common.o
0x4030b8b5       0x19 arch/arm/cpu/armv7/omap4/libomap4.o
0x4030b9ad       0xbe common/spl/libspl.o
0x4030ba6b       0x57 drivers/gpio/libgpio.o
0x4030bac2      0x44c drivers/i2c/libi2c.o
0x4030bf0e      0x302 drivers/mmc/libmmc.o
0x4030c27e       0x15 drivers/serial/libserial.o
0x4030c293      0x145 drivers/spi/libspi.o
0x4030c4d8       0x53 lib/libgeneric.o

with more than half being unreferenced. This is a big deal when you only have about 25K of SRAM for code and data.

In searching the web it seems that dead code and data are removed using --gc-sections, -ffunction-sections and -fdata-sections which u-boot is using correctly.

But it seems that gcc puts all anonymous strings into the same section (.rodata or .rodata.str1.1 if string merging is on) which prevents them from participating in the stripping process.

Interestingly, it puts its own __func__ strings into separate sections and they are eliminated if the function go away. It just doesn't do this for plain "" strings.  Grrr.

I was shocked to find gcc posts asking about this more than 13 years ago with barely any traction at all. Given that embarrassing history I'm not hopefully that the gcc folks will ever address this.

Is there a work around I haven't thought of? I'm thinking along the lines of disabling all printfs in SPL in the hope that will take the strings away (since many are some sort of debug / progress message).

Any thoughts or guidance would be appreciated.

-Mike

[U-Boot] SPL size issues on OMAP4

[Tom Rini]

On Thu, Jul 11, 2013 at 01:01:30PM -0400, Michael Cashwell wrote:
> Greetings,
> 
> I've been absent for a while and couldn't find a way to search the
> list archives so I apologize if this has already been discussed?
> 
> I've been fighting the SPL binary growing too large on OMAP4 (using
> custom configs and features). It's annoying that too large just fails
> to run with no build or runtime notice. But that's a different issue.

What version are you using?  When SPL is too large a build-time failure
is expected.

> My main issue is that in looking through the map for SPL I've repeatedly found code that I don't need and have a pretty good handle on that. My issue is that code that is compiled but eliminated because it's not called leaves behind all of its anonymous strings ("like this"). In my latest build I have the following sections that are all anonymous strings:

This is http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54303 which seems to
have gotten little attention after initial triage.  I guess I need to
find a little time to show it's still there.

[snip]
> Is there a work around I haven't thought of? I'm thinking along the
> lines of disabling all printfs in SPL in the hope that will take the
> strings away (since many are some sort of debug / progress message).

One option would be to add a "disable all output" option to SPL that
would get all of the strings dropped.  I'm not sure how cleanly this can
be done, but I know it has been done.

Another option would be to do some careful splitting and #ifdef'ery of
files so that we can just never link in the stuff with strings we don't
need.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20130711/8fd3d228/attachment.pgp>

[U-Boot] SPL size issues on OMAP4

[Michael Cashwell]

On Jul 11, 2013, at 1:29 PM, Tom Rini <trini@ti.com> wrote:

> On Thu, Jul 11, 2013 at 01:01:30PM -0400, Michael Cashwell wrote:
>> I've been absent for a while and couldn't find a way to search the
>> list archives so I apologize if this has already been discussed?
>> 
>> I've been fighting the SPL binary growing too large on OMAP4 (using
>> custom configs and features). It's annoying that too large just fails
>> to run with no build or runtime notice. But that's a different issue.
> 
> What version are you using?  When SPL is too large a build-time failure
> is expected.

I've seen that happen in gross cases where it exceeds the 38K limit in 
omap4_common.h's CONFIG_SPL_MAX_SIZE but I currently have two configs
that are both well below that size yet the larger one doesn't run.

The larger MLO is 0x8a21 bytes (0x8c29 with the GP header) and _end is
0x4030cd74. This loops endlessly at 0x30080. I get no console output.
Even if the additional code is buggy it's not called early enough to
prevent at least the banner from going out so I'm pretty sure it's the
ROM not even starting it.

The smaller MLO is 0x757c bytes (0x7784 with the GP header) and _end is
0x4030b8cc. This runs OK.

I am still exploring.

> This is http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54303 which seems to
> have gotten little attention after initial triage.  I guess I need to
> find a little time to show it's still there.

Yes, I'd seen that. What I don't understand is why gcc doesn't just put
such strings into different sections like it does with its own __func__
strings. Then it would all just work.

I also don't get them implementing anonymous string merging while ignoring
GC. Both are size optimizations and the one they don't seem to care about
I'd expect to produce more savings.

>> Is there a work around I haven't thought of? I'm thinking along the
>> lines of disabling all printfs in SPL in the hope that will take the
>> strings away (since many are some sort of debug / progress message).
> 
> One option would be to add a "disable all output" option to SPL that
> would get all of the strings dropped.  I'm not sure how cleanly this can
> be done, but I know it has been done.

I have a pile of WIP to submit (a tiny one went today). I'm loath to
do anything major that would be unlikely to be accepted upstream because
of the work to keep it clean when I pull.

I'm thinking about a config option for SPL that would define away all
printf() and puts() calls. That would cover most of the low-hanging fruit.
It's not a complete solution and would mean no console output in SPL but
I'd think it could be done with a small source impact. Still noodling.

> Another option would be to do some careful splitting and #ifdef'ery of
> files so that we can just never link in the stuff with strings we don't
> need.

Yes, lacking a toolchain that has any vowels in it's tray I must agree.

-Mike

[U-Boot] SPL size issues on OMAP4

[Michael Trimarchi]

Hi

On 07/12/2013 11:03 PM, Michael Cashwell wrote:
> On Jul 11, 2013, at 1:29 PM, Tom Rini <trini@ti.com> wrote:
> 
>> On Thu, Jul 11, 2013 at 01:01:30PM -0400, Michael Cashwell wrote:
>>> I've been absent for a while and couldn't find a way to search the
>>> list archives so I apologize if this has already been discussed?
>>>
>>> I've been fighting the SPL binary growing too large on OMAP4 (using
>>> custom configs and features). It's annoying that too large just fails
>>> to run with no build or runtime notice. But that's a different issue.
>>
>> What version are you using?  When SPL is too large a build-time failure
>> is expected.
> 
> I've seen that happen in gross cases where it exceeds the 38K limit in 
> omap4_common.h's CONFIG_SPL_MAX_SIZE but I currently have two configs
> that are both well below that size yet the larger one doesn't run.
> 
> The larger MLO is 0x8a21 bytes (0x8c29 with the GP header) and _end is
> 0x4030cd74. This loops endlessly at 0x30080. I get no console output.
> Even if the additional code is buggy it's not called early enough to
> prevent at least the banner from going out so I'm pretty sure it's the
> ROM not even starting it.
> 
> The smaller MLO is 0x757c bytes (0x7784 with the GP header) and _end is
> 0x4030b8cc. This runs OK.
> 
> I am still exploring.
> 

41K Jul 12 15:07 MLO

I have an hybrid booting (serial + eMMC raw) or (sdcard + eMMC raw) both are
working.

Michael

>> This is http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54303 which seems to
>> have gotten little attention after initial triage.  I guess I need to
>> find a little time to show it's still there.
> 
> Yes, I'd seen that. What I don't understand is why gcc doesn't just put
> such strings into different sections like it does with its own __func__
> strings. Then it would all just work.
> 
> I also don't get them implementing anonymous string merging while ignoring
> GC. Both are size optimizations and the one they don't seem to care about
> I'd expect to produce more savings.
> 
>>> Is there a work around I haven't thought of? I'm thinking along the
>>> lines of disabling all printfs in SPL in the hope that will take the
>>> strings away (since many are some sort of debug / progress message).
>>
>> One option would be to add a "disable all output" option to SPL that
>> would get all of the strings dropped.  I'm not sure how cleanly this can
>> be done, but I know it has been done.
> 
> I have a pile of WIP to submit (a tiny one went today). I'm loath to
> do anything major that would be unlikely to be accepted upstream because
> of the work to keep it clean when I pull.
> 
> I'm thinking about a config option for SPL that would define away all
> printf() and puts() calls. That would cover most of the low-hanging fruit.
> It's not a complete solution and would mean no console output in SPL but
> I'd think it could be done with a small source impact. Still noodling.
> 
>> Another option would be to do some careful splitting and #ifdef'ery of
>> files so that we can just never link in the stuff with strings we don't
>> need.
> 
> Yes, lacking a toolchain that has any vowels in it's tray I must agree.
> 
> -Mike
> 
> _______________________________________________
> U-Boot mailing list
> U-Boot at lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot
> 

[U-Boot] SPL size issues on OMAP4

[Michael Trimarchi]

Hi

cc: Mailing List

On 07/11/2013 07:33 PM, Michael Trimarchi wrote:
> Hi Michael
> 
> On 07/11/2013 07:01 PM, Michael Cashwell wrote:
>> Greetings,
>>
>> I've been absent for a while and couldn't find a way to search the list archives so I apologize if this has already been discussed?
>>
>> I've been fighting the SPL binary growing too large on OMAP4 (using custom configs and features). It's annoying that too large just fails to run with no build or runtime notice. But that's a different issue.
>>
>> My main issue is that in looking through the map for SPL I've repeatedly found code that I don't need and have a pretty good handle on that. My issue is that code that is compiled but eliminated because it's not called leaves behind all of its anonymous strings ("like this"). In my latest build I have the following sections that are all anonymous strings:
>>
>> 0x4030b638      0x232 arch/arm/cpu/armv7/omap-common/libomap-common.o
>> 0x4030b8b5       0x19 arch/arm/cpu/armv7/omap4/libomap4.o
>> 0x4030b9ad       0xbe common/spl/libspl.o
>> 0x4030ba6b       0x57 drivers/gpio/libgpio.o
>> 0x4030bac2      0x44c drivers/i2c/libi2c.o
>> 0x4030bf0e      0x302 drivers/mmc/libmmc.o
>> 0x4030c27e       0x15 drivers/serial/libserial.o
>> 0x4030c293      0x145 drivers/spi/libspi.o
>> 0x4030c4d8       0x53 lib/libgeneric.o
>>
>> with more than half being unreferenced. This is a big deal when you only have about 25K of SRAM for code and data.
>>
> 
> I don't give an answer but some suggestions:
> 
> - using a raw partition to boot and remove the vfat support in first stage boot
> - safety you can add 2Kb more to CONFIG_SPL_MAX_SIZE (tested on serial boot too)
> - do some tests on different toolchains
> 
> Try to move all in the second stage when it's possible
> 
> Michael
> 

Michael

>> In searching the web it seems that dead code and data are removed using --gc-sections, -ffunction-sections and -fdata-sections which u-boot is using correctly.
>>
>> But it seems that gcc puts all anonymous strings into the same section (.rodata or .rodata.str1.1 if string merging is on) which prevents them from participating in the stripping process.
>>
>> Interestingly, it puts its own __func__ strings into separate sections and they are eliminated if the function go away. It just doesn't do this for plain "" strings.  Grrr.
>>
>> I was shocked to find gcc posts asking about this more than 13 years ago with barely any traction at all. Given that embarrassing history I'm not hopefully that the gcc folks will ever address this.
>>
>> Is there a work around I haven't thought of? I'm thinking along the lines of disabling all printfs in SPL in the hope that will take the strings away (since many are some sort of debug / progress message).
>>
>> Any thoughts or guidance would be appreciated.
>>
>> -Mike
>>
>> _______________________________________________
>> U-Boot mailing list
>> U-Boot at lists.denx.de
>> http://lists.denx.de/mailman/listinfo/u-boot
>>
>