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