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 _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
