From: Reinhard Meyer <u-boot@emk-elektronik.de>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH 1/2] arm: implement ELF relocations
Date: Wed, 06 Oct 2010 08:45:35 +0200 [thread overview]
Message-ID: <4CAC1B0F.3030607@emk-elektronik.de> (raw)
In-Reply-To: <4CAC1731.8030508@free.fr>
Dear Albert ARIBAUD,
> 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.
CONFIG_SKIP_RELOCATE_UBOOT could remain, making CONFIG_SYS_ARM_WITHOUT_RELOC
obsolete. Both must now anyway be defined together or both not!
Also I observed problems with old AT91 code since without
CONFIG_SYS_ARM_WITHOUT_RELOC board_init() is called very early, with it
is called after relocation is done. I think most AT91 boards that copied
code from AT91SAM9***-EK's have to correct their code because "early init"
stuff is done in board_init().
>
> 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'?
Everything, including the #if's that is there for the non-relocating cases.
(preventing was a bad choice of word)
>
>> 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.
CONFIG_RELOCATE_UBOOT definitely worked before the relocation patches, I
am not sure whether it still works, especially when
CONFIG_SYS_ARM_WITHOUT_RELOC is removed.
Best Regards,
Reinhard
next prev parent reply other threads:[~2010-10-06 6:45 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
2010-10-06 6:45 ` Reinhard Meyer [this message]
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=4CAC1B0F.3030607@emk-elektronik.de \
--to=u-boot@emk-elektronik.de \
--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