[U-Boot] Question on the max size of SPL and OMAP3 SRAM

[U-Boot] Question on the max size of SPL and OMAP3 SRAM

[Adam Lee]

I have a Gumstix Overo (OMAP3) with a 512MiB NAND. I have been validating
BCH8 ecc scheme and one of the problems I ran into is this:

arm-linux-gnueabi-ld.bfd: u-boot-spl section `.rodata' will not fit in
region `.sram'
arm-linux-gnueabi-ld.bfd: region `.sram' overflowed by 4092 bytes


This happens because BCH8 support increases the size of my SPL to larger
than 54KiB  defined by CONFIG_SPL_MAX_SIZE in ti_omap3_common.h.

My plan at the moment is to strip out unnecessary and unpopular features
from SPL to save space. If I fail to fit my SPL under 54kiB, I'd like to
know if it is safe to increase the size defined by config.

As per README.omap3, there is about 9KB (0x4020E000 - 0x4020BBFF) of
unallocated space between the SPL data and SPL stack:

Option 2 (SPL or X-Loader):
0x40200800 - 0x4020BBFF: Area for SPL text, data and rodata
0x4020E000 - 0x4020FFFC: Area for the SPL stack.


Is this space being used for something? I'm sure there have been a good
reason for this division. I would like to have some insight as to how and
why.

Thanks,

Adam

[U-Boot] Question on the max size of SPL and OMAP3 SRAM

[Tom Rini]

On Tue, Feb 17, 2015 at 04:47:14PM -0800, Adam Lee wrote:
> I have a Gumstix Overo (OMAP3) with a 512MiB NAND. I have been validating
> BCH8 ecc scheme and one of the problems I ran into is this:
> 
> arm-linux-gnueabi-ld.bfd: u-boot-spl section `.rodata' will not fit in
> region `.sram'
> arm-linux-gnueabi-ld.bfd: region `.sram' overflowed by 4092 bytes
> 
> 
> This happens because BCH8 support increases the size of my SPL to larger
> than 54KiB  defined by CONFIG_SPL_MAX_SIZE in ti_omap3_common.h.
> 
> My plan at the moment is to strip out unnecessary and unpopular features
> from SPL to save space. If I fail to fit my SPL under 54kiB, I'd like to
> know if it is safe to increase the size defined by config.

This is probably your best bet.  My hope is that as part of moving to
Kconfig we can make these support choices easier.

> As per README.omap3, there is about 9KB (0x4020E000 - 0x4020BBFF) of
> unallocated space between the SPL data and SPL stack:
> 
> Option 2 (SPL or X-Loader):
> 0x40200800 - 0x4020BBFF: Area for SPL text, data and rodata
> 0x4020E000 - 0x4020FFFC: Area for the SPL stack.
> 
> 
> Is this space being used for something? I'm sure there have been a good
> reason for this division. I would like to have some insight as to how and
> why.

Well, the best answer is to check the TRM and see what it says about the
ROM memory map.  My recollection is that 0x40200800 - 0x4020BBFF is the
download area and 0x4020E000 - 0x4020FFFC is what it calls the public
stack and we decide to use it for our stack (rather than keeping it in
the download area).  The range inbetween (0x4020BC00 - 0x4020DFFF) is
claimed by the ROM and we shouldn't touch it.

Unless the TRM says something different of course.

> 
> Thanks,
> 
> Adam
> _______________________________________________
> U-Boot mailing list
> U-Boot at lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot

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

[U-Boot] Question on the max size of SPL and OMAP3 SRAM

[Ash Charles]

Hi Tom,
On Wed, Feb 18, 2015 at 10:32 AM, Tom Rini <trini@ti.com> wrote:
> Well, the best answer is to check the TRM and see what it says about the
> ROM memory map.  My recollection is that 0x40200800 - 0x4020BBFF is the
> download area and 0x4020E000 - 0x4020FFFC is what it calls the public
> stack and we decide to use it for our stack (rather than keeping it in
> the download area).  The range inbetween (0x4020BC00 - 0x4020DFFF) is
> claimed by the ROM and we shouldn't touch it.
I just had a look at the "64KB RAM Memory Map of GP Devices" in the
TRMs for AM/DM37xx, and OMAP3530.

The download area starts out 0x4020 0000---I can't find any history on
the 0x800 offset to 0x40200800 (the value comes from some very early
x-loader commits).  Moving CONFIG_SPL_TEXT_BASE to 0x4020 0000 buys 2
kB extra and seems (lightly tested) to work okay on a couple different
Overos.

According to the TRM, the download area extends up to 0x4020 F000
followed by a ~3 kB public stack from 0x4020F000 to 0x4020FCB0.  The
area between 0x4020FCB0 and 0x4020FFF contains 'reserved', 'tracing
data', and 'RAM exception vectors' sections---I'm guessing these are
fair game as these are just how the ROM code chooses to use the
memory?

Looking at doc/SPL/README.omap3, both possible configurations match
your email i.e.
0x40200800 - 0x4020BBFF: Area for SPL text, data and rodata
0x4020E000 - 0x4020FFFC: Area for the SPL stack.

Based on u-boot-spl.lds though, I think the first area would be
[CONFIG_SPL_TEXT_BASE - (CONFIG_SPL_TEXT_BASE + CONFIG_SPL_MAX_SIZE)]
(default: 0x40200800 - 0x4020e000)

The stack seems to be defined by CONFIG_SPL_STACK used in
arch/arm/lib/crt0.S.  On most platforms, this seems to point to an
area in SDRAM, not SRAM.  How can this work before RAM is setup?

In short: does this seem reasonable?
#define CONFIG_SPL_TEXT_BASE 0x40200000
#define CONFIG_SPL_MAX_SIZE (64*1024)

Thanks for any insight,
--Ash