From: Dirk Behme <dirk.behme@de.bosch.com>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH] arm: Add option to disable code relocation
Date: Tue, 7 Feb 2012 07:51:22 +0100 [thread overview]
Message-ID: <4F30C9EA.30401@de.bosch.com> (raw)
In-Reply-To: <4F304376.3020400@aribaud.net>
On 06.02.2012 22:17, Albert ARIBAUD wrote:
> 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.
For the i.MX6 preloader, i.e. the i.MX6 boot ROM, the issue I observed
is that the copy *and* relocation will be skipped [1]. The skipped copy
is fine, skipping the relocation breaks things, though:
Getting the address where U-Boot will relocate to, and setting this as
CONFIG_SYS_TEXT_BASE will result in skipping the copy. Fine. But the
whole 'fix .rel.dyn relocations' in e.g. arch/arm/cpu/armv7/start.S is
skipped, too. And this breaks things.
Best regards
Dirk
[1] http://lists.denx.de/pipermail/u-boot/2012-February/117134.html
next prev parent reply other threads:[~2012-02-07 6:51 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
2012-02-06 22:24 ` Wolfgang Denk
2012-02-07 6:51 ` Dirk Behme [this message]
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=4F30C9EA.30401@de.bosch.com \
--to=dirk.behme@de.bosch.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