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? >> >> 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. sorry - I don't understand this. Why do you want to create something new if there's a standard like SPD layout ? It is working perfectly fine and the data can be obtained from the manufacturer without further modifications.
>>> 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. The SPD data has nothing to do with HRCW - it's just stored in the same PROM. > How can you be sure the data matches DDR? Because the SPD data gets programmed during production. We can use any SPD table *exactly* matching the soldered parts. > It would be equivalent to using fixed raw timing data, wouldn't it? no - it isn't. I want the *same* U-Boot binary running on *different* memory configurations, i.e. *no* fixed timing at all. >>> 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. To me it is a fundamental design error to rely on environment data to set up the hardware correctly. Especially something that critical as memory configuration. Do you expect U-Boot to work with a corrupted environment, i.e. hwconfig value unavailable ? Of course this might never happen on a reference design board - but that's not real life. >>> 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. > no - auto calibration is far from ideal regarding emc and power consumption. Regards, André MATRIX VISION GmbH, Talstrasse 16, DE-71570 Oppenweiler Registergericht: Amtsgericht Stuttgart, HRB 271090 Geschaeftsfuehrer: Gerhard Thullner, Werner Armingeon, Uwe Furtner _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot