[U-Boot] [PATCH v2] arm: spl: Allow board_init_r() to run with a larger stack

[Simon Glass]

Hi Albert,

On 31 January 2015 at 15:36, Albert ARIBAUD <albert.u.boot at aribaud.net> wrote:
> Hello Simon,
>
> On Mon, 26 Jan 2015 08:34:21 -0700, Simon Glass <sjg at chromium.org>
> wrote:
>> At present SPL uses a single stack, either CONFIG_SPL_STACK or
>> CONFIG_SYS_INIT_SP_ADDR. Since some SPL features (such as MMC and
>> environment) require a lot of stack, some boards set CONFIG_SPL_STACK to
>> point into SDRAM. They then set up SDRAM very early, before board_init_f(),
>> so that the larger stack can be used.
>>
>> This is an abuse of lowlevel_init(). That function should only be used for
>> essential start-up code which cannot be delayed. An example of a valid use is
>> when only part of the SPL code is visible/executable, and the SoC must be set
>> up so that board_init_f() can be reached. It should not be used for SDRAM
>> init, console init, etc.
>>
>> Add a CONFIG_SPL_STACK_R option, which allows the stack to be moved to a new
>> address before board_init_r() is called in SPL.
>>
>> The expected SPL flow (for CONFIG_SPL_FRAMEWORK) is now:
>>
>> Execution starts with start.S. Two main functions can be provided by the
>> board implementation. The purpose and limitations of each is described below.
>> After that, the common board_init_r() is called to perform the SPL task.
>>
>> lowlevel_init():
>>       - purpose: essential init to permit execution to reach board_init_f()
>>       - no global_data, but there is a stack
>
> lowlevel_init() does not have a stack for all ARM CPUs, e.g. for
> arm926ejs it has none; and I don't see any code in this patch that
> provides one. If we need lowlevel_init to have a stack, then this stack
> should be set up in crt0.S and lowlevel_init called from there (which
> I would be fine with, btw).

OK, so I should adjust this comment I think. Is that the only action?

       - no global_data, but may be a stack (e.g. for armv7)

[snip]

Regards,
Simon