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

[Albert ARIBAUD]

Hello Simon,

On Mon, 19 Jan 2015 12:39:34 -0700, Simon Glass <sjg at chromium.org>
wrote:
> 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? :-)

Not sure I'm getting your point: waiting for a board to support this
may be a strongly preferred prerequisite for a custodian to apply the
patchset (it would be for me if that landed in my custody, at least);
but that does not prevent posting a v2 with a more complete boot
sequence documentation in a dedicated file.

> Regards,
> Simon

Amicalement,
-- 
Albert.