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] [PATCH 1/2] arm: implement ELF relocations
Date: Wed, 06 Oct 2010 08:29:05 +0200	[thread overview]
Message-ID: <4CAC1731.8030508@free.fr> (raw)
In-Reply-To: <4CAC10A4.30808@emk-elektronik.de>

Le 06/10/2010 08:01, Reinhard Meyer a ?crit :
> To me it looks now like we have dangling use of
>
> CONFIG_SKIP_RELOCATE_UBOOT and CONFIG_SYS_ARM_WITHOUT_RELOC
> all over the source, but it appears to me that they can't really
> work anymore (I have not tested that).

Indeed, CONFIG_SYS_ARM_WITHOUT_RELOC should disappear eventually -- it's 
still there only to give board maintainers a way to build with and 
without relocation e.g. for testing purposes, and it was announced that 
it would disappear when relocation makes it into an official release.

As for CONFIG_SKIP_RELOCATE_UBOOT, it was useful in getting a smaller 
u-boot that would not relocated because it was already at the right 
place to execute; perfect (along with CONFIG_SKIP_LOWLEVEL_INIT) for 
building a RAM-based, run-where-it-is u-boot.

Now with relocation, we may not need it any more; but you're right that 
it cannot stay if it does not work.

> Although I am not happy to have that removed right now
> (for code size concerns), I would suggest to remove all relocation
> preventing code which should make the code much more readable.

What do you mean by 'relocation-*preventing* code'?

>If really required, a new introduction of a define, mainly changing
>the linker options not to emit relocation information and skipping a
>few lines of relocation business _could_ be introduced.

That would be a cleaner thing, yes.

Right now I don't think that should go into the ELF relocation patch, 
though; I'll make sure CONFIG_SKIP_RELOCATE_UBOOT either works or goes 
away, but unless instructed otherwise, I won't introduce a system-wide 
"don't relocate" feature.

> Best Regards,
> Reinhard

Amicalement,
-- 
Albert.

  reply	other threads:[~2010-10-06  6:29 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-10-05 19:40 [U-Boot] [PATCH 1/2] arm: implement ELF relocations Albert Aribaud
2010-10-05 19:41 ` [U-Boot] [PATCH 2/2] edminiv2: add support for " Albert Aribaud
2010-10-06  5:30   ` Heiko Schocher
2010-10-06  5:55     ` Albert ARIBAUD
2010-10-06  5:37 ` [U-Boot] [PATCH 1/2] arm: implement " Heiko Schocher
2010-10-06  5:54   ` Albert ARIBAUD
2010-10-06  6:01   ` Reinhard Meyer
2010-10-06  6:29     ` Albert ARIBAUD [this message]
2010-10-06  6:45       ` Reinhard Meyer
2010-10-06  7:03         ` Albert ARIBAUD

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=4CAC1731.8030508@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