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.rai...@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.rai...@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.
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
