[U-Boot] [PATCH] 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 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 */
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
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@lists.denx.de http://lists.denx.de/mailman/listinfo/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@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@lists.denx.de mailto:U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/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.
participants (4)
-
Enric Balletbo i Serra -
Enric Balletbo Serra -
Heiko Schocher -
Tom Rini