Skip to contentSkip to conversation

igep00x0: Use all SRAM available for SPL.

PATCH New Enric Balletbo i Serra 4 participants 5 messages Apr 26, 2016 – Apr 27, 2016

lore
Share & tools
lore

Enric Balletbo i Serra

author
#0 lore raw

PATCH 1/1 igep00x0: Use all SRAM available for SPL.

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 <[email protected]>
---
 include/configs/omap3_igep00x0.h | 7 +++++++
 1 file changed, 7 insertions(+)
include/configs/omap3_igep00x0.h +7 -0
index 5da50a5..2459064 100644
@@ -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
  */
Signature · 1 line
2.1.0
#1 lore raw

PATCH 1/1 igep00x0: Use all SRAM available for SPL.

Hello Enric,

Am 26.04.2016 um 17:05 schrieb Enric Balletbo i Serra:

Quoted 14 lines

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 <[email protected]>
---
  include/configs/omap3_igep00x0.h | 7 +++++++
  1 file changed, 7 insertions(+)
include/configs/omap3_igep00x0.h +0 -0
index 5da50a5..2459064 100644

include/configs/omap3_igep00x0.h line 27

Quoted 9 lines
include/configs/omap3_igep00x0.h +6 -0
@@ -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

Signature · 2 lines
DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
#2 lore raw

PATCH 1/1 igep00x0: Use all SRAM available for SPL.

Hi Heiko,

2016-04-27 6:25 GMT+02:00 Heiko Schocher <[email protected]>:

Quoted 22 lines

Hello Enric,

Am 26.04.2016 um 17:05 schrieb Enric Balletbo i Serra:

Quoted 19 lines

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 <[email protected]>
---
  include/configs/omap3_igep00x0.h | 7 +++++++
  1 file changed, 7 insertions(+)
include/configs/omap3_igep00x0.h +0 -0
index 5da50a5..2459064 100644
@@ -19,6 +19,13 @@
  #include <configs/ti_omap3_common.h>
  #include <asm/mach-types.h>
Quoted 11 lines

include/configs/omap3_igep00x0.h line 27

Quoted 6 lines
include/configs/omap3_igep00x0.h +6 -0
+/* 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

Quoted 10 lines

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

#3 lore raw

PATCH 1/1 igep00x0: Use all SRAM available for SPL.

Hello Enric,

Am 27.04.2016 um 09:00 schrieb Enric Balletbo Serra:

Quoted 40 lines

Hi Heiko,

2016-04-27 6:25 GMT+02:00 Heiko Schocher <hs at denx.de <mailto:[email protected]>>:

Quoted 9 lines

Hello Enric,

Am 26.04.2016 um 17:05 schrieb Enric Balletbo i Serra:

Quoted 6 lines

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 <[email protected]

<mailto:[email protected]>>

Quoted 13 lines
Quoted 13 lines
---
  include/configs/omap3_igep00x0.h | 7 +++++++
  1 file changed, 7 insertions(+)
include/configs/omap3_igep00x0.h +0 -0
index 5da50a5..2459064 100644
@@ -19,6 +19,13 @@
  #include <configs/ti_omap3_common.h>
  #include <asm/mach-types.h>
Quoted 11 lines

include/configs/omap3_igep00x0.h line 27

Quoted 6 lines
include/configs/omap3_igep00x0.h +6 -0
+/* 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

Quoted 8 lines
   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

Quoted 14 lines

Regards,
Enric

Quoted 10 lines

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:[email protected]>
http://lists.denx.de/mailman/listinfo/u-boot

Signature · 2 lines
DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
#4 lore raw

PATCH 1/1 igep00x0: Use all SRAM available for SPL.

In reply to Enric Balletbo i Serra
Quoted 14 lines · 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 <[email protected]>
---
 include/configs/omap3_igep00x0.h | 7 +++++++
 1 file changed, 7 insertions(+)
include/configs/omap3_igep00x0.h +0 -0
index 5da50a5..2459064 100644

include/configs/omap3_igep00x0.h line 27

Quoted 9 lines
include/configs/omap3_igep00x0.h +6 -0
@@ -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.

Signature · 8 lines
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>