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.asselst...@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 > _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
