[U-Boot] [PATCH] igep00x0: Use all SRAM available for SPL.

[Tom Rini]

On Tue, Apr 26, 2016 at 05:05:33PM +0200, Enric Balletbo i Serra wrote:
> Internal SRAM starts at 0x40200000 and ends at 0x4020FFFF, so there
> are 64KB available to be used for SPL. This will also help some
> compilers to fit all the code into the allocated space.
> 
> Signed-off-by: Enric Balletbo i Serra <enric.balletbo at collabora.com>
> ---
>  include/configs/omap3_igep00x0.h | 7 +++++++
>  1 file changed, 7 insertions(+)
> 
> diff --git a/include/configs/omap3_igep00x0.h b/include/configs/omap3_igep00x0.h
> index 5da50a5..2459064 100644
> --- a/include/configs/omap3_igep00x0.h
> +++ b/include/configs/omap3_igep00x0.h
> @@ -19,6 +19,13 @@
>  #include <configs/ti_omap3_common.h>
>  #include <asm/mach-types.h>
>  
> +/* SRAM starts at 0x40200000 and ends at 0x4020FFFF (64KB) */
> +#undef CONFIG_SPL_MAX_SIZE
> +#undef CONFIG_SPL_TEXT_BASE
> +
> +#define CONFIG_SPL_MAX_SIZE		(64*1024)
> +#define CONFIG_SPL_TEXT_BASE		0x40200000

So yes, there are a few other examples of this, but, it's wrong.  I'm
pulling up the OMAP35x TRM (rev T) but this applies to all omap3 (and
am35x) variants.  The download space is from 0x40200000 - 0x4020F000.
Going past that will result in any number of bad things happening, all
of which are a failure (we would first go into the "public stack" which
is what ROM uses, if it even allows us to download something so large).
This would be 60KiB.  Next, we default to 0x40200800 as the text base
for (I believe) compatibility with HS parts.  So in your case (as well
as well as the other parts which override this) you know this isn't a
concern and you can change it down to 0x40200000.

That brings us to the concern about stack space.  In doc/README.SPL we
document how to use the '.su' files that are generated by the compiler
and 'cflow' to get a reasonable idea on how much stack space we need.
If you aren't sure if you can use 4KiB, then yes, as Heiko mentions, you
should use CONFIG_SPL_STACK_R / CONFIG_SPL_STACK_R_ADDR to point into
DDR so that we use the 4KiB CONFIG_SYS_INIT_SP_ADDR space for just very
early things.

But wait, there's more (sigh).  We need to keep a small amount of
scratch space in SRAM available for a "scratch pad" of sorts.  For all
of the details / uses, check out 'git grep OMAP_SRAM_SCRATCH_' but in
sum, today we say that on OMAP3 this area starts at 0x4020E000.  Based
on what we have done for OMAP4 (See dcc23576) we could at least safely
move this up into the "public stack" area instead.

So, in sum, for today, the only safe things you can do for igep00x0 is
to move CONFIG_SPL_TEXT_BASE down to 0x40200000 and set
CONFIG_SPL_MAX_SIZE to (SRAM_SCRATCH_SPACE_ADDR - CONFIG_SPL_TEXT_BASE)
(so that it's clear what the limit is).

My plan for v2016.07 is to move OMAP3 (and finish OMAP4/5/etc/related)
to having the SPL max size be the public download area and compatible
with HS when possible and move scratch space to the "public stack" area
and use CONFIG_SPL_STACK_R / CONFIG_SPL_STACK_R_ADDR.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20160427/ab8114fc/attachment.sig>