All of lore.kernel.org
 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 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.