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