I am trying to track down the memory map and what I believe to be some memory corruption in SPL.
I have a few findings that I am not sure are issues or not, so I am hoping someone who know the OMAP3 family better might shed some light on it.
Looking at README.omap3, I can see two suggested maps, one for SPL and one for SPL & X-Loader. It shows SRAM 0x40200000 - 0x4020FFFF. Both of tables show:
0x40200800 - 0x4020BBFF: Area for SPL text, data and rodata 0x4020E000 - 0x4020FFFC: Area for the SPL stack.
Looking at arch/arm/include/asm/arch-omap3/omap.h, it seems like it's defining the beginning of SRAM to be NON_SECURE_SRAM_START 0x40208000
I wonder if this should be 0x40200800 instead.?
Question 2:
That same file defines SRAM_SCRATCH_SPACE_ADDR as the top 1K of RAM down from NON_SECURE_SRAM_IMG_END
We then point OMAP3_PUBLIC_SRAM_SCRATCH_AREA to NON_SECURE_SRAM_START I am wondering if OMAP3_PUBLIC_SRAM_SCRATCH_AREA should point to SRAM_SCRATCH_SPACE_ADDR instead.
Currently, the reference to OMAP3_PUBLIC_SRAM_SCRATCH_AREA is checked in arch/arm/mach-omap2/boot-common.c aginst NON_SECURE_SRAM_START and NON_SECURE_SRAM_END to make sure the data is inside a valid memory address. Since OMAP3_PUBLIC_SRAM_SCRATCH_AREA is already defined to be NON_SECURE_SRAM_START, this comparison seems like it would be unnecessary, however if we're going to point boot_params to this address it seems like other data written/stored to NON_SECURE_SRAM_START would be over written. I think it would be safer to point SRAM_SCRATCH_SPACE_ADDR so we don't clobber data that the linker may be putting there.
Any thoughts?
Third Question:
I noticed a bunch of boards, including my own, un-define CONFIG_SPL_TEXT_BASE and redefine it to 0x40200000. It seems like it would give us 2k of SRAM. I 'think' making all boards use 0x40200000 instead of 40200800 is a bad idea, especially for secure parts. Since there is a flag called CONFIG_TI_SECURE_DEVICE. I would like to propse using it to set the CONFIG_SPL_TEXT_BASE to 0x40200000 if is not set. Would that be acceptable? This way, we can dump the extra lines of code in the board files hat undef this and redefine it.
I also wonder if the same could be said about NON_SECURE_SRAM_START depending on th answers to questions 1 and 3.
I have more questions, but I'll start there.
Thanks
adam