Dear Aneesh,
Am 01.07.2011 11:27, schrieb Aneesh V:
Dear Andreas,
On Thursday 30 June 2011 12:38 PM, Andreas Bießmann wrote:
Dear Aneesh V,
Am 30.06.2011 um 08:12 schrieb Aneesh V:
Hi Heiko,
On Thursday 30 June 2011 11:31 AM, Heiko Schocher wrote:
Hello Aneesh,
Aneesh V wrote:
Signed-off-by: Aneesh Vaneesh@ti.com
<snip>
diff --git a/arch/arm/cpu/armv7/omap-common/spl.c b/arch/arm/cpu/armv7/omap-common/spl.c new file mode 100644 index 0000000..b5a5f3c --- /dev/null +++ b/arch/arm/cpu/armv7/omap-common/spl.c
[...]
@@ -0,0 +1,56 @@ +void board_init_f(ulong dummy) +{
- debug(">>board_init_f()\n");
- relocate_code(CONFIG_SYS_SPL_STACK,&gdata,
CONFIG_SYS_SPL_TEXT_BASE);
- debug("<<board_init_f()\n");
<snip>
BTW: Do you really need to relocate code? You could just load the 2nd stage loader to ram from board_init_f, or?
I am passing the same address as I am executing from as the target for the relocation, so the relocation will not happen, instead BSS will be initialized. That's what I am calling it for. Initially I had my own routine for clearing BSS. Then I decided to re-use it from start.S
So you could just call clear_bss(void) and skip relocate_code. But I think you need to adopt the __bss_start_ofs, __bss_end_ofs markers, cause your linker skript places them in SDRAM.
Is that really needed, or is it ok to just comment this fact clearly as Heiko suggested?
No, it is not needed to call clear_bss() directly. I think commenting the fact, that passing same source and target address will skip the relocation stuff would be also OK here.
But the second part is not clear to me. I saw in your linker, that bss is placed in SDRAM. In start.S the boundaries for clear_bss are calculated at compile time to
---8<--- _bss_start_ofs: .word __bss_start - _start --->8---
Will that also work with e.g. SDRAM adress space is before SRAM, SDRAM addressing is far away (> 4GiB) ... So in you special case it may work, but if this is a blueprint for SPL on arm(v7) we should consider this.
BTW: I think Simon Schwarz is also working on this, can one comment on his first version of patchset?
We have decided to co-ordinate our work so that there won't be any duplication of efforts. As per this plan, these parts will be taken care in my OMAP4 MMC spl series and then he will extend it for OMAP3 and NAND.
I'm fine with that. ;)
regards
Andreas Bießmann