[U-Boot] [PATCH] sheevaplug: correct SDRAM address control register value

[Mark Asselstine <mark.asselstine@windriver.com>]

On Sunday 18 October 2009 16:11:11 Tom wrote:
> Mark Asselstine wrote:
> > The SheevaPlug DevKit is shipped with 4x8 by 1Gb DDR devices in
> > two banks for a total of 512MB of RAM. Based on this configuration
> > the existing values for SDRAM address control register are incorrect
> > and result in random kernel oops as memory is incorrectly accessed
> > (while for example extracting a large tarball such as a rootfs).
> > Based on the hardware configuration along with the supporting
> > documentation from Marvell these are the correct values, as
> > well this change mimics values previously used in Marvell's own
> > u-boot git tree for the SheevaPlug.
> >
> > Other variants of the hardware such as the PogoPlug and TonidoPlug
> > may have different memory configurations but to properly support
> > those additional board directories should be maintained or a better
> > system to support other kwb*.cfg is needed.
> >
> > Tested on SheevaPlug DevKit.
> 
> Mark and Prafulla
> If this configuration is different from the what is already in use,
> then the kwbimage.cfg can not be overwritten.
> 
> Reviewing the kwbimage.cfg file shows a lot of magic.
> What would be a good way to generalize this ?
> 
Let me start with a quick disclaimer that I haven't spent the necessary 
prerequisite time with the kwb image concept yet to be anything more then a 
casual observer at this point.

Moving to a more typical header file format would be useful to remove the 
feeling of "magic", ie. similar to kernel register #defines with BASE and 
OFFSETs. Groupings of registers should be then captured in structures with a 
layout that would allow for 'make sheevaplug_devkit_config' to use the 
include/configs/*.h files to influence the values of particular registers, by 
name.

If the format of the kwbimage.cfg file is fixed we want to consider generating 
this file.

I will defer to Prafulla though as he might already have plans and what we see 
today might only be on the path to the final vision of things.

> More versions of the file ?

This would be the easiest route but would not make any strides to making the 
file less "magic".

> Variable support in the file?

Allowing the file to make use of #ifdef, #ifndef would allow for flexibility 
but again this solves on the issue of supporting variations not in making the 
file more reader friendly.

The $0.02 of a casual observer.

Mark.


> Other ideas ?
> 
> Tom
> 
> > Signed-off-by: Mark Asselstine <mark.asselstine@windriver.com>
> > ---
> >  board/Marvell/sheevaplug/kwbimage.cfg |   10 +++++-----
> >  1 files changed, 5 insertions(+), 5 deletions(-)
> >
> > diff --git a/board/Marvell/sheevaplug/kwbimage.cfg
> > b/board/Marvell/sheevaplug/kwbimage.cfg index 6c47d62..61be8c2 100644
> > --- a/board/Marvell/sheevaplug/kwbimage.cfg
> > +++ b/board/Marvell/sheevaplug/kwbimage.cfg
> > @@ -74,11 +74,11 @@ DATA 0xFFD0140C 0x00000a33	#  DDR Timing (High)
> >  # bit12-11: TW2W
> >  # bit31-13: zero required
> >
> > -DATA 0xFFD01410 0x00000099	#  DDR Address Control
> > -# bit1-0:   01, Cs0width=x16
> > -# bit3-2:   10, Cs0size=512Mb
> > -# bit5-4:   01, Cs1width=x16
> > -# bit7-6:   10, Cs1size=512Mb
> > +DATA 0xFFD01410 0x000000cc	#  DDR Address Control
> > +# bit1-0:   00, Cs0width=reserved
> > +# bit3-2:   11, Cs0size=1Gb
> > +# bit5-4:   00, Cs1width=reserved
> > +# bit7-6:   11, Cs1size=1Gb
> >  # bit9-8:   00, Cs2width=nonexistent
> >  # bit11-10: 00, Cs2size =nonexistent
> >  # bit13-12: 00, Cs3width=nonexistent
>