From mboxrd@z Thu Jan 1 00:00:00 1970 From: Schwarz,Andre Date: Thu, 7 Apr 2011 22:42:57 +0200 (CEST) Subject: [U-Boot] [RFC] mpc83xx: add config options to spd_sdram In-Reply-To: <908840060.379.1302115339879.JavaMail.open-xchange@proteus> References: <4D9AE5BD.704@matrix-vision.de> <20110405165227.78ecd5bd.kim.phillips@freescale.com> <4D9C21EA.3070005@matrix-vision.de> <1302107849.4586.14.camel@oslab-l1> <908840060.379.1302115339879.JavaMail.open-xchange@proteus> Message-ID: <1427125824.654.1302208977309.JavaMail.open-xchange@proteus> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de York, ? "Schwarz,Andre" hat am 6. April 2011 um 20:42 geschrieben: > York, > ? > ok - will give it a try tomorrow. > ? > ? hmm - having a look at the Makefile it looks like I need CONFIG_FSL_DDR2. This seems to pull in the "new" code ... without omitting the "old" one? in arch/powerpc/cpu/mpc83xx/spd_sdram.c ? The Makefile further uses ctrl_regs.c ... which fails. ? having a look arch/powerpc/cpu/mpc8xxx/ddr/ctrl_regs.c?gives : ? #ifdef CONFIG_MPC85xx ??#define _DDR_ADDR CONFIG_SYS_MPC85xx_DDR_ADDR #elif defined(CONFIG_MPC86xx) ??#define _DDR_ADDR CONFIG_SYS_MPC86xx_DDR_ADDR #else?? ? ? ? ??#error "Undefined _DDR_ADDR" #endif? ? There's not a single sign of any 83xx within this code. Grepping through the board configs only show 85xx and 86xx based boards using it. ? Sorry, but I'm feeling like an idiot. ? Are you playing some game with me or am I simply unable to understand the code ? ? Please shed some light on this. ? Regards, Andr? ? > ? > > York Sun hat am 6. April 2011 um 18:37 geschrieben: > > > On Wed, 2011-04-06 at 10:18 +0200, Andre Schwarz wrote: > > > Kim, 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? > > > SPD data is nothing more than an I2C-EEPROM soldered on each memory module > > > containing the physical details of the memory devices. > > > Since I already have an I2C-EEPROM on the board I can use it for SPD > > > data, i.e. > > > the board's memory is configured using normal detection routines. > > > > > > During production (exactly: board testing) the EEPROM will be programmed > > > with an SPD > > > table matching the soldered memory devices. This gives some flexibility > > > regarding size and > > > speed grades ... some devices have pretty short life-cycles. > > > > That's right. If you have the SPD in I2C-EEPROM, you have a real SPD as > > far as software concerns. Just provide the I2C address. > > > > > >> 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. > > > ok. > > > > however, it should not be being done by glittering old-83xx/spd_sdram > > > > with an extra #ifdef for every new parameter > > > > > > ok - what about this : > > > > > > #if !defined(CONFIG_SYS_DDR_MODE_ODT_VALUE) > > > #define CONFIG_SYS_DDR_MODE_ODT_VALUE 0x40 > > > #endif > > > > > > mode_odt_enable = CONFIG_SYS_DDR_MODE_ODT_VALUE; > > > > > > > > > I really can't think of this change being a problem for anybody. > > > > > > > I would suggest to put it in fsl_ddr_board_options() in ddr.c under the > > board directory. There you can override any options, including > > > > popts->cs_local_opts[i].odt_rd_cfg > > popts->cs_local_opts[i].odt_wr_cfg > > popts->cpo_override > > > > > > > > York > > > > > >-- > Gru?, > Andr? Schwarz > MATRIX VISION GmbH, Talstrasse 16, DE-71570 Oppenweiler Registergericht: Amtsgericht Stuttgart, HRB 271090 Geschaeftsfuehrer: Gerhard Thullner, Werner Armingeon, Uwe Furtner