From mboxrd@z Thu Jan  1 00:00:00 1970
From: Schwarz,Andre <andre.schwarz@matrix-vision.de>
Date: Wed, 6 Apr 2011 20:42:19 +0200 (CEST)
Subject: [U-Boot] [RFC] mpc83xx: add config options to spd_sdram
In-Reply-To: <1302107849.4586.14.camel@oslab-l1>
References: <4D9AE5BD.704@matrix-vision.de>
	<20110405165227.78ecd5bd.kim.phillips@freescale.com>
	<4D9C21EA.3070005@matrix-vision.de>
	<1302107849.4586.14.camel@oslab-l1>
Message-ID: <908840060.379.1302115339879.JavaMail.open-xchange@proteus>
List-Id: <u-boot.lists.denx.de>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
To: u-boot@lists.denx.de

York,
?
ok - will give it a try tomorrow.
?
Cheers,
Andr?
?

York Sun <yorksun@freescale.com> hat am 6. April 2011 um 18:37 geschrieben:

> On Wed, 2011-04-06 at 10:18 +0200, Andre Schwarz wrote:
> > Kim, York,
> >
> > >> I have made some mods to spd_sdram.c for various reason:
> > >>
> > >> 1.
> > >> use SPD setup also for soldered RAM.
> > >> This allows DDR mounting options without U-Boot change because SPD data
> > >> is written during in-circuit/boundary-scan testing.
> > > not sure I understand this - board with soldered RAM can't physically
> > > get the SPD data from RAM, yet SPD data were somehow acquired and
> > > written into some ROM, so spd_sdram() is still needed to parse&
> > > program the controller without requiring a new u-boot binary?
> > SPD data is nothing more than an I2C-EEPROM soldered on each memory module
> > containing the physical details of the memory devices.
> > Since I already have an I2C-EEPROM on the board I can use it for SPD
> > data, i.e.
> > the board's memory is configured using normal detection routines.
> >
> > During production (exactly: board testing) the EEPROM will be programmed
> > with an SPD
> > table matching the soldered memory devices. This gives some flexibility
> > regarding size and
> > speed grades ... some devices have pretty short life-cycles.
>
> That's right. If you have the SPD in I2C-EEPROM, you have a real SPD as
> far as software concerns. Just provide the I2C address.
>
> > >> 3.
> > >> for optimized signal integrity and power consumption we need more
> > >> influence on
> > >> the on-die termination. Although the assumed default values are working
> > >> they
> > >> are far from ideal.
> > > board specific things like this are perfectly acceptable, of course.
> > ok.
> > > however, it should not be being done by glittering old-83xx/spd_sdram
> > > with an extra #ifdef for every new parameter
> >
> > ok - what about this :
> >
> > #if !defined(CONFIG_SYS_DDR_MODE_ODT_VALUE)
> > #define CONFIG_SYS_DDR_MODE_ODT_VALUE 0x40
> > #endif
> >
> > mode_odt_enable = CONFIG_SYS_DDR_MODE_ODT_VALUE;
> >
> >
> > I really can't think of this change being a problem for anybody.
> >
>
> I would suggest to put it in fsl_ddr_board_options() in ddr.c under the
> board directory. There you can override any options, including
>
> popts->cs_local_opts[i].odt_rd_cfg
> popts->cs_local_opts[i].odt_wr_cfg
> popts->cpo_override
>
>
>
> York
>
>
>--
Gru?,
Andr? Schwarz

MATRIX VISION GmbH, Talstrasse 16, DE-71570 Oppenweiler
Registergericht: Amtsgericht Stuttgart, HRB 271090
Geschaeftsfuehrer: Gerhard Thullner, Werner Armingeon, Uwe Furtner