On Wed, May 13, 2015 at 8:22 PM, Simon Glass <s...@chromium.org> wrote: > Hi, > > On 13 May 2015 at 20:02, Simon Glass <s...@chromium.org> wrote: >> Hi, >> >> On 13 May 2015 at 16:40, Tim Harvey <thar...@gateworks.com> wrote: >>> On Wed, May 13, 2015 at 12:58 PM, Tim Harvey <thar...@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 _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
