From: Aneesh V <aneesh@ti.com>
To: u-boot@lists.denx.de
Subject: [U-Boot] [RFC] ARM: mx31pdk: Use the new relocation scheme
Date: Fri, 11 Feb 2011 19:19:36 +0530 [thread overview]
Message-ID: <4D553E70.60800@ti.com> (raw)
In-Reply-To: <4D552F8D.5020200@free.fr>
On Friday 11 February 2011 06:16 PM, Albert ARIBAUD wrote:
[snip...]
>>>
>>> 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?
No. It doesn't. I am fine with this change if it applies only to u-boot.
br,
Aneesh
prev parent reply other threads:[~2011-02-11 13:49 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
2011-02-11 13:49 ` Aneesh V [this message]
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=4D553E70.60800@ti.com \
--to=aneesh@ti.com \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.