On Tue, 2011-04-05 at 16:52 -0500, Kim Phillips wrote:
> On Tue, 5 Apr 2011 11:49:49 +0200
> Andre Schwarz <andre.schw...@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
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
