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] Dump questions about u-boot relocation
Date: Wed, 22 Sep 2010 21:33:17 +0200	[thread overview]
Message-ID: <4C9A59FD.4050707@free.fr> (raw)
In-Reply-To: <AANLkTikAP9TO3x6_C3K=fSEaR_7Vmiw8adwwCjBvuh6P@mail.gmail.com>

Le 22/09/2010 19:10, Rajat Jain a ?crit :
> Hello,
>
> 1) If a code section (from an abolutely linked executable) is linked
> at address "x" but is instead loaded at address "y" would it still
> execute fine? Considereding the absolute branching, gloab variable
> access etc.

This question has no definite answer, because it strongly depends on the 
arch and cpu, code generation options, etc; but the most likely answer 
is 'no, it will not execute fine', and will require modifications 
('fixups').

> 2) If not, then how does u-boot work after relocation? All the uboot
> code&  data section is linked to the flash addresses. But after
> relocation is running from RAM?

This depends on architectures and cpus. For ARM, relocation options 
added to build (-fPIC, -fPIE) minimize the fixup work needed to 
relocate, and produce a GOT -- global offset table -- which basically 
lists the address of each location in the binary which requires fixing 
up. After relocation and before jumping to RAM, u-boot must go through 
this table and perform the fixups.

> 3) I need to write some code that shall be linked at address "x" but
> shall be running while sitting at address "y". What are the
> precautions in my code that if I take, will I be able to achieve this?

Patience, all relevant datasheets (and I mean *all* of them), knowledge 
of assembly language for your target and a JTAG debugger are a minimum. :)

The problem is that when you run at a different location than the one 
specified at link time, you cannot fixup the code using the GOT as required.

This means any data holding a pointer will be wrong if you do nothing 
about it.

Note also that the code does not always use relocation where you would 
expect it to. For instance, on ARM targets, board_init_f() uses a table 
of pointers to functions, init_sequence[]. These pointers were computed 
at link time, and thus point to link-time locations; looking at the 
disassembled code will show you that they don't go through GOT 
relocation. They're used as-is, and so are wrong if you don't execute 
from the link-time location.

> Thanks,
>
> Rajat Jain
>
> PS: IN the above, whereever I write address, I actually mean "virtual
> address" not physical.
> _______________________________________________
> U-Boot mailing list
> U-Boot at lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot

Amicalement,
-- 
Albert.

      reply	other threads:[~2010-09-22 19:33 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-09-22 17:10 [U-Boot] Dump questions about u-boot relocation Rajat Jain
2010-09-22 19:33 ` Albert ARIBAUD [this message]

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=4C9A59FD.4050707@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