From mboxrd@z Thu Jan  1 00:00:00 1970
From: Albert ARIBAUD <albert.u.boot@aribaud.net>
Date: Sun, 03 Jul 2011 09:48:37 +0200
Subject: [U-Boot] [RFC PATCH 6/7] omap: common spl support for OMAP3/4
In-Reply-To: <58A653AE-B886-457A-AEA4-4918D2EE951C@googlemail.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>
	<4E0D999C.1050209@gmail.com> <4E0DB41B.5010709@ti.com>
	<4E0E2542.8010500@aribaud.net> <4E0FF45C.4060707@ti.com>
	<4E1012BA.3040004@aribaud.net>
	<58A653AE-B886-457A-AEA4-4918D2EE951C@googlemail.com>
Message-ID: <4E101ED5.4010708@aribaud.net>
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

Le 03/07/2011 09:31, Andreas Bie?mann a ?crit :
> Dear Albert Aribaud,
>
> Am 03.07.2011 um 08:56 schrieb Albert ARIBAUD:
>
>> Hi Aneesh,
>>
>> Le 03/07/2011 06:47, Aneesh V a ?crit :
>>> Hi Albert,
>>>
>>> On Saturday 02 July 2011 01:21 AM, Albert ARIBAUD wrote:
>>>> Hi Aneesh,
>>>>
>
> <snip>
>
>>> I was thinking of doing that in start.S itself. I haven't looked at
>>> all the details though.
>>>
>>> BTW, please note that I am not trying to support disjoint BSS in
>>> regular u-boot. I think it becomes complex with relocation + it doesn't
>>> seem to be worth when all SDRAM is at our disposal.
>>>
>>> So:
>>> 1. #ifdef CONFIG_PRELOADER part in start.s will just pass __bss_start
>>> and __bss_end to the clear_bss function(assumes no relocation).
>>> 2. #else part of above will assume that bss follows text and data(or at
>>> least that __bss_start>  _start), so add relocation offset to
>>> __bss_start and __bss_end, and pass them to the clear_bss()
>>>
>>> Does that sound ok?
>>
>> (note clear_bss is not a function in arch/arm/cpu/armv7/start.S, it is only a label)
>>
>> So, considering what is already in arch/arm/cpu/armv7/start.S, you would just add a conditional variant to the BSS clearing code for the preloader case?
>>
>> If so, and considering that you'll pass an offset of 0, why would you need that variant for? With offset=0, the code already does what you want, does it not?
>
> we are looking forward to have relocate_code(), clear_bss(), a.s.o. implemented in c in future (as I understood the discussion around christmas about relocation).
> Wouldn't it be nice to implement now a SPL version of clear_bss(int start, int size)  in c and skip the relocate_code() stuff in start.S completely?
>
> As I see the normal way to boot is:
>
> ->  some start vector
>   ->  lowlevel_init
>    ->  board_init_f
>     ->  relocate_code
>      ->  board_init_r
>
> for SPL we do not need the steps after board_init_f. board_init_f
> for  SPL should implement the generic way to load data from predefined
> (compile time) source to predefined target address and branch it.
> Therefore a simple memset() in board_init_f could be sufficient to clear
> the bss.

Granted, clear_bss could become a function and should be optimized 
according to the context; however, I don't like the idea of calling a C 
library function at a point where we know the C environment for the 
caller is by definition not really set up yet.

And as a general rule, I think we should not perform changes 'now for 
the future' so yes, it would be nice to have a clear_bss() function, but 
we don't need it right now in U-Boot working as it is now; I'd much 
prefer the separate clear_bss C function to appear within the patch set 
that will bring this future general move of relocation to C.

> regards
>
> Andreas Bie?mann

Amicalement,
-- 
Albert.