public inbox for u-boot@lists.denx.de
 help / color / mirror / Atom feed
* [U-Boot] [PATCH] igep00x0: Use all SRAM available for SPL.
@ 2016-04-26 15:05 Enric Balletbo i Serra
  2016-04-27  4:25 ` Heiko Schocher
  2016-04-27 13:36 ` Tom Rini
  0 siblings, 2 replies; 5+ messages in thread
From: Enric Balletbo i Serra @ 2016-04-26 15:05 UTC (permalink / raw)
  To: u-boot

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@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
+
 /*
  * Display CPU and Board information
  */
-- 
2.1.0

^ permalink raw reply related	[flat|nested] 5+ messages in thread

* [U-Boot] [PATCH] igep00x0: Use all SRAM available for SPL.
  2016-04-26 15:05 [U-Boot] [PATCH] igep00x0: Use all SRAM available for SPL Enric Balletbo i Serra
@ 2016-04-27  4:25 ` Heiko Schocher
  2016-04-27  7:00   ` Enric Balletbo Serra
  2016-04-27 13:36 ` Tom Rini
  1 sibling, 1 reply; 5+ messages in thread
From: Heiko Schocher @ 2016-04-27  4:25 UTC (permalink / raw)
  To: u-boot

Hello Enric,

Am 26.04.2016 um 17:05 schrieb Enric Balletbo i Serra:
> 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@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

Hmm... risky, as the SPL needs at last some bytes for stack, until
RAM is initialized and stack moved to it ... or do I miss something?

bye,
Heiko
-- 
DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany

^ permalink raw reply	[flat|nested] 5+ messages in thread

* [U-Boot] [PATCH] igep00x0: Use all SRAM available for SPL.
  2016-04-27  4:25 ` Heiko Schocher
@ 2016-04-27  7:00   ` Enric Balletbo Serra
  2016-04-27  7:23     ` Heiko Schocher
  0 siblings, 1 reply; 5+ messages in thread
From: Enric Balletbo Serra @ 2016-04-27  7:00 UTC (permalink / raw)
  To: u-boot

Hi Heiko,

2016-04-27 6:25 GMT+02:00 Heiko Schocher <hs@denx.de>:
> Hello Enric,
>
> Am 26.04.2016 um 17:05 schrieb Enric Balletbo i Serra:
>>
>> 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@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
>
>
> Hmm... risky, as the SPL needs at last some bytes for stack, until
> RAM is initialized and stack moved to it ... or do I miss something?
>

This is what I thought, orginally I thought

  CONFIG_SPL_MAX_SIZE            (60*1024) /* 4KB for stack */

But then I saw that overo and logic boards set

  CONFIG_SPL_MAX_SIZE    (64 * 1024)

I send this version just to have some discussion. So, can we say that overo
and logic boards are incorrect too (or at least risky)? And, Tom proposed a
4KB stack, do you think it's enough?

Regards,
 Enric

> bye,
> Heiko
> --
> DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
> HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
>
> _______________________________________________
> U-Boot mailing list
> U-Boot at lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot

^ permalink raw reply	[flat|nested] 5+ messages in thread

* [U-Boot] [PATCH] igep00x0: Use all SRAM available for SPL.
  2016-04-27  7:00   ` Enric Balletbo Serra
@ 2016-04-27  7:23     ` Heiko Schocher
  0 siblings, 0 replies; 5+ messages in thread
From: Heiko Schocher @ 2016-04-27  7:23 UTC (permalink / raw)
  To: u-boot

Hello Enric,

Am 27.04.2016 um 09:00 schrieb Enric Balletbo Serra:
> Hi Heiko,
>
> 2016-04-27 6:25 GMT+02:00 Heiko Schocher <hs at denx.de <mailto:hs@denx.de>>:
>  > Hello Enric,
>  >
>  > Am 26.04.2016 um 17:05 schrieb Enric Balletbo i Serra:
>  >>
>  >> 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@collabora.com
> <mailto:enric.balletbo@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
>  >
>  >
>  > Hmm... risky, as the SPL needs at last some bytes for stack, until
>  > RAM is initialized and stack moved to it ... or do I miss something?
>  >
>
> This is what I thought, orginally I thought
>
>    CONFIG_SPL_MAX_SIZE            (60*1024) /* 4KB for stack */
>
> But then I saw that overo and logic boards set
>
>    CONFIG_SPL_MAX_SIZE    (64 * 1024)
>
> I send this version just to have some discussion. So, can we say that overo and logic boards are
> incorrect too (or at least risky)? And, Tom proposed a 4KB stack, do you think it's enough?

I would say risky. How many stack you need, depends on what tasks SPL
has to do ...

May you try to move the stack into RAM?
Then you need less then 4k for the initial stack in SPL ...

You may want to look into:
CONFIG_SPL_STACK_R_ADDR
CONFIG_SPL_STACK_R

defines ...

bye,
Heiko
>
> Regards,
>   Enric
>
>  > bye,
>  > Heiko
>  > --
>  > DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
>  > HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
>  >
>  > _______________________________________________
>  > U-Boot mailing list
>  > U-Boot at lists.denx.de <mailto:U-Boot@lists.denx.de>
>  > http://lists.denx.de/mailman/listinfo/u-boot

-- 
DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany

^ permalink raw reply	[flat|nested] 5+ messages in thread

* [U-Boot] [PATCH] igep00x0: Use all SRAM available for SPL.
  2016-04-26 15:05 [U-Boot] [PATCH] igep00x0: Use all SRAM available for SPL Enric Balletbo i Serra
  2016-04-27  4:25 ` Heiko Schocher
@ 2016-04-27 13:36 ` Tom Rini
  1 sibling, 0 replies; 5+ messages in thread
From: Tom Rini @ 2016-04-27 13:36 UTC (permalink / raw)
  To: u-boot

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@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>

^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2016-04-27 13:36 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2016-04-26 15:05 [U-Boot] [PATCH] igep00x0: Use all SRAM available for SPL Enric Balletbo i Serra
2016-04-27  4:25 ` Heiko Schocher
2016-04-27  7:00   ` Enric Balletbo Serra
2016-04-27  7:23     ` Heiko Schocher
2016-04-27 13:36 ` Tom Rini

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox