[U-Boot] kirkwood: CONFIG_SYS_INIT_SP_ADDR wrong?

[Heiko Schocher <hs@denx.de>]

Hello Daniel,

Daniel Hobi wrote:
> In commit 0b20ed76 (Kirkwood: Changes specific to ARM relocation
> support), you set CONFIG_SYS_INIT_SP_ADDR to 0xC8012000 which is
> supposed to lie within the internal Security SRAM.
> 
> However, the Kirkwood Functional Specification (chapter 2.13 Default
> Address Map) and arch/arm/include/asm/arch-kirkwood/cpu.h suggest that
> the Security SRAM is mapped to 0xC8010000. Given the size of 2 KiB, the
> upper end would be 0xC8010800.
> 
> So I am wondering whether the value 0xC8012000 works at all.
> 
> In addition, "CONFIG_SYS_INIT_SP_ADDR should point to RAM with enough
> space for global data above and enough stack space below", as Reinhard
> Meyer points out in:
> 
> http://article.gmane.org/gmane.comp.boot-loaders.u-boot/87490
> 
> Since you use quite a large print buffer (CONFIG_SYS_PBSIZE > 1 KiB), I
> assume something like 0xC8010700 might work.
> 
> @Heiko: include/configs/km_arm.h may have the same problem.

I made a patch for this, see:

http://lists.denx.de/pipermail/u-boot/2010-November/081275.html

but you are right, looking in Kirkwood Functional Specification
(chapter 2.13 Default Address Map) internal Security SRAM is mapped
from 0xc8010000-0xc801ffff with the note, that only 2kb sram are
implemented) ... so your question is right, why this is working ...
I just can say, it works on the suen3 ... Prafulla, do you have
an idea for this (maybe the sram is mirrored?)

bye,
Heiko
-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany