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

[Albert ARIBAUD <albert.u.boot@aribaud.net>]

Hi Helmut,

On Thu, 03 Jul 2014 10:19:39 +0200, Helmut Raiger
<helmut.raiger@hale.at> wrote:

> Hi,
> 
> On 07/03/2014 01:20 AM, Beno?t Th?baudeau wrote:
> > )Dear Helmut Raiger,
> >
> > On Wed, Jul 2, 2014 at 9:04 AM, Helmut Raiger <helmut.raiger@hale.at> wrote:
> >>>       the commit 41623c91 breaks the SPL on i.mx31 platforms.
> > Here, you are talking about mx31pdk, right?
> Actually im talking TT-01, but it has no contributed NAND boot code (which I
> was working on), but it should hit mx31pdk in the same way.
> This should answer Albert's question about the board.

It does, thanks -- but I fail to see any SPL code built for TT-01.
You're getting SPL issues with another target, right?

> >> 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.
> > Actually, the ROM bootloader first copies the first NAND page to
> > 0xB8000000. Then, the SPL placed here but linked at
> > CONFIG_SPL_TEXT_BASE copies itself to CONFIG_SPL_TEXT_BASE in order
> > to free the NFC buffer so that it can be used by the SPL. There is
> > no relocation going on at this stage, but only a copy, and the SPL
> > code size is limited to 2 kiB. Then, the SPL does its NAND load job
> > towards CONFIG_SYS_TEXT_BASE and starts executing the non-SPL
> > binary, which then relocates itself according to the heap size, etc.

Ok, I think I'm getting it, but actually you don't need PIC (your code
won't run at arbitrary locations), you need VMAs vs LMAs (your code
will run partly at one location, partly at another, but will be loaded
at only one of these locations).

Therefore, we should be able to manage this in the linker script, by
basically defining two output sections: the first one with a VMA and
LMA equal to 0xB8000000 both, and which would contain the 'copier' code;
and the second one with a VMA equal to CONFIG_SPL_TEXT_BASE (so that it
links properly for running at that address) and a LMA equal to 0xB800000
(so that it gets lumped with the first section in the less-than-2K ELF
file produced by the linker.

(actually we'd have several output sections with VMA==LMA, but it
does not affect the core of the idea.)

 Does it make sense to you?

> Helmut

Amicalement,
-- 
Albert.