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

[Schwarz,Andre]

York,
 


"Schwarz,Andre" <andre.schwarz at 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 at 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