public inbox for u-boot@lists.denx.de
 help / color / mirror / Atom feed
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

      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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox