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

[York Sun]

On Tue, 2011-04-05 at 16:52 -0500, Kim Phillips wrote:
> On Tue, 5 Apr 2011 11:49:49 +0200
> Andre Schwarz <andre.schwarz at matrix-vision.de> wrote:
> 
> Cc'ing York Sun, who knows a little more about this stuff than I do.
> 
> > 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?
> 
> this isn't included in the below diff, right?

Actually I have code for this already, pending for more broader testing.
I use raw timing data from datasheet of DDR chips. We have an internal
discussion to recommend using EEPROM to mimic SPD structure.

> 
> > 2.
> > read SPD data also from extended adressing EEPROMS used for e.g. HRCW 
> > storage.
> > Due to HRCW being being located at offset 0 we need an SPD data offset.
> 
> and this is the SPD_EEPROM_OFFSET stuff below?  hmm..
> 
> so both 1 & 2 are coagulated in my mind - ideally, this would be
> implemented with the new ddr code in
> arch/powerpc/cpu/mpc8xxx/ddr/main.c - see fsl_ddr_compute(), which has
> a GET_SPD step that would need to be either skipped (i.e, start_step =
> COMPUTE_DIMM_PARMS), or changed to be able to be overridden, or,
> ideally, all DIMM computations would be precomputed and stored in ROM
> and a direct start_step to e.g., STEP_ASSIGN_ADDRESSES were made.

I don't 100% agree with the idea to put SPD-like data in HRCW. How can
you be sure the data matches DDR? It would be equivalent to using fixed
raw timing data, wouldn't it?

> 
> > 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.  
> 
> however, it should not be being done by glittering old-83xx/spd_sdram
> with an extra #ifdef for every new parameter that is needed, especially
> when this is all fixed in the new ddr code.  So, in preparation for
> 83xx to eventually migrate to the new ddr code, I'd like this to be
> done in such a way so as to start to conform to the new code by at least
> defining ODT, etc. parameters in a board-specific
> ddr.c:fsl_ddr_board_options().  See board/freescale/{p1022ds,*}/ddr.c
> for example.

The ODT table is implemented in options.c and it can be override by
board functions. Look for the last function in options.c and  ddr.c
under the board folder.

> 
> > 4.
> > CPO values depend on internal bond wire length which has significantly
> > high variance on MPC837x, i.e. this value also should be board specific.
> 
> again, to be defined as popts->cpo_override in the board-specific
> ddr.c:fsl_ddr_board_options().

I recommend to use auto calibration. If for some reason, you want to
override, it belongs to board specific file, same as the above.

York