[U-Boot] [PATCH] Kirkwood: dram_init is moved to dram.c

[Albert ARIBAUD]

Le 01/10/2010 07:59, Prafulla Wadaskar a écrit :
>
>
>> -----Original Message-----
>> From: Heiko Schocher [mailto:hs at denx.de]
>> Sent: Thursday, September 30, 2010 9:10 PM
>> To: Prafulla Wadaskar
>> Cc: u-boot at lists.denx.de; Ashish Karkare; Prabhanjan Sarnaik
>> Subject: Re: [U-Boot] [PATCH] Kirkwood: dram_init is moved to dram.c
>>
>> Hello Prafulla,
>>
>> Prafulla Wadaskar wrote:
>>> For all Kirkwood boards so far dram_init function is duplicated
>>> dram_init function is moved to dram.c and relevant code from all
>>> board specific files removed
>>>
>>> If any board needs specific dram init handling than standard one,
>>> then, a macro CONFIG_SYS_BOARD_DRAM_INIT should be defined in
>>> board config header file and the dram_init function can be put
>>> in board specific source file
>>> For ex. keymile boards
>>>
>>> Signed-off-by: Prafulla Wadaskar<prafulla at marvell.com>
>>> ---
>>>   arch/arm/cpu/arm926ejs/kirkwood/dram.c          |   22
>> ++++++++++++++++++++++
>>>   board/Marvell/guruplug/guruplug.c               |   11 -----------
>>>   board/Marvell/mv88f6281gtw_ge/mv88f6281gtw_ge.c |   11 -----------
>>>   board/Marvell/openrd_base/openrd_base.c         |   11 -----------
>>>   board/Marvell/rd6281a/rd6281a.c                 |   11 -----------
>>>   board/Marvell/sheevaplug/sheevaplug.c           |   11 -----------
>>>   include/configs/keymile-common.h                |    1 +
>>>   7 files changed, 23 insertions(+), 55 deletions(-)
>>>
>>> diff --git a/arch/arm/cpu/arm926ejs/kirkwood/dram.c
>> b/arch/arm/cpu/arm926ejs/kirkwood/dram.c
>>> index 8f2a18a..d929d7a 100644
>>> --- a/arch/arm/cpu/arm926ejs/kirkwood/dram.c
>>> +++ b/arch/arm/cpu/arm926ejs/kirkwood/dram.c
>>> @@ -23,8 +23,11 @@
>>>    */
>>>
>>>   #include<config.h>
>>> +#include<common.h>
>>>   #include<asm/arch/kirkwood.h>
>>>
>>> +DECLARE_GLOBAL_DATA_PTR;
>>> +
>>>   #define KW_REG_CPUCS_WIN_BAR(x)		
>> (KW_REGISTER(0x1500) + (x * 0x08))
>>>   #define KW_REG_CPUCS_WIN_SZ(x)		
>> (KW_REGISTER(0x1504) + (x * 0x08))
>>>   /*
>>> @@ -56,3 +59,22 @@ u32 kw_sdram_bs(enum memory_bank bank)
>>>   	result += 0x01000000;
>>>   	return result;
>>>   }
>>> +
>>> +#ifndef CONFIG_SYS_BOARD_DRAM_INIT
>>> +int dram_init(void)
>>> +{
>>> +	int i;
>>> +#if !defined(CONFIG_SYS_ARM_WITHOUT_RELOC)
>>> +	gd->ram_size = 0;
>>> +#endif
>>> +	for (i = 0; i<  CONFIG_NR_DRAM_BANKS; i++) {
>>> +		gd->bd->bi_dram[i].start = kw_sdram_bar(i);
>>> +		gd->bd->bi_dram[i].size = kw_sdram_bs(i);
>>> +#if !defined(CONFIG_SYS_ARM_WITHOUT_RELOC)
>>> +		gd->ram_size += gd->bd->bi_dram[i].size;
>>
>> This is only OK, if the memory banks are consecutive without
>> gaps ... is this true for all boards?
>
> Yes, those are consecutive without gaps on all boards so far.
> But one can configure with gaps too, for ex. If any new board uses two chips with smaller size then it is possibility of gap insertion.
>
> In that case how it should be?
>
> Regards..
> Prafulla . .

I guess the most correct approach would be to "lump" together all banks 
until one is found not to be contiguous. The "lump" would be "the RAM".
Technically, if the banks are not in ascending base address order then 
you'd have to sort them out, so the best is to make it a requirement 
that they are in ascending base address order.

Amicalement,
-- 
Albert.