----- Original Message ----- From: Prafulla Wadaskar <prafulla@marvell.com> To: Tanmay Upadhyay <tanmay.upadhyay@einfochips.com> Cc: u-boot@lists.denx.de, g remlin <g_remlin@rocketmail.com>, Ashish Karkare <akarkare@marvell.com>, Prabhanjan Sarnaik <sarnaik@marvell.com> Sent: Thu, 21 Oct 2010 10:27:28 +0530 (IST) Subject: RE: [PATCH v2] Kirkwood: bugfix: DRAM size initialization
-----Original Message----- From: Tanmay Upadhyay [mailto:tanmay.upadhyay@einfochips.com] Sent: Friday, October 15, 2010 5:28 PM To: Prafulla Wadaskar Cc: u-boot@lists.denx.de; Tanmay Upadhyay Subject: [PATCH v2] Kirkwood: bugfix: DRAM size initialization
If start of any DRAM bank is greater than total DDR size, remaining DDR banks' start address & size were left un-initialized in dram_init function. This could break other functions who uses array 'gd->bd->bi_dram'. Kirkwood network driver is one example. This also stops Linux kernel from booting.
v2 - Set start address also to 0. Without this Linux kernel couldn't boot up
Signed-off-by: Tanmay Upadhyay tanmay.upadhyay@einfochips.com
arch/arm/cpu/arm926ejs/kirkwood/dram.c | 10 ++++++++++ 1 files changed, 10 insertions(+), 0 deletions(-)
diff --git a/arch/arm/cpu/arm926ejs/kirkwood/dram.c b/arch/arm/cpu/arm926ejs/kirkwood/dram.c index 7439c87..a4344b8 100644 --- a/arch/arm/cpu/arm926ejs/kirkwood/dram.c +++ b/arch/arm/cpu/arm926ejs/kirkwood/dram.c @@ -81,6 +81,16 @@ int dram_init(void) gd->ram_size += gd->bd->bi_dram[i].size;
}
- for (; i < CONFIG_NR_DRAM_BANKS; i++) {
- /* If above loop terminated prematurely, we need to set
- remaining banks' start address & size as 0.
Otherwise other
- u-boot functions and Linux kernel gets wrong
values which
- could result in crash */
- gd->bd->bi_dram[i].start = 0;
- gd->bd->bi_dram[i].size = 0;
- }
return 0; }
Hi Tanmay I hope you would not mind if I apply the below patch by Gray for similar fix http://lists.denx.de/pipermail/u-boot/2010-October/079655.html Regards.. Prafulla . .
Hi Prafulla,
Gray's patch takes care of ram size in u-boot. But still with his patch non-contiguous memory would be exposed -if it's there - to Linux kernel by start and size variables of bi_dram. My patch takes care of that by zeroing these variables. What's your opinion?
Thanks, Tanmay