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

["Benoît Thébaudeau" <benoit.thebaudeau.dev@gmail.com>]

Hi Albert,

On Fri, Jul 4, 2014 at 10:50 AM, Albert ARIBAUD
<albert.u.boot@aribaud.net> wrote:
> On Thu, 3 Jul 2014 22:58:56 +0200, Beno?t Th?baudeau
> <benoit.thebaudeau.dev@gmail.com> wrote:
>> On Thu, Jul 3, 2014 at 3:35 PM, Albert ARIBAUD
>> <albert.u.boot@aribaud.net> wrote:
>> > On Thu, 03 Jul 2014 10:19:39 +0200, Helmut Raiger
>> > <helmut.raiger@hale.at> wrote:
>> >> On 07/03/2014 01:20 AM, Beno?t Th?baudeau wrote:
>> >> > 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?
>>
>> 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.

Looks good.

>> 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.

OK. There seems to be the same issue for
board/ait/cam_enc_4xx/u-boot-spl.lds . All the ARM arch and ARM boards
linker scripts should probably be rechecked.

>> 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.

Sorry, I can't before next week at best.