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

[Simon Glass]

Hi Tim,

On 14 May 2015 at 07:11, Tim Harvey <tharvey at gateworks.com> wrote:
> 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

Just to update this thread, I sent a patch for this:

http://patchwork.ozlabs.org/patch/502840/

Regards,
Simon