Hi Tim, On 14 May 2015 at 07:11, Tim Harvey <[email protected]> wrote: > On Wed, May 13, 2015 at 8:22 PM, Simon Glass <[email protected]> wrote: >> Hi, >> >> On 13 May 2015 at 20:02, Simon Glass <[email protected]> wrote: >>> Hi, >>> >>> On 13 May 2015 at 16:40, Tim Harvey <[email protected]> wrote: >>>> On Wed, May 13, 2015 at 12:58 PM, Tim Harvey <[email protected]> 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 _______________________________________________ U-Boot mailing list [email protected] http://lists.denx.de/mailman/listinfo/u-boot
