From mboxrd@z Thu Jan 1 00:00:00 1970 From: Heiko Schocher Date: Fri, 01 Oct 2010 08:17:11 +0200 Subject: [U-Boot] [PATCH] Kirkwood: dram_init is moved to dram.c In-Reply-To: References: <1285869240-17251-1-git-send-email-prafulla@marvell.com> <4CA4AF41.1070307@denx.de> Message-ID: <4CA57CE7.1060209@denx.de> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de Hello Prafulla, Prafulla Wadaskar wrote: > > >> -----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 >>> --- >>> 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 >>> +#include >>> #include >>> >>> +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? Good question ... for this case we must adapt in arch/arm/lib/board.c addr = CONFIG_SYS_SDRAM_BASE + gd->ram_size; But no idea, where to put u-boot ... at the end of the first bank? at the end of the last bank? bye, Heiko -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany