From: J. William Campbell <jwilliamcampbell@comcast.net>
To: u-boot@lists.denx.de
Subject: [U-Boot] ARM relocation, question to Heiko
Date: Sun, 03 Oct 2010 11:54:39 -0700 [thread overview]
Message-ID: <4CA8D16F.80504@comcast.net> (raw)
In-Reply-To: <20101003181438.D0BC51539A0@gemini.denx.de>
On 10/3/2010 11:14 AM, Wolfgang Denk wrote:
> Dear "J. William Campbell",
>
> In message<4CA75BFB.5030208@comcast.net> you wrote:
>>>>> And I think there are more places of this type in u-boot...
>>>> Yes, maybe. But relocation as I did for arm, also works
>>>> on m68k, sparc, mips, avr32 and they must do also this
>>>> fixups, so for common functions (except the new env handling,
>>>> which I think got never tested on this architectures?) should
>>>> work ...
>>> This pointer problem is solved with the fixup relocs on ppc and
>>> should work without manual relocation. I think this is a ppc
>>> only extension but I might be wrong.
>> You are correct that this is a ppc only extension. As such, it is
>> not a good candidate for "general" use.
> On contrary.
>
> If it works for PPC, then there should be ways to do the same on other
> architectures.
>
Well, maybe so, but GCC won't do it now, and there has been no move by
other architectures to adopt this capability. I suspect that it is
extremely unlikley that this capability will ever be ported to other
architectures since it has been available for so long on PPC without any
movement to other systems.
>> Using the full relocation scheme eliminates the need for all these
>> "fixups" in u-boot C code. I think this is a very desirable result.
>> It is also not clear to me that hard coding in the relocation as several
>> C routines will produce a u-boot that is "smaller" than the one
>> produced by using normal ELF relocation. However, using full relocation
>> creates an environment that is true "C" and does not rely on people
>> remembering that they may have to fix up some parts of their code. It is
>> hard to see much downside in using the full relocation capability
>> provided by Graeme's code.
> Agreed. But if we take this path, we need to find an implementation
> that looks clean and readable.
Agreed. This should be possible to do now that there is a better
understanding of the ELF format by the u-boot community. Perhaps the
place to start would be trying to port what Graeme has done to ARM or
perhaps better yet, PPC. Since lots of people on this list are PPC
folks, we should have a lot of leverage there.
Best Regards,
Bill Campbell
>
> Best regards,
>
> Wolfgang Denk
>
next prev parent reply other threads:[~2010-10-03 18:54 UTC|newest]
Thread overview: 113+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-09-30 13:57 [U-Boot] ARM relocation, probably trivial mistake Reinhard Meyer
2010-09-30 14:08 ` Stefano Babic
2010-09-30 14:20 ` Reinhard Meyer
2010-09-30 15:39 ` Heiko Schocher
2010-09-30 16:06 ` Reinhard Meyer
2010-09-30 15:38 ` Heiko Schocher
2010-09-30 17:43 ` Wolfgang Denk
2010-10-01 5:25 ` Heiko Schocher
2010-10-01 5:40 ` Albert ARIBAUD
2010-10-01 5:53 ` Heiko Schocher
2010-10-01 6:39 ` Reinhard Meyer
2010-10-01 6:57 ` Heiko Schocher
2010-10-01 8:45 ` Wolfgang Denk
2010-10-01 7:01 ` Albert ARIBAUD
2010-10-01 7:42 ` [U-Boot] ARM relocation, probably trivial mistake - back to original problem Reinhard Meyer
2010-10-01 8:27 ` Heiko Schocher
2010-10-01 10:44 ` Reinhard Meyer
2010-10-01 10:55 ` Wolfgang Denk
2010-10-01 11:03 ` Reinhard Meyer
2010-10-01 11:21 ` Wolfgang Denk
2010-10-01 11:37 ` Reinhard Meyer
2010-10-01 11:59 ` Wolfgang Denk
2010-10-01 12:22 ` Reinhard Meyer
2010-10-01 12:47 ` Reinhard Meyer
2010-10-01 12:55 ` Wolfgang Denk
2010-10-01 14:55 ` Reinhard Meyer
2010-10-02 8:53 ` Heiko Schocher
2010-10-01 15:47 ` Steve Sakoman
2010-10-02 7:15 ` [U-Boot] ARM relocation, question to Heiko Reinhard Meyer
[not found] ` <4CA6E517.9040701@fr<1286167382.22760.19.camel@ptyser-laptop>
2010-10-02 7:53 ` Albert ARIBAUD
2010-10-02 8:10 ` Reinhard Meyer
2010-10-02 8:26 ` Albert ARIBAUD
2010-10-03 18:04 ` Wolfgang Denk
2010-10-02 9:08 ` Heiko Schocher
2010-10-02 9:29 ` Albert ARIBAUD
2010-10-03 18:05 ` Wolfgang Denk
2010-10-02 10:17 ` Joakim Tjernlund
2010-10-02 16:21 ` J. William Campbell
2010-10-02 18:33 ` Reinhard Meyer
2010-10-03 18:22 ` Wolfgang Denk
2010-10-02 20:39 ` Reinhard Meyer
2010-10-02 21:09 ` Albert ARIBAUD
2010-10-02 23:07 ` Graeme Russ
2010-10-03 7:10 ` Albert ARIBAUD
2010-10-03 8:44 ` Graeme Russ
2010-10-03 8:58 ` Albert ARIBAUD
2010-10-03 15:36 ` J. William Campbell
2010-10-03 16:47 ` Albert ARIBAUD
2010-10-03 17:54 ` Albert ARIBAUD
2010-10-03 18:43 ` Wolfgang Denk
2010-10-04 5:41 ` Heiko Schocher
2010-10-03 18:29 ` Wolfgang Denk
2010-10-03 19:26 ` J. William Campbell
2010-10-04 5:52 ` Heiko Schocher
2010-10-03 18:14 ` Wolfgang Denk
2010-10-03 18:54 ` J. William Campbell [this message]
2010-10-03 19:52 ` Albert ARIBAUD
2010-10-03 18:03 ` Wolfgang Denk
2010-10-03 18:34 ` Albert ARIBAUD
2010-10-03 18:45 ` Wolfgang Denk
2010-10-04 6:08 ` Heiko Schocher
2010-10-04 6:40 ` Albert ARIBAUD
2010-10-04 7:27 ` Reinhard Meyer
2010-10-04 8:28 ` Albert ARIBAUD
2010-10-04 8:57 ` Heiko Schocher
2010-10-04 9:27 ` Albert ARIBAUD
2010-10-04 10:01 ` Joakim Tjernlund
2010-10-04 9:58 ` Graeme Russ
2010-10-04 14:17 ` Albert ARIBAUD
2010-10-04 14:25 ` Rogan Dawes
2010-10-04 15:24 ` Albert ARIBAUD
2010-10-04 16:31 ` Stefan Roese
2010-10-04 21:31 ` Albert ARIBAUD
2010-10-04 7:44 ` Albert ARIBAUD
2010-10-04 4:43 ` Peter Tyser
2010-10-04 6:08 ` Wolfgang Denk
2010-10-04 7:36 ` Joakim Tjernlund
2010-10-04 8:08 ` Albert ARIBAUD
2010-10-04 8:28 ` Joakim Tjernlund
2010-10-04 8:33 ` Albert ARIBAUD
[not found] ` <OF05779DA1.EF3C4954-ONC12577B2.00307A0D-C12577B2.0030B9C0@tran <4CAA1613.80002@comcast.net>
2010-10-04 8:52 ` Joakim Tjernlund
2010-10-04 9:10 ` Albert ARIBAUD
2010-10-04 10:13 ` Wolfgang Denk
2010-10-04 15:28 ` J. William Campbell
2010-10-04 15:52 ` Albert ARIBAUD
2010-10-04 17:06 ` Wolfgang Denk
2010-10-04 17:59 ` J. William Campbell
2010-10-04 18:43 ` Joakim Tjernlund
2010-10-04 21:10 ` Wolfgang Denk
2010-10-05 7:26 ` Joakim Tjernlund
2010-10-04 17:04 ` Graeme Russ
2010-10-04 17:14 ` Wolfgang Denk
2010-10-04 8:27 ` Wolfgang Denk
2010-10-02 8:49 ` [U-Boot] ARM relocation, probably trivial mistake - back to original problem Heiko Schocher
2010-10-01 12:49 ` Wolfgang Denk
2010-10-01 14:48 ` Reinhard Meyer
2010-10-04 7:44 ` [U-Boot] AT91 clock and timer cleanups (was: ARM relocation, probably trivial mistake - back to original problem) Reinhard Meyer
2010-10-04 8:32 ` Wolfgang Denk
2010-10-04 8:42 ` [U-Boot] AT91 clock and timer cleanups Reinhard Meyer
2010-10-04 8:49 ` Wolfgang Denk
2010-10-04 8:52 ` Reinhard Meyer
2010-10-04 9:03 ` Wolfgang Denk
2010-10-04 9:12 ` Reinhard Meyer
2010-10-04 14:58 ` Reinhard Meyer
2010-10-04 17:00 ` Wolfgang Denk
2010-10-04 17:15 ` Reinhard Meyer
2010-10-04 17:32 ` Wolfgang Denk
2010-10-04 19:22 ` Reinhard Meyer
2010-10-01 8:48 ` [U-Boot] ARM relocation, probably trivial mistake - back to original problem Wolfgang Denk
2010-10-01 9:50 ` Reinhard Meyer
2010-10-01 8:03 ` [U-Boot] ARM relocation, probably trivial mistake Wolfgang Denk
2010-10-01 7:51 ` Wolfgang Denk
2010-10-01 8:28 ` Heiko Schocher
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=4CA8D16F.80504@comcast.net \
--to=jwilliamcampbell@comcast.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