[U-Boot] [PATCH 03/12] omap5: Expand CONFIG_SPL_MAX_SIZE and comment upon SRAM_SCRATCH_SPACE_ADDR

[Tom Rini <trini@ti.com>]

On Wed, Aug 21, 2013 at 10:52:26AM +0530, Sricharan R wrote:
> Hi Tom,
> 
> On Tuesday 20 August 2013 06:23 PM, Tom Rini wrote:
> > After examining both TRMs and doing some experimentation, we can rely on
> > using the start of the download area for CONFIG_SPL_TEXT_BASE and then
> > move SRAM_SCRATCH_SPACE_ADDR up, just like am335x.  This is required for
> > peripheral boot modes such as UART.
> >
> > Signed-off-by: Tom Rini <trini@ti.com>
> > ---
> >  arch/arm/include/asm/arch-omap5/omap.h |   11 ++++++++++-
> >  include/configs/omap5_common.h         |    4 ++--
> >  2 files changed, 12 insertions(+), 3 deletions(-)
> >
> > diff --git a/arch/arm/include/asm/arch-omap5/omap.h b/arch/arm/include/asm/arch-omap5/omap.h
> > index 597c692..e9a51d3 100644
> > --- a/arch/arm/include/asm/arch-omap5/omap.h
> > +++ b/arch/arm/include/asm/arch-omap5/omap.h
> > @@ -153,6 +153,15 @@ struct s32ktimer {
> >  #define EFUSE_4 0x45145100
> >  #endif /* __ASSEMBLY__ */
> >  
> > +/*
> > + * In all cases, the TRM defines the RAM Memory Map for the processor
> > + * and indicates the area for the downloaded image.  We use all of that
> > + * space for download and once up and running may use other parts of the
> > + * map for our needs.  We set a scratch space that is at the end of the
> > + * OMAP5 download area, but within the DRA7xx download area (as it is
> > + * much larger) and do not, at this time, make use of the additional
> > + * space.
> > + */
> >  #ifdef CONFIG_DRA7XX
> >  #define NON_SECURE_SRAM_START	0x40300000
> >  #define NON_SECURE_SRAM_END	0x40380000	/* Not inclusive */
> > @@ -160,7 +169,7 @@ struct s32ktimer {
> >  #define NON_SECURE_SRAM_START	0x40300000
> >  #define NON_SECURE_SRAM_END	0x40320000	/* Not inclusive */
> >  #endif
> > -#define SRAM_SCRATCH_SPACE_ADDR	NON_SECURE_SRAM_START
> > +#define SRAM_SCRATCH_SPACE_ADDR	0x4031E000
> >  
> >  /* base address for indirect vectors (internal boot mode) */
> >  #define SRAM_ROM_VECT_BASE	0x4031F000
> > diff --git a/include/configs/omap5_common.h b/include/configs/omap5_common.h
> > index 8e82fed..0345c57 100644
> > --- a/include/configs/omap5_common.h
> > +++ b/include/configs/omap5_common.h
> > @@ -128,8 +128,8 @@
> >  
> >  
> >  /* Defines for SPL */
> > -#define CONFIG_SPL_TEXT_BASE		0x40300350
> > -#define CONFIG_SPL_MAX_SIZE		0x19000	/* 100K */
> > +#define CONFIG_SPL_TEXT_BASE		0x40300000
> > +#define CONFIG_SPL_MAX_SIZE		(0x4031E000 - CONFIG_SPL_TEXT_BASE)
> >  #define CONFIG_SPL_DISPLAY_PRINT
> >  #define CONFIG_SPL_LDSCRIPT "$(CPUDIR)/omap-common/u-boot-spl.lds"
> >  
> Ok, we keep the SPL stack at
> 
> #define CONFIG_SYS_INIT_SP_ADDR         (NON_SECURE_SRAM_END - GENERATED_GBL_DATA_SIZE)
> 
> So does this now create any possiblity of STACK overlap with the
> SCRATCH PAD area ? or since we have 8K at TOP, this is enough to avoid
> overlap ?

Yes, we should be fine here, from a quick look at the .su files we've
got around.

> Is it good to keep NON_SECURE_SRAM_END 0x4031E000 otherwise ?
> 
> Also with the base address change to 0x40300000, wanted to check this
> once on HS devices.  I can check this and let you know.

OK, thanks.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20130821/88d906dc/attachment.pgp>