public inbox for u-boot@lists.denx.de
 help / color / mirror / Atom feed
From: Albert ARIBAUD <albert.u.boot@aribaud.net>
To: u-boot@lists.denx.de
Subject: [U-Boot] [RFC PATCH] dm: Add support for all targets which requires MANUAL_RELOC
Date: Wed, 4 Feb 2015 11:34:07 +0100	[thread overview]
Message-ID: <20150204113407.764554dc@lilith> (raw)
In-Reply-To: <47a1090bf93248349575eba1fc1e3315@BN1AFFO11FD015.protection.gbl>

Hello Michal,

On Wed, 4 Feb 2015 10:56:02 +0100, Michal Simek
<michal.simek@xilinx.com> wrote:
> On 02/04/2015 04:11 AM, Masahiro Yamada wrote:
> > Hi Michal,
> > 
> > 
> > On Tue, 3 Feb 2015 10:11:39 +0100
> > Michal Simek <michal.simek@xilinx.com> wrote:
> > 
> >> Hi Simon,
> >>
> >> On 02/03/2015 03:02 AM, Masahiro Yamada wrote:
> >>> Hi.
> >>>
> >>>
> >>> On Mon, 2 Feb 2015 16:57:15 -0700
> >>> Simon Glass <sjg@chromium.org> wrote:
> >>>
> >>>> Hi Michal,
> >>>>
> >>>> On 2 February 2015 at 08:31, Michal Simek <michal.simek@xilinx.com> wrote:
> >>>>> Targets with CONFIG_NEEDS_MANUAL_RELOC do not use REL/RELA
> >>>>> relocation (mostly only GOT) where functions aray are not
> >>>>> updated. This patch is fixing function pointers for DM core
> >>>>> and serial-uclass to ensure that relocated functions are called.
> >>>>>
> >>>>> Signed-off-by: Michal Simek <michal.simek@xilinx.com>
> >>>>> ---
> >>>>>
> >>>>>  drivers/core/root.c            | 64 ++++++++++++++++++++++++++++++++++++++++++
> >>>>>  drivers/serial/serial-uclass.c | 16 +++++++++++
> >>>>>  2 files changed, 80 insertions(+)
> >>>>
> >>>> How long will we have to carry this patch? It seems that if we add any
> >>>> new driver we will have to add more code like this?
> >>>
> >>>
> >>>
> >>> This patch is unfortunate.
> >>> Can we discontinue CONFIG_NEEDS_MANUAL_RELOC some day?
> >>
> >> This patch (or similar one) has to be alive when we have platform
> >> which requires CONFIG_NEEDS_MANUAL_RELOC for full u-boot.
> >> There is an option to move to REL/RELA but the question is if
> >> all platforms have it/support it. Unfortunately I think that
> >> it will be in the tree for a long time.
> >>
> >>>
> >>> 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.

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.

> (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.

> Thanks,
> Michal

Amicalement,
-- 
Albert.

  reply	other threads:[~2015-02-04 10:34 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 [this message]
2015-02-04 11:39             ` Michal Simek
2015-02-04 12:08             ` 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=20150204113407.764554dc@lilith \
    --to=albert.u.boot@aribaud.net \
    --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