[U-Boot] [RFC] mpc83xx: add config options to spd_sdram

[Schwarz,Andre <andre.schwarz@matrix-vision.de>]

York,
?


"Schwarz,Andre" <andre.schwarz@matrix-vision.de> hat am 6. April 2011 um 20:42
geschrieben:


> York,
> ?
> ok - will give it a try tomorrow.
> ?
> 
?
hmm - having a look at the Makefile it looks like I need CONFIG_FSL_DDR2.
This seems to pull in the "new" code ... without omitting the "old" one?
in arch/powerpc/cpu/mpc83xx/spd_sdram.c
?
The Makefile further uses ctrl_regs.c ... which fails.
?
having a look arch/powerpc/cpu/mpc8xxx/ddr/ctrl_regs.c?gives :
?
#ifdef CONFIG_MPC85xx
??#define _DDR_ADDR CONFIG_SYS_MPC85xx_DDR_ADDR
#elif defined(CONFIG_MPC86xx)
??#define _DDR_ADDR CONFIG_SYS_MPC86xx_DDR_ADDR
#else?? ? ? ?
??#error "Undefined _DDR_ADDR"
#endif?
?
There's not a single sign of any 83xx within this code.
Grepping through the board configs only show 85xx and 86xx based boards using
it.
?
Sorry, but I'm feeling like an idiot.
?
Are you playing some game with me or am I simply unable to understand the code ?
?
Please shed some light on this.
?
Regards,
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