public inbox for u-boot@lists.denx.de
 help / color / mirror / Atom feed
From: Graeme Russ <gruss@tss-engineering.com>
To: u-boot@lists.denx.de
Subject: [U-Boot] Let's bury CONFIG_NEEDS_MANUAL_RELOC
Date: Wed, 04 Feb 2015 18:14:22 +1100	[thread overview]
Message-ID: <54D1C6CE.2020307@tss-engineering.com> (raw)

Hi Guys,

Since I did the initial 'full relocation' for x86 way back when 
(http://git.denx.de/?p=u-boot.git;a=commit;h=1c409bc7101a24ecd47a13a4e851845d66dc23ce), 
there has been a lot of chatter about the ongoing need for 
CONFIG_NEEDS_MANUAL_RELOC. I think it's about time we looked really hard 
at this define and come to a definitive conclusion as to IF and HOW we 
can get rid of it for the remaining architectures that use it (being 
avr32, m68k, nds32, and sparc).

First, a bit of a primer on why and how I finally killed off 
CONFIG_NEEDS_MANUAL_RELOC for x86...

Despite the best intentions of the 'manual' relocation performed by 
U-Boot, there were still instances where the U-Boot binary referenced 
the 'unrelocated' image which typically resides in flash (NOR flash in 
the case of the x86 board I was using). I only finally tracked this down 
through some arduous debugging of random crashes during the writing of a 
new U-Boot image to the NOR flash.

After a lot of digging around, I managed to get a good understanding of 
the ELF binary format for x86 and compiler/linker flags needed in order 
to generate a binary image that could be relocated. It turns out that 
for x86, it was the -pic and --emit-relocs ld flags (Oddly, I cannot 
find the -pic flag in the gnu ld documentation maybe it's depricated?)

The --emit-relocs flags leaves the relocation sections (for x86 the 
section of interest is .rela.dyn) in the final image. These sections 
list all the locations in the final binary that need to be adjusted if 
the image is loaded at a different address than the one it is compiled 
for. You can see the processing in do_elf_reloc_fixups() in 
arch/x86/lib/relocate.c

Keep in mind that the relocation sections are NOT copied to RAM - they 
are only used once after U-Boot is copied to RAM to locate the memory 
locations that need to be adjusted.

So the crux of generic relocation is to generate a stripped binary with 
all necessary ELF relocation information located AFTER the text and data 
sections which are copied to RAM

So the first question that we need to answer is: Do the avr32, m68k, 
nds32, and sparc toolchains support the generation of the relevant 
sections needed to perform relocation in a manner similar to x86 (i.e 
generation of relocation references into sections of the final U-Boot 
binary)?

Regards,

Graeme

             reply	other threads:[~2015-02-04  7:14 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-02-04  7:14 Graeme Russ [this message]
2015-02-04 10:29 ` [U-Boot] Let's bury CONFIG_NEEDS_MANUAL_RELOC Albert ARIBAUD
2015-02-04 12:16   ` Graeme Russ

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=54D1C6CE.2020307@tss-engineering.com \
    --to=gruss@tss-engineering.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox