From: Tom Rini <trini@konsulko.com>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH v6 4/6] arm: spl: Allow board_init_r() to run with a larger stack
Date: Tue, 3 Mar 2015 15:14:59 -0500 [thread overview]
Message-ID: <20150303201459.GL25373@bill-the-cat> (raw)
In-Reply-To: <CAPnjgZ1nKU9NUVXkt7uGdUvxEb=GHYr8Knr2t9HgiO2-E4moDA@mail.gmail.com>
On Tue, Mar 03, 2015 at 12:04:16PM -0700, Simon Glass wrote:
> Hi Tom,
>
> On 3 March 2015 at 10:49, Tom Rini <trini@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.
> >>
> >> Signed-off-by: Simon Glass <sjg@chromium.org>
> >> For version 1:
> >> Acked-by: Albert ARIBAUD <albert.u.boot@aribaud.net>
> >> Reviewed-by: Stefan Roese <sr@denx.de>
> >> Tested-by: Bo Shen <voice.shen@atmel.com>
> >> Acked-by: Bo Shen <voice.shen@atmel.com>
> >> Acked-by: Heiko Schocher <hs@denx.de>
> >> Tested-by: Heiko Schocher <hs@denx.de>
> >> ---
> >>
> >> Changes in v6: None
> >> Changes in v5:
> >> - Rebase to master
> >>
> >> Changes in v4:
> >> - Adjust README to mention that lowlevel_init() should have no stack
> >>
> >> Changes in v3: None
> >> Changes in v2:
> >> - Move docs to top-level README file and expand them to cover U-Boot proper
> >> - Add Kconfig settings
> >>
> >> Kconfig | 18 ++++++++++++++
> >> README | 69 +++++++++++++++++++++++++++++++++++++++++++++++++++++
> >> arch/arm/lib/crt0.S | 13 +++++++---
> >> common/spl/spl.c | 35 +++++++++++++++++++++++++++
> >> 4 files changed, 132 insertions(+), 3 deletions(-)
> > [snip]
> >> diff --git a/arch/arm/lib/crt0.S b/arch/arm/lib/crt0.S
> >> index 22df3e5..7939ced 100644
> >> --- a/arch/arm/lib/crt0.S
> >> +++ b/arch/arm/lib/crt0.S
> >> @@ -113,7 +113,14 @@ here:
> >> /* Set up final (full) environment */
> >>
> >> bl c_runtime_cpu_setup /* we still call old routine here */
> >> -
> >> +#endif
> >> +#if !defined(CONFIG_SPL_BUILD) || defined(CONFIG_SPL_FRAMEWORK)
> >> +# ifdef CONFIG_SPL_BUILD
> >> + /* Use a DRAM stack for the rest of SPL, if requested */
> >> + bl spl_relocate_stack_gd
> >> + cmp r0, #0
> >> + movne sp, r0
> >> +# endif
> >> ldr r0, =__bss_start /* this is auto-relocated! */
> >> ldr r1, =__bss_end /* this is auto-relocated! */
> >>
> >> @@ -124,9 +131,10 @@ clbss_l:cmp r0, r1 /* while not at end of BSS */
> >> addlo r0, r0, #4 /* move to next */
> >> blo clbss_l
> >>
> >> +#if ! defined(CONFIG_SPL_BUILD)
> >> bl coloured_LED_init
> >> bl red_led_on
> >> -
> >> +#endif
> >> /* call board_init_r(gd_t *id, ulong dest_addr) */
> >> mov r0, r9 /* gd_t */
> >> ldr r1, [r9, #GD_RELOCADDR] /* dest_addr */
> >> @@ -134,7 +142,6 @@ clbss_l:cmp r0, r1 /* while not at end of BSS */
> >> ldr pc, =board_init_r /* this is auto-relocated! */
> >>
> >> /* we should not return here. */
> >> -
> >> #endif
> >>
> >> ENDPROC(_main)
> >> diff --git a/common/spl/spl.c b/common/spl/spl.c
> >> index ded0f30..cd75bbc 100644
> >> --- a/common/spl/spl.c
> >> +++ b/common/spl/spl.c
> >> @@ -281,3 +281,38 @@ void preloader_console_init(void)
> >> spl_display_print();
> >> #endif
> >> }
> >> +
> >> +/**
> >> + * spl_relocate_stack_gd() - Relocate stack ready for board_init_r() execution
> >> + *
> >> + * Sometimes board_init_f() runs with a stack in SRAM but we want to use SDRAM
> >> + * for the main board_init_r() execution. This is typically because we need
> >> + * more stack space for things like the MMC sub-system.
> >> + *
> >> + * This function calculates the stack position, copies the global_data into
> >> + * place and returns the new stack position. The caller is responsible for
> >> + * setting up the sp register.
> >> + *
> >> + * @return new stack location, or 0 to use the same stack
> >> + */
> >> +ulong spl_relocate_stack_gd(void)
> >> +{
> >> +#ifdef CONFIG_SPL_STACK_R
> >> + gd_t *new_gd;
> >> + ulong ptr;
> >> +
> >> + /* Get stack position: use 8-byte alignment for ABI compliance */
> >> + ptr = CONFIG_SPL_STACK_R - sizeof(gd_t);
> >> + ptr &= ~7;
> >> + new_gd = (gd_t *)ptr;
> >> + memcpy(new_gd, (void *)gd, sizeof(gd_t));
> >> + gd = new_gd;
> >> +
> >> + /* Clear the BSS. */
> >> + memset(__bss_start, 0, __bss_end - __bss_start);
> >> +
> >> + return ptr;
> >> +#else
> >> + return 0;
> >> +#endif
> >> +}
> >
> > All of this _does_ move gd into where CONFIG_SPL_STACK_R points. It
> > does _not_ move the stack itself into where CONFIG_SPL_STACK_R points so
> > the big use case (am335x_boneblack for example where
> > CONFIG_SPL_ENV_SUPPORT is set) doesn't work and blows up as we overflow
> > the area for stack.
>
> OK I'll have to test more. What sort of problem should i see?
We hang on entering env_reloc_spec() which is what puts some big sized
variables on the stack.
> The return value from spl_relocate_stack_gd() should be shoved into
> sp. Does that not happen?
It doesn't appear to be. I hadn't broken out the BBB with JTAG tho.
--
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/20150303/d24e864e/attachment.sig>
next prev parent reply other threads:[~2015-03-03 20:14 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-03-03 15:02 [U-Boot] [PATCH v6 0/6] Clean out SPL and enable driver model Simon Glass
2015-03-03 15:02 ` [U-Boot] [PATCH v6 1/6] arm: Reduce the scope of lowlevel_init() Simon Glass
2015-03-04 22:16 ` Tom Rini
2015-03-03 15:02 ` [U-Boot] [PATCH v6 2/6] arm: spl: Avoid setting up a duplicate global data structure Simon Glass
2015-03-04 22:16 ` Tom Rini
2015-03-03 15:02 ` [U-Boot] [PATCH v6 3/6] dm: tegra: Enable driver model in SPL and adjust the GPIO driver Simon Glass
2015-03-04 22:16 ` Tom Rini
2015-03-08 21:00 ` Stephen Warren
2015-03-09 17:04 ` Simon Glass
2015-03-09 17:23 ` Stephen Warren
2015-03-10 1:15 ` Simon Glass
2015-03-03 15:03 ` [U-Boot] [PATCH v6 4/6] arm: spl: Allow board_init_r() to run with a larger stack Simon Glass
2015-03-03 17:49 ` Tom Rini
2015-03-03 19:04 ` Simon Glass
2015-03-03 20:14 ` Tom Rini [this message]
2015-03-04 3:23 ` Simon Glass
2015-03-04 13:38 ` Tom Rini
2015-03-04 15:10 ` Tom Rini
2015-03-04 15:42 ` Tom Rini
2015-03-04 19:14 ` Simon Glass
2015-03-04 22:16 ` Tom Rini
2015-03-03 15:03 ` [U-Boot] [PATCH v6 5/6] Make export interface support CONFIG_SYS_MALLOC_SIMPLE Simon Glass
2015-03-04 22:16 ` Tom Rini
2015-03-03 15:03 ` [U-Boot] [PATCH v6 6/6] ti: armv7: am33xx: Move SPL SDRAM into the correct place Simon Glass
2015-03-03 15:15 ` Tom Rini
2015-03-03 15:17 ` Simon Glass
2015-03-04 16:30 ` [U-Boot] [PATCH v7 6/6] ti: armv7: Move SPL SDRAM init to the right place, drop unused CONFIG_SPL_STACK Tom Rini
2015-03-04 19:07 ` Simon Glass
2015-03-04 22:16 ` Tom Rini
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20150303201459.GL25373@bill-the-cat \
--to=trini@konsulko.com \
--cc=u-boot@lists.denx.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.