From: Nick Thompson <nick.thompson@ge.com>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH] [NEXT] da830: fixup ARM relocation support
Date: Wed, 22 Sep 2010 16:15:58 +0100 [thread overview]
Message-ID: <4C9A1DAE.5000002@ge.com> (raw)
In-Reply-To: <AANLkTinsQvaXZm5yw9qMzJ9N=S6-=+miapgDZWfdT=aO@mail.gmail.com>
On 22/09/10 16:07, Ben Gardiner wrote:
> On Wed, Sep 22, 2010 at 10:15 AM, Nick Thompson <nick.thompson@ge.com> wrote:
>> On 22/09/10 14:43, Ben Gardiner wrote:
>>> What about removing "#define CONFIG_SKIP_RELOCATE_UBOOT" as in commit
>>> ab86f72c354f9b2572340f72b74ca0a258c451bd ?
>>
>> Hmmm. It wouldn't hurt I guess. The UBL copies the code to the correct
>> address though doesn't it? The copy is not executed and so the code is
>> redundant - or did I miss something?
>
> Yeah, good point. UBL does copy the code to the correct address -- but
> I also remember that I needed to remove that define in my testing of
> Heiko's patches on the da850.
>
> I'll get around to testing -next again soon and I'll try with
> CONFIG_SKIP_RELOCATE_UBOOT defined.
No, don't do that. I just did some testing myself. The relocation address
is calculated at run time and includes the size of u-boot itself. I got
away with it once in my debugger (I was trying to dodge the extra copy),
but it broke once I added more code.
You would have to change the UBL on more or less every build of u-boot
to skip the copy, which is clearly impractical.
I have removed CONFIG_SKIP_RELOCATE_UBOOT as you suggested and now
everything takes care of itself. I've already sent a v2 patch.
Thanks for pointing me in the right direction.
Nick.
next prev parent reply other threads:[~2010-09-22 15:15 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-09-22 13:16 [U-Boot] [PATCH] [NEXT] da830: fixup ARM relocation support Nick Thompson
2010-09-22 13:43 ` Ben Gardiner
2010-09-22 14:15 ` Nick Thompson
2010-09-22 15:07 ` Ben Gardiner
2010-09-22 15:15 ` Nick Thompson [this message]
2010-09-22 15:21 ` Ben Gardiner
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=4C9A1DAE.5000002@ge.com \
--to=nick.thompson@ge.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.