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] [RFC PATCH] dm: Add support for all targets which requires MANUAL_RELOC
Date: Wed, 04 Feb 2015 23:08:43 +1100	[thread overview]
Message-ID: <54D20BCB.2050805@tss-engineering.com> (raw)
In-Reply-To: <20150204113407.764554dc@lilith>

Hi Albert,

>>>>
>>>>>
>>>>> If we use SPL, we do not have to relocate code, I think.
>>>>
>>>> SPL doesn't have relocation that's why this code is not used there.
>>>>
>>>
>>> It is not what I meant.
>>>
>>>
>>> If SPL can directly load the main u-boot image
>>> to the DRAM address where it is linked,
>>> we do not relocate the code in the main image.
>> Current behavior is that SPL is reading u-boot.img entry point which
>> can be in any location and jump to it and u-boot self relocate to the end of
>> memory.
>> If SPL adds u-boot directly to the location where it should run after relocation
>> then relocation is not needed.
>> To ensure this capability (based on my poor GOT/REL/RELA) experience it means
>> that SPL loads u-boot to that location and patch REL/RELA section based on this location
>> and internal relocation should be skipped.

I've always thought the logical approach would be for SPL to calculate 
where U-Boot would end up in RAM, copy it from wherever (NAND, NOR, MMC, 
whatever) to the final location, perform the relocation fixups, then 
jump straight into U-Boot. It's pretty much what the Dynamic Loader does 
(particularly with address space layout randomization)

>
> IOW, that SPL perform the work of relocate_code() in U-Boot -- at least,
> on ARM, where REL/RELA is used.
>
>> This is definitely doable for REL/RELA case and it can also speedup boot process
>
> Not sure about the speed-up, but never mind.

It will save a RAM to RAM copy of u-boot's text and data sections. 
However, running the relocation code in SPL may be even slower 
(depending on configuration of caches).

>> (I don't think there is easy way how to solve this with just GOT relocation because
>> of that MANUAL_RELOC code which is patching arrays with function pointers).
>
> Even without importing SPL in the equation, switching from GOT to
> REL/RELA has enourmous advantages.

I must admit, I'm really rusty with GOT vs REL/RELA - anyone care to 
give me a refresher?

But yes, only having to deal with REL/RELA sections will make the 
relocation procedures much simpler

Regards,


Graeme

      parent reply	other threads:[~2015-02-04 12:08 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-02-02 15:31 [U-Boot] [RFC PATCH] dm: Add support for all targets which requires MANUAL_RELOC Michal Simek
2015-02-02 23:57 ` Simon Glass
2015-02-03  2:02   ` Masahiro Yamada
2015-02-03  9:11     ` Michal Simek
2015-02-04  0:40       ` Simon Glass
2015-02-04  5:48         ` Graeme Russ
2015-02-04  9:58           ` Michal Simek
2015-02-05  3:07         ` Simon Glass
2015-02-05  6:31           ` Michal Simek
2015-02-06  5:45             ` Simon Glass
2015-02-09 10:27               ` Michal Simek
2015-02-09 22:14                 ` Simon Glass
2015-02-10  9:55                   ` Michal Simek
2015-02-12 22:18                     ` Simon Glass
2015-02-04  3:11       ` Masahiro Yamada
2015-02-04  9:56         ` Michal Simek
2015-02-04 10:34           ` Albert ARIBAUD
2015-02-04 11:39             ` Michal Simek
2015-02-04 12:08             ` Graeme Russ [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=54D20BCB.2050805@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