[U-Boot] U-Boot OMAP3 memory map potential issues/questions

[Adam Ford]

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