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 smallstack available. Since SPL sets up DRAM while in its board_init_f()function, it is possible for the stack to move there beforeboard_init_r() is reached. This option enables a special SDRAMlocation for the SPL stack. U-Boot SPL switches to this afterboard_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.