Hi Tim,
On 14 May 2015 at 07:11, Tim Harvey tharvey@gateworks.com wrote:
On Wed, May 13, 2015 at 8:22 PM, Simon Glass sjg@chromium.org wrote:
Hi,
On 13 May 2015 at 20:02, Simon Glass sjg@chromium.org wrote:
Hi,
On 13 May 2015 at 16:40, Tim Harvey tharvey@gateworks.com wrote:
On Wed, May 13, 2015 at 12:58 PM, Tim Harvey tharvey@gateworks.com wrote:
<snip
Tom,
I don't really understand the CONFIG_SPL_STACK_R usage at all. The only thing that uses CONFIG_SPL_STACK_R is spl_relocate_stack_gd which is called from arch/arm/lib/crt0.S 'after' board_init_f() is called, which will never return for SPL because we loaded and jumped to u-boot.img.
How is this working for the am335x stuff?
Tom just forwarded me this thread. There is definitely something missing upstream compared to my local branch. I'll take a look and see what I missed.
It should say CONFIG_SPL_STACK_R_ADDR instead of CONFIG_SPL_STACK_R
As to the question about why CONFIG_SPL_STACK_R does not produce a compile error, it is defined to 1 in autoconf.h, which is a valid number. With the current value it sets the stack to 0xffffff28 which seems invalid to me (it is in reserved memory).
ok - makes sense.... I thought I was going crazy.
It's a little bit of a mystery as to why this works on my beaglebone black.
probably just lucky address wrapping
Anyway I have sent a patch to correct it.
There are instructions in the README for using CONFIG_SPL_STACK_R, and for the new board init flow. Basically you need to return normally from your SPL board_init_f(). The code in crt0.S will then change the SPL stack to CONFIG_SPL_STACK_R_ADDR which should be in SDRAM and everything should be good.
So perhaps what you are missing is that board_init_f() is now expected to return. It must not load U-Boot at this stage. That is supposed to happen in board_init_r().
I completely missed your recent commit regarding the stack relocation (db910353a126d84fe8dff7a694ea792f50fcfb6a) - I must admit I don't have time to keep up-to-date on the maillist.
As its a new thing that spl board_init_f should 'not' call board_init_r, there are a lot of spl files that still call it directly (as well as the weak implementation of board_init_f in arch/arm/lib/spl.c). Of course, as I found out you really don't need to remove that call unless you want to use stack relocation. The documentation in arch/arm/lib/crt0.S is now out of date and doesn't mention the fact that for SPL you should not call board_init_f - perhaps this documentation should be removed and the README referred to (or visa versa).
Thanks for clearing this up.
Tim
Just to update this thread, I sent a patch for this:
http://patchwork.ozlabs.org/patch/502840/
Regards, Simon