[U-Boot] SPL broken on i.mx31 platforms

Albert ARIBAUD albert.u.boot at aribaud.net
Wed Jul 2 12:58:46 CEST 2014


Hi Helmut,

On Wed, 02 Jul 2014 09:04:46 +0200, Helmut Raiger
<helmut.raiger at 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.


More information about the U-Boot mailing list