* v2013.02.0 phyCORE-OMAP4 MLO to big @ 2013-02-08 15:22 Jan Weitzel 2013-02-11 10:04 ` Sascha Hauer 0 siblings, 1 reply; 5+ messages in thread From: Jan Weitzel @ 2013-02-08 15:22 UTC (permalink / raw) To: barebox 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? Jan _______________________________________________ barebox mailing list barebox@lists.infradead.org http://lists.infradead.org/mailman/listinfo/barebox ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: v2013.02.0 phyCORE-OMAP4 MLO to big 2013-02-08 15:22 v2013.02.0 phyCORE-OMAP4 MLO to big Jan Weitzel @ 2013-02-11 10:04 ` Sascha Hauer [not found] ` <OFC6CD83ED.4FD2D09A-ONC1257B25.0047F4F9-C1257B25.00480A80@phytec.de> 0 siblings, 1 reply; 5+ messages in thread From: Sascha Hauer @ 2013-02-11 10:04 UTC (permalink / raw) To: Jan Weitzel; +Cc: barebox 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? Sascha -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 | Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 | _______________________________________________ barebox mailing list barebox@lists.infradead.org http://lists.infradead.org/mailman/listinfo/barebox ^ permalink raw reply [flat|nested] 5+ messages in thread
[parent not found: <OFC6CD83ED.4FD2D09A-ONC1257B25.0047F4F9-C1257B25.00480A80@phytec.de>]
* Re: Antwort: Re: v2013.02.0 phyCORE-OMAP4 MLO to big [not found] ` <OFC6CD83ED.4FD2D09A-ONC1257B25.0047F4F9-C1257B25.00480A80@phytec.de> @ 2013-03-05 13:30 ` Jürgen 2013-03-07 8:18 ` Sascha Hauer 0 siblings, 1 reply; 5+ messages in thread From: Jürgen @ 2013-03-05 13:30 UTC (permalink / raw) To: barebox 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@lists.infradead.org http://lists.infradead.org/mailman/listinfo/barebox ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Antwort: Re: v2013.02.0 phyCORE-OMAP4 MLO to big 2013-03-05 13:30 ` Antwort: " Jürgen @ 2013-03-07 8:18 ` Sascha Hauer 2013-03-07 11:19 ` Jean-Christophe PLAGNIOL-VILLARD 0 siblings, 1 reply; 5+ messages in thread From: Sascha Hauer @ 2013-03-07 8:18 UTC (permalink / raw) To: Jürgen; +Cc: barebox Hi Jürgen, On Tue, Mar 05, 2013 at 02:30:22PM +0100, Jürgen wrote: > 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 This won't help you directly. What you could do with this is: - generate a compressed image using PBL support - The PBL is loaded to SRAM by the ROM, relocated to the current address in SRAM - extracts the binary to SDRAM - continues executing in SDRAM. Thinking about it it should work. The other thing you could do is making the bss segment smaller. For ARM we initialize the malloc space before the initcalls are starting which means that malloc can be used in every initcall. This in turn means that we can allocate the files array and the gpio_desc array dynamically. You would have to move the malloc initialization from initcalls to early init for the other architectures though to make this work. Sascha -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 | Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 | _______________________________________________ barebox mailing list barebox@lists.infradead.org http://lists.infradead.org/mailman/listinfo/barebox ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Antwort: Re: v2013.02.0 phyCORE-OMAP4 MLO to big 2013-03-07 8:18 ` Sascha Hauer @ 2013-03-07 11:19 ` Jean-Christophe PLAGNIOL-VILLARD 0 siblings, 0 replies; 5+ messages in thread From: Jean-Christophe PLAGNIOL-VILLARD @ 2013-03-07 11:19 UTC (permalink / raw) To: Sascha Hauer; +Cc: barebox On 09:18 Thu 07 Mar , Sascha Hauer wrote: > Hi Jürgen, > > On Tue, Mar 05, 2013 at 02:30:22PM +0100, Jürgen wrote: > > 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 > > This won't help you directly. What you could do with this is: > - generate a compressed image using PBL support > - The PBL is loaded to SRAM by the ROM, relocated to the current > address in SRAM > - extracts the binary to SDRAM > - continues executing in SDRAM. this is what we do for the bootstrap on at91 so the pbl setup the sdram and decompress it in sdram and jump in it also try the patch I send to switch the xloader to the generic bootstrap this decrease the size of the binary > > Thinking about it it should work. > > The other thing you could do is making the bss segment smaller. > > For ARM we initialize the malloc space before the initcalls are > starting which means that malloc can be used in every initcall. > This in turn means that we can allocate the files array and the > gpio_desc array dynamically. > You would have to move the malloc initialization from initcalls > to early init for the other architectures though to make this > work. > > Sascha > > -- > Pengutronix e.K. | | > Industrial Linux Solutions | http://www.pengutronix.de/ | > Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 | > Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 | > > _______________________________________________ > barebox mailing list > barebox@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/barebox _______________________________________________ barebox mailing list barebox@lists.infradead.org http://lists.infradead.org/mailman/listinfo/barebox ^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2013-03-07 11:23 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2013-02-08 15:22 v2013.02.0 phyCORE-OMAP4 MLO to big Jan Weitzel
2013-02-11 10:04 ` Sascha Hauer
[not found] ` <OFC6CD83ED.4FD2D09A-ONC1257B25.0047F4F9-C1257B25.00480A80@phytec.de>
2013-03-05 13:30 ` Antwort: " Jürgen
2013-03-07 8:18 ` Sascha Hauer
2013-03-07 11:19 ` Jean-Christophe PLAGNIOL-VILLARD
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox