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@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:
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.
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?
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.
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