From: Albert ARIBAUD <albert.aribaud@free.fr>
To: u-boot@lists.denx.de
Subject: [U-Boot] [RFC] ARM: mx31pdk: Use the new relocation scheme
Date: Fri, 11 Feb 2011 13:46:05 +0100 [thread overview]
Message-ID: <4D552F8D.5020200@free.fr> (raw)
In-Reply-To: <4D5514BF.2080906@ti.com>
Le 11/02/2011 11:51, Aneesh V a ?crit :
> Hi Albert,
>
> On Wednesday 09 February 2011 02:20 AM, Albert ARIBAUD wrote:
>> Le 08/02/2011 21:18, stefano babic a ?crit :
>>> Am 08.02.2011 20:26, schrieb Magnus Lilja:
>>>> Patch reposted as a separate mail a couple of minutes ago.
>>>>
>>>> As I mention in the patch I think Fabio's patch has to be applied
>>>> first.
>>>
>>> I think your patch is ok - Fabio fixed the syntax error as you do. We
>>> need only one of them.
>>>
>>>> Another solution would be to change my patch somewhat to apply it first
>>>> and then update Fabios patch to only touch the i.MX31-PDK specific
>>>> files.
>>>
>>> IMHO this is the preferred way, because the two issues are orthogonal.
>>> Your patch fixes booting from NAND for ARM11, and Fabio's patch fix the
>>> mx31pdk board only.
>>
>> Agreed.
>>
>> Note also that there was a recent patch to ARM926's start.S (replacing
>> 'adr r1, _start' with 'ldr r1, _TEXT_BASE' at line 284). The same should
>> be done on arm1136.
>
> Is this going to happen for armv7 too? What is the real reason behind
> this proposal. What is the case when _start is not same as _TEXT_BASE(I
> looked at the archives but couldn't filter out the original discussion
> on this)
The difference is that _TEXT_BASE always contains the link-time address
of _start, whereas references to _start may contain a different value if
the code is executed somewhere else than at the link-time address.
/Normally/, u-boot should always execute first at the link-time address
-- that's a base constraint.
/But/ this change makes it more resilient to out-of-link-time-address
execution, and I want, at some time in the future, to find a way for
u-boot to be able to start anywhere -- within reasonable limits:
anywhere in NOR for a NOR-based U-boot, anywhere in RAM for a RAM-based
U-boot, but I am not talking about a generic,
run-in-RAM-or-NOR-or-anywhere, binary.
Yet. :)
> I see a problem with that. _TEXT_BASE is based on
> CONFIG_SYS_TEXT_BASE. In our SPL's case CONFIG_SYS_TEXT_BASE indicates
> the TEXT_BASE for u-boot and *CONFIG_SYS_SPL_TEXT_BASE* indicates the
> TEXT_BASE for SPL. Both are defined and useful in SPL because one is
> used for linking SPL while the other is used while loading u-boot from
> MMC. So, CONFIG_SYS_TEXT_BASE used in the start.S of SPL will not be
> correct.
The change I indicate is under the #else of a #ifdef CONFIG_NAND_SPL, so
it will not apply to SPL. Does that still cause an issue with armv7?
> In the worst case we need to define yet another label in the linker
> scripts like __text_base. But I was wondering if we could maintain the
> status quo for armv7: that is 'adr r1, _start'
As long as you run the u-boot start code at the link-time address, there
will be no difference except the code is more correct with respect to
what it should do; and if you run it elsewhere, which you should not,
you have slightly better chances that it manages to survive.
> Best regards,
> Aneesh
Amicalement,
--
Albert.
next prev parent reply other threads:[~2011-02-11 12:46 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-01-12 12:49 [U-Boot] [RFC] ARM: mx31pdk: Use the new relocation scheme Fabio Estevam
2011-01-13 13:38 ` Stefano Babic
2011-01-14 18:33 ` Fabio Estevam
2011-02-06 12:03 ` Magnus Lilja
2011-02-06 15:07 ` Albert ARIBAUD
2011-02-07 11:32 ` Fabio Estevam
2011-02-07 14:13 ` Stefano Babic
2011-02-07 19:48 ` Magnus Lilja
2011-02-08 17:09 ` Fabio Estevam
2011-02-08 17:50 ` stefano babic
2011-02-08 19:26 ` Magnus Lilja
2011-02-08 20:18 ` stefano babic
2011-02-08 20:50 ` Albert ARIBAUD
2011-02-09 11:45 ` Fabio Estevam
2011-02-11 10:51 ` Aneesh V
2011-02-11 12:46 ` Albert ARIBAUD [this message]
2011-02-11 13:49 ` Aneesh V
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=4D552F8D.5020200@free.fr \
--to=albert.aribaud@free.fr \
--cc=u-boot@lists.denx.de \
/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