public inbox for u-boot@lists.denx.de
 help / color / mirror / Atom feed
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>

  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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox