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

[Benoît Thébaudeau]

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.

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

Cordialement,
Benoît