From mboxrd@z Thu Jan  1 00:00:00 1970
From: =?ISO-8859-1?Q?Andreas_Bie=DFmann?= <andreas.devel@googlemail.com>
Date: Fri, 01 Jul 2011 11:55:40 +0200
Subject: [U-Boot] [RFC PATCH 6/7] omap: common spl support for OMAP3/4
In-Reply-To: <4E0D9314.4050001@ti.com>
References: <BANLkTim9AE2aszKLiDH53vd+Hjpz7GVoNA@mail.gmail.com>
	<1309352967-5719-7-git-send-email-aneesh@ti.com>
	<4E0C113B.3070303@denx.de> <4E0C13D0.5040001@ti.com>
	<461E70CA-D429-4E3E-A43D-E28F71B35631@googlemail.com>
	<4E0D9314.4050001@ti.com>
Message-ID: <4E0D999C.1050209@gmail.com>
List-Id: <u-boot.lists.denx.de>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
To: u-boot@lists.denx.de

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<aneesh@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