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