From: Sascha Hauer <s.hauer@pengutronix.de>
To: Jürgen <J.Kilb@phytec.de>
Cc: barebox@lists.infradead.org
Subject: Re: Antwort: Re: v2013.02.0 phyCORE-OMAP4 MLO to big
Date: Thu, 7 Mar 2013 09:18:59 +0100 [thread overview]
Message-ID: <20130307081859.GT1906@pengutronix.de> (raw)
In-Reply-To: <5135F36E.2090401@phytec.de>
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
next prev parent reply other threads:[~2013-03-07 8:19 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-02-08 15:22 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 [this message]
2013-03-07 11:19 ` Jean-Christophe PLAGNIOL-VILLARD
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20130307081859.GT1906@pengutronix.de \
--to=s.hauer@pengutronix.de \
--cc=J.Kilb@phytec.de \
--cc=barebox@lists.infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox