[U-Boot] [PATCH] env_mmc: avoid stack allocation for env

[Tim Harvey]

On Wed, May 13, 2015 at 8:22 PM, Simon Glass <sjg at chromium.org> wrote:
> Hi,
>
> On 13 May 2015 at 20:02, Simon Glass <sjg at chromium.org> wrote:
>> Hi,
>>
>> On 13 May 2015 at 16:40, Tim Harvey <tharvey at gateworks.com> wrote:
>>> On Wed, May 13, 2015 at 12:58 PM, Tim Harvey <tharvey at 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