Hi Albert, On 18 January 2015 at 23:54, Albert ARIBAUD <albert.u.b...@aribaud.net> wrote: > Hello Simon, > > On Sun, 18 Jan 2015 11:55:36 -0700, Simon Glass <s...@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 _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
