[U-Boot] SPL size issues on OMAP4

[Michael Trimarchi <michael@amarulasolutions.com>]

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
>