[U-Boot] Question on the max size of SPL and OMAP3 SRAM
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
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@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
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
participants (3)
-
Adam Lee -
Ash Charles -
Tom Rini