From mboxrd@z Thu Jan 1 00:00:00 1970 From: Albert ARIBAUD Date: Tue, 20 Jan 2015 07:46:25 +0100 Subject: [U-Boot] [PATCH] arm: spl: Allow board_init_r() to run with a larger stack In-Reply-To: References: <1421607336-26934-1-git-send-email-sjg@chromium.org> <20150119075458.5875bdc9@lilith> Message-ID: <20150120074625.13a26368@lilith> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de Hello Simon, On Mon, 19 Jan 2015 12:39:34 -0700, Simon Glass wrote: > Hi Albert, > > On 18 January 2015 at 23:54, Albert ARIBAUD wrote: > > Hello Simon, > > > > On Sun, 18 Jan 2015 11:55:36 -0700, Simon Glass > > 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.