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

[Simon Glass]

Hi Albert,

On 18 January 2015 at 23:54, Albert ARIBAUD <albert.u.boot at aribaud.net> wrote:
> Hello Simon,
>
> On Sun, 18 Jan 2015 11:55:36 -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
>>       - must not set up SDRAM or use console
>>       - must only do the bare minimum to allow execution to continue to
>>               board_init_f()
>>       - this is almost never needed
>>       - return normally from this function
>>
>> board_init_f():
>>       - purpose: set up the machine ready for running board_init_r():
>>               i.e. SDRAM and serial UART
>>       - global_data is available
>>       - preloader_console_init() can be called here in extremis
>>       - stack is in SRAM
>>       - should set up SDRAM, and anything needed to make the UART work
>>       - these is no need to clear BSS, it will be done by crt0.S
>>       - must return normally from this function (don't call board_init_r()
>>               directly)
>>
>> Here the BSS is cleared. If CONFIG_SPL_STACK_R is defined, then at this point
>> the stack and global_data are relocated to below that address.
>>
>> board_init_r():
>>       - purpose: main execution, common code
>>       - global_data is available
>>       - SDRAM is available
>>       - stack is optionally in SDRAM, if CONFIG_SPL_STACK_R is defined and
>>               points into SDRAM
>>       - preloader_console_init() can be called here - typically this is
>>               done by defining CONFIG_SPL_BOARD_INIT and then supplying a
>>               spl_board_init() function containing this call
>>       - loads U-Boot or (in falcon mode) Linux
>
> Seems to me that now SPL and non-SPL boot sequences are mostly similar
> in the name, order and purpose of the functions called (which is a good
> thing!) so maybe this sequence should be described in a single document
> rather than in doc/README.SPL? Just opening the discussion; I have no
> strong opinion on this.

Yes that is the idea. Yes I think it would be good to documentation
this more generally, although I wonder if we should wait until some
boards actually support this? :-)

Regards,
Simon