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

[Helmut Raiger]

On 07/03/2014 10:58 PM, Benoît Thébaudeau wrote:
> Hi,
>
> On Thu, Jul 3, 2014 at 10:19 AM, Helmut Raiger <helmut.raiger at hale.at> wrote:
>> 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.
> Then, since you are out of tree, can you test with the HEAD vs.
> 41623c91 vs. 41623c91^ mx31pdk codes, replacing the _reset lines with
> "b reset" or "bl reset" after "_start:" for 41623c91 and HEAD? It
> would probably run U-Boot on TT-01 too. You can remove board-specific
> initializations like GPIO outputs from mx31pdk.c in order not to risk
> damaging the board (just keep a valid UART to see the boot). This is
> just to make sure that there is nothing wrong in your out-of-tree code
> that could interfere with the mainline changes, like a custom SPL
> linker script that would miss the *(.vectors) section.

1) Simply reverting the 41623c91 on HEAD makes it work again.
2) Replace ldr pc, _reset with b reset, still hangs
3) I'm using no special linker scripts, board_init_f() is pretty much 
the same as in mx31pdk.


> You are talking about rebasing, reverting, and testing with modified
> mainline. Just to make things clear, do you confirm that reverting
> commit 41623c91 on top of mainline works (not just rebasing before
> this commit)? You mentioned failing tests with a modified mainline, so
> I want to make sure that there is no other offending commit after
> 41623c91 that would interfere with these tests.
Yes reverting 41623c91 on HEAD works, there is no other offending commit.

>
> I was using the word 'relocation' instead of copying. I did
> what you suggest, but this does not completely fix the issue.
> If the only wrong commit is 41623c91, I do not see what else could be
> wrong, hence my questions above.
>
> What do you mean by "not completely"? Is there any progress?

I meant, that the SPL is now doing the RAM init and copying of the SPL code
correctly. RAM is working, the SPL code is at 0x87dc0000 after that 
(CRCed it via JTAG).
I could not track it further (I have very limited development time right 
now ... repeating myself).

After all I need to debug further. If someone could test the current 
state on the
mx31pdk, this still would be great. Just to rule out any other board 
specific issues.

Helmut


--
Scanned by MailScanner.