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] SPL broken on i.mx31 platforms
Date: Wed, 2 Jul 2014 12:58:46 +0200	[thread overview]
Message-ID: <E1X2IFU-0002tJ-K7@janus> (raw)
In-Reply-To: <53B3AF0E.1010105@hale.at>

Hi Helmut,

On Wed, 02 Jul 2014 09:04:46 +0200, Helmut Raiger
<helmut.raiger@hale.at> wrote:

> Hi,
> > Hi,
> >
> >      the commit 41623c91 breaks the SPL on i.mx31 platforms.
> > The original startup code (start.S) was position independent to
> > allow relocation in board_init_f. This is necessary as the internal
> > RAM used by the IPL to load the first 2kB from NAND is also
> > used by the NAND controller to buffer pages.
> > As far as the issue goes: where and how exactly is the code not
> > position independent now?
> The first statement is now:
> 
>      ldr pc, _reset
> _reset: .word reset
> 
> reset is an address generated by the linker (here 0x87dc0060).
> Originally this was:
> 
>      b reset
> 
> which is a relative branch (here 0x60 bytes forward).
> 
> I have to add, that changing this back does not fix the issue, something 
> else is in disorder.
> I'm still working on it.
> 
> >>> Does changing the startup code back to PIC generate any
> >>> drawbacks on other ARM platforms?
> > How would this changing back to PIC be implemented? Not by reverting
> > the patch, I hope.
> No, it will only be a minor change, I think, but I thought there might
> have been an additional intention behind the change to position
> dependent code. One could link the first part to 0xB8000000
> (the original position of the SPL when loaded by the IPL) and
> the part after the relocation to CONFIG_SPL_TEXT_BASE.
> >>> What was the intention of the change besides unifying?
> > Any other intent would be stated in the commit message.
> Ok, so the PIC issue was just an oversight.
> 
> > Maybe Albert, Stefano or Magnus could help?
> > I don't have mx31 hardware either.
> >
> >
> It seems we are the only ones still dealing with this old lad ;-)

Full position independence was a lucky side effect of the code, not an
intended feature; relocation is precisely here because moving code
around usually won't work.

However, no relocation record (relative or other) are generated for the
indirect vectors, so that'll need a fix as well. It basically works in
U-Boot because most of the targets get loaded at their link-time base
address, so the indirect vectors are correct.

I suspect in your case, SPL was linked for one address and gets jumped
into at another address.

Can you tell me which board exactly you are experiencing the issue on?

> Helmut

Amicalement,
-- 
Albert.

  reply	other threads:[~2014-07-02 10:58 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-07-01 13:33 [U-Boot] SPL broken on i.mx31 platforms Helmut Raiger
2014-07-01 13:53 ` Fabio Estevam
2014-07-01 19:45   ` Albert ARIBAUD
2014-07-02  7:04     ` Helmut Raiger
2014-07-02 10:58       ` Albert ARIBAUD [this message]
2014-07-02 23:20       ` Benoît Thébaudeau
2014-07-03  8:19         ` Helmut Raiger
2014-07-03 13:35           ` Albert ARIBAUD
2014-07-03 20:58             ` Benoît Thébaudeau
2014-07-04  8:50               ` Albert ARIBAUD
2014-07-04 10:42                 ` Magnus Lilja
2014-07-04 21:42                   ` Benoît Thébaudeau
2014-07-04 21:29                 ` Benoît Thébaudeau
2014-07-03 20:58           ` Benoît Thébaudeau
2014-07-08  8:05             ` Helmut Raiger
2014-07-08 12:32               ` Helmut Raiger
2014-07-08 12:48                 ` Helmut Raiger
2014-07-09  8:22               ` [U-Boot] SPL broken on i.mx31 platforms, FIX? Helmut Raiger
2014-07-11  7:56               ` [U-Boot] SPL broken on i.mx31 platforms Magnus Lilja
2014-07-15  9:31                 ` Helmut Raiger
2014-08-04 20:23                   ` Magnus Lilja
2014-08-04 20:40                     ` Jeroen Hofstee
2014-08-05 12:28                     ` Fabio Estevam
2014-08-05 12:32                       ` Magnus Lilja
2014-08-13 12:01                         ` Helmut Raiger
2014-08-15 17:45                           ` Magnus Lilja
2014-08-19 20:55                             ` Benoît Thébaudeau
2014-08-19 22:01                               ` Fabio Estevam
2014-09-03  0:53                               ` Benoît Thébaudeau
2014-09-03  1:13                                 ` Tom Rini
2014-09-04 19:12                                   ` Magnus Lilja
2014-09-04 19:50                                     ` Benoît Thébaudeau
2014-09-04 19:59                                       ` Magnus Lilja
2014-07-02  8:11   ` Stefano Babic

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=E1X2IFU-0002tJ-K7@janus \
    --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