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

[Tom Rini <trini@konsulko.com>]

On Tue, Mar 03, 2015 at 08:03:00AM -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 documented in the README.
[snip]
> diff --git a/Kconfig b/Kconfig
> index 91a0618..8de731d 100644
> --- a/Kconfig
> +++ b/Kconfig
> @@ -96,6 +96,24 @@ config SPL
>  	help
>  	  If you want to build SPL as well as the normal image, say Y.
>  
> +config CONFIG_SPL_STACK_R
> +	depends on SPL
> +	bool "Enable SDRAM location for SPL stack"
> +	help
> +	  SPL starts off execution in SRAM and thus typically has only a small
> +	  stack available. Since SPL sets up DRAM while in its board_init_f()
> +	  function, it is possible for the stack to move there before
> +	  board_init_r() is reached. This option enables a special SDRAM
> +	  location for the SPL stack. U-Boot SPL switches to this after
> +	  board_init_f() completes, and before board_init_r() starts.
> +
> +config CONFIG_SPL_STACK_R_ADDR
> +	depends on CONFIG_SPL_STACK_R

I found my problem!  Incorrect Kconfig syntax, no CONFIG_ in 'config' or
'depends' lines only help lines.  So I was right in that my stack wasn't
moving because I was doing it via the defconfig and that was broken :)

I'm just going to pick up 1-5 (with this fixed) and send out my own 6
after I test it on omap3 and omap4/5 which also need a similar
conversion.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20150304/50169024/attachment.sig>