Antwort: Re: v2013.02.0 phyCORE-OMAP4 MLO to big

[Jürgen]

On 11.02.2013 Sascha Hauer wrote:
> On Fri, Feb 08, 2013 at 04:22:09PM +0100, Jan Weitzel wrote:
>> Hi,
>> with the release v2013.02.0 the MLO gets so bit, that it eats the boot
>> information in the SRAM.
>>
>> nm --size-sort
>>
>> ...
>> 00000630 D nand_flash_ids
>> 000008c0 t mci_probe
>> 00000c00 b gpio_desc
>> 00001400 b files
>>
>> If I remove  GPIOLIB from MLO it work again. Maybe setting MAX_FILES
>> down or find a dynamic way for the big arrays is a better solution.
>> Any Ideas?
> Could you link the MLO to SDRAM instead?
Hi Sascha, we have tried as you suggested and it doesn't work without 
changes...

We found two things:

1.) There is early code which is not relocatable.

We solved this by adding -fPIC to the CPPFLAGS.
But I think, this is also solved with your patch 
http://lists.infradead.org/pipermail/barebox/2013-March/013366.html

2.) The TEXTBASE is passed to the signGP tool, which is wrong if
       TEXT_BASE is different from the executing address before relocating.
       In our case TEXT_BASE would be 0x86000000 but the MLO is executed 

in internal SRAM at 0x40300000.

So I would suggest to create a config option like OMAP_IFT_BASE which 
can be passed to the signGP tool and is set to 0x40300000 per default..

What do you think?

Jürgen