public inbox for u-boot@lists.denx.de
 help / color / mirror / Atom feed
From: Albert ARIBAUD <albert.u.boot@aribaud.net>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH] arm: Add option to disable code relocation
Date: Mon, 06 Feb 2012 22:17:42 +0100	[thread overview]
Message-ID: <4F304376.3020400@aribaud.net> (raw)
In-Reply-To: <201202061427.02208.vapier@gentoo.org>

Le 06/02/2012 20:27, Mike Frysinger a ?crit :
> On Monday 06 February 2012 09:49:27 Tom Rini wrote:
>> On Mon, Feb 6, 2012 at 1:43 AM, Graeme Russ wrote:
>>> On 02/06/2012 06:51 PM, Wolfgang Denk wrote:
>>>> Graeme Russ wrote:
>>>>> I think the immediate focus should be on centralising the init sequence
>>>>> processing into /common/init.c and then bringing the new'initcall'
>>>>> architecture online
>>>>
>>>> Agreed.
>>>>
>>>>> Once these have been done, any board can just specific:
>>>>>
>>>>> SKIP_INIT(RELOC)
>>>>
>>>> I will probably object to his, too - for the same reasons.
>>>
>>> Considering this is a 'free' artefact of how the init sequence functions,
>>> and that it is board specific and totally non-invasive for anyone else
>>> (i.e. no ugly ifdef's anywhere else in the code) I'm surprised you would
>>> object...
>>
>> To pick up Wolfgang's argument, but why do we want to skip relocation?
>>   You can debug through it, it's documented (official wiki has GDB,
>> over in TI-land, the wiki page for CCS has the bits for doing it in
>> that Eclipse-based env, other debuggers I'm sure have a similar "now
>> add symbols at this offset from link" option) and the end result makes
>> it very easy for end-users to break their world (default kernel load
>> addrs being where U-Boot would be).
>
> if you have a static platform which never changes, isn't the relocation a
> waste of time ?  i can understand wanting relocation by default for platforms
> where memory sizes are unknown, but it's not uncommon for people to have fixed
> hardware when they deploy.

Relocation may not be a waste of time if the static platform boots 
U-Boot from NOR, as relocation will be needed to move U-Boot to RAM in 
working order.

Now if the platform is static and has a preloader of sorts, then one can 
predict (or just observe) where U-Boot would want to relocate, and set 
the preloader once and for all (for a given release of U-Boot, that is) 
to load U-Boot directly at that address. U-Boot will skip copy and 
relocation if it already resides at the right address.

> although, with SPL picking up direct-to-Linux booting, this argument might not
> matter that much anymore.

Agreed, although one could make a point that SPL direct-to-Linux is not 
the most common case currently and may not be applicable to all cases 
anyway.

> -mike

Amicalement,
-- 
Albert.

  parent reply	other threads:[~2012-02-06 21:17 UTC|newest]

Thread overview: 38+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-02-05  6:44 [U-Boot] [PATCH] arm: Add option to disable code relocation Simon Glass
2012-02-05  7:39 ` Mike Frysinger
2012-02-05 12:05   ` Marek Vasut
2012-02-05 20:38     ` Mike Frysinger
2012-02-05 21:40       ` Simon Glass
2012-02-05 22:44         ` Wolfgang Denk
2012-02-05 23:23           ` Graeme Russ
2012-02-05 23:32             ` Simon Glass
2012-02-05 23:37               ` Graeme Russ
2012-02-05 23:41                 ` Simon Glass
2012-02-05 23:46                   ` Graeme Russ
2012-02-07  9:52                   ` Graeme Russ
2012-02-06  7:51             ` Wolfgang Denk
2012-02-06  8:43               ` Graeme Russ
2012-02-06 14:49                 ` Tom Rini
2012-02-06 19:27                   ` Mike Frysinger
2012-02-06 19:46                     ` Tom Rini
2012-02-06 20:25                     ` Graeme Russ
2012-02-07  6:41                       ` Dirk Behme
2012-02-07 23:23                         ` Wolfgang Denk
2012-02-07 23:28                           ` Graeme Russ
2012-02-07 23:36                             ` Wolfgang Denk
2012-02-07 23:48                               ` Graeme Russ
2012-02-08  6:42                                 ` Dirk Behme
2012-02-08  6:51                               ` Dirk Behme
2012-02-08  7:12                                 ` Simon Glass
2012-02-08  7:16                                   ` Dirk Behme
2012-02-08 22:05                                   ` Graeme Russ
2012-02-09  3:38                                   ` Graeme Russ
2012-02-09 18:30                                     ` Simon Glass
2012-02-08 14:03                                 ` Wolfgang Denk
2012-02-06 21:17                     ` Albert ARIBAUD [this message]
2012-02-06 22:24                       ` Wolfgang Denk
2012-02-07  6:51                       ` Dirk Behme
2012-02-07  7:25                   ` Aneesh V
2012-02-05 23:32           ` Simon Glass
2012-02-05 12:05 ` Marek Vasut
2012-02-05 18:54 ` Wolfgang Denk

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=4F304376.3020400@aribaud.net \
    --to=albert.u.boot@aribaud.net \
    --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