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

  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