* [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