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

[Simon Glass]

Hi Tom,

On 4 March 2015 at 08:42, Tom Rini <trini at konsulko.com> wrote:
> 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.

Great, thanks for doing this!

Regards,
Simon