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

[Albert ARIBAUD]

Hi Benoît,

On Thu, 3 Jul 2014 22:58:56 +0200, Benoît Thébaudeau
<benoit.thebaudeau.dev at gmail.com> wrote:

> Hi Albert,
> 
> On Thu, Jul 3, 2014 at 3:35 PM, Albert ARIBAUD
> <albert.u.boot at aribaud.net> wrote:
> > Hi Helmut,
> >
> > On Thu, 03 Jul 2014 10:19:39 +0200, Helmut Raiger
> > <helmut.raiger at 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 at 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?
> 
> Helmut seems to be working on a custom TT-01 variant (or just with a
> specific hardware configuration using dip switches, or jumpers, etc.)
> using the i.MX31 NAND internal boot rather than the mainline boot
> source.
> 
> >> >> 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?
> 
> It makes sense to me. That should work, but it'd be better to avoid
> adding a custom linker script. A simple fix in vectors.S would be
> preferable if possible. Also, the __image_copy_start stuff should be
> taken care of with such a change.

I do not intend to have this in a custom linker script; I want this to
be in the common ARM SPL linker script (I hope it is what Helmut's
TT-01 changes use) -- I also want to get rid of all custom linker
scripts in the ARM par of U-Boot, but I could not get this done for
2014.07.

> BTW, I see that you skipped arch/arm/cpu/arm1136/u-boot-spl.lds in
> commit 41623c91 (addition of "*(.vectors)"). Was it intentional?

Not that I can remember: I did modify the arm1136 start.S, so te linker
scripts should have followed. 

> It silently changes woodburn_sd because the fallback exception vectors no
> longer exist. This should not cause a build error because the _start
> symbol is duplicated in this linker script. The board may also boot
> correctly with this, but the default vectors can be useful in some
> cases, especially for debugging exceptions.

Can you post a patch today? I'll pull it in a PR I'll do today before
COB.

> Cordialement,
> Benoît

Amicalement,
-- 
Albert.