public inbox for u-boot@lists.denx.de
 help / color / mirror / Atom feed
From: Jeroen Hofstee <dasuboot@myspectrum.nl>
To: u-boot@lists.denx.de
Subject: [U-Boot] armv8 relocation questions
Date: Sun, 18 May 2014 14:37:45 +0200	[thread overview]
Message-ID: <1400416665.2394.20.camel@yellow> (raw)
In-Reply-To: <20140517165301.E49DE38042B@gemini.denx.de>

Hello Wolfgang,

On za, 2014-05-17 at 18:53 +0200, Wolfgang Denk wrote:
> Dear fenghua,
> 
> In message <B9A956AA-4ED7-488D-B496-90111AA45A5A@phytium.com.cn> you wrote:
> > 
> > 
> > We can not make gcc-aarch64 do not use adrp instruction when
> > constructing address of label.
> > 
> > So, I think the 4kb alignment would be a requirement or restriction.
> > Gcc did not declare it explicitly
> > due to in normal world memory are allocated with page aligned.
> > If u-boot for aarch64 want to be compiled at address not 4kb aligned
> > the relocated address
> > should also be shifted with the same offset.
> 
> Sorry, I don't understand anything here.  At which exact place is
> there any such 4 k alignment restriction?  When we relocate U-Boot, we
> just process a list of addresses.  Even if the start of the image is
> aligned to a 4 k boundary, there are a zillion of other addresses that
> are not, and these can be relocated just fine.
> 

The following document [1] mentions:

"ADRP Xd, label
Address of Page: sign extends a 21-bit offset, shifts it left by 12 and
adds it to the value of the PC with its bottom 12 bits cleared, writing
the result to register Xd. This computes the base address of the 4KiB
aligned memory region containing label, and is designed to be used in
conjunction with a load, store or ADD instruction which supplies the
bottom 12 bits of the label?s address. This permits position-
independent addressing of any location within ?4GiB of the PC using two
instructions, providing that dynamic relocation is done with a minimum
granularity of 4KiB (i.e. the bottom 12 bits of the label?s address are
unaffected by the relocation). The term ?page? is short-hand for the
4KiB relocation granule, and is not necessarily related to the virtual
memory page size."

And apparently gcc choose to use it as such. Since the instructions in
question are relative to the most significant bits of the pc it does not
need fixups, so it is not included in the "list of addresses" you
mention. The compiler does create the 4k requirement though by using the
instruction the way it does.

Regards,
Jeroen

[1]
http://www.element14.com/community/servlet/JiveServlet/previewBody/41836-102-1-229511/ARM.Reference_Manual.pdf

  reply	other threads:[~2014-05-18 12:37 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-05-13 21:38 [U-Boot] armv8 relocation questions Darwin Rambo
2014-05-16 13:47 ` fenghua at phytium.com.cn
2014-05-16 16:23   ` Darwin Rambo
2014-05-16 20:28     ` Wolfgang Denk
2014-05-16 21:15       ` Tom Rini
2014-05-16 22:26         ` Jeroen Hofstee
2014-05-17  2:13           ` fenghua at phytium.com.cn
2014-05-17 16:53             ` Wolfgang Denk
2014-05-18 12:37               ` Jeroen Hofstee [this message]
2014-05-18 19:51                 ` Wolfgang Denk
2014-05-19  7:37                   ` Jeroen Hofstee
2014-05-19 12:33                     ` Wolfgang Denk
2014-05-19 18:10                       ` Jeroen Hofstee
2014-05-19 18:30                         ` Wolfgang Denk
2014-05-19 20:42                           ` Jeroen Hofstee
2014-05-19 21:05                             ` Wolfgang Denk
2014-05-20 17:42                               ` Jeroen Hofstee
2014-05-16 21:24       ` Darwin Rambo
2014-05-16 21:52         ` Tom Rini
2014-05-22 14:19     ` fenghua at phytium.com.cn
2014-05-23  6:51       ` Wolfgang Denk
2014-05-26 13:11         ` fenghua at phytium.com.cn
2014-05-26 14:38           ` Wolfgang Denk
2014-05-17  3:53   ` fenghua at phytium.com.cn

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=1400416665.2394.20.camel@yellow \
    --to=dasuboot@myspectrum.nl \
    --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