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
_______________________________________________
barebox mailing list
barebox@xxxxxxxxxxxxxxxxxxx
http://lists.infradead.org/mailman/listinfo/barebox
