[U-Boot-Users] 83xx SPD_EEPROM DDR2 Issues

[David Hawkins <dwh@ovro.caltech.edu>]

Hi Russell,

> Reposting on previous issue that is becoming a lot more painful.
> 
> Today, I went to my local PC store, and bought EVERY type of DDR2 SODIMM 
> memory they had, Kingston, Crucial, PC4200, PC5300 four different kinds 
> of memory, and NONE of them will boot with U-boot now.
> 
> We apparently have hit a new version of RAM in production, that I 
> imagine will affect EVERYONE using 83xx chips if they actually try and 
> purchase any recent memory.
> 
> Has anyone got patches out for updates SPD code?
> 
> I will work on this today and until I get it fixed, since beta testing 
> has come to a complete halt within our company due to this.

Out of interest, have you determined what is incorrect in the
SPD entries versus a working configuration for the board?

Have you tried to get each DDR2 working independently of
the SPD settings?

For example, you could test each RAM module by plugging it into
the MPC8349EA-MDS-PB, and powering it up in a PCI slot with
CFG_RS[0:2] = 100h, and CFG_CLKIN = 0 for a 33MHz PCI bus, or
CFG_RS[0:2] = 011h, and CFG_CLKIN = 0 for a 66MHz PCI bus
(or CFG_CLKIN = 1 for 33MHz bus). See 4.3 in the EA reference
manual.

This will boot the board in agent mode with a hard-coded reset
values for the RCWs. The DDR interface will be clocked at 133MHz,
so 266MHz DDR. The core would run at 400MHz if it was enabled,
but its not needed.

 From the x86 host, you can manually program the DDR registers and
determine a configuration that works. The reason for booting the
board in this way, is that during each test you need to disable
the DDR controller, make changes to the settings, and then
re-enable the controller. You can generate burst transactions
to the DDR memory by DMAing data from the PCI host to the board,
and back again. Even though the PCI clock is slower than the DDR,
the I/O sequencer buffers the data, and generates burst
transactions to the DDR. I used this to write a pattern to a
page of memory on the host, DMA to our MPC8349EA board, DMA it
back again, and check the pattern is valid. The adjust the
clocks and retry.

I'm pretty sure the only things that you'll want to adjust are
the clock timings. There are two clock adjustment options in
the DDR controller

  1. CK/CK# to address/command timing

     DDR_SDRAM_CLK_CNTL[CLK_ADJUST]
        0000b   clock launched aligned with address/command
        0001b   clock launched 1/8th clock after address/command
        0010b   clock launched 1/2th clock after address/command
        0011b   clock launched 3/8th clock after address/command
        0100b   clock launched 1/2th clock after address/command
        0101b   clock launched 5/8th clock after address/command
        0110b   clock launched 3/4th clock after address/command
        0111b   clock launched 7/8th clock after address/command
        1000b   clock launched     1 clock after address/command
        1001b-1111b Reserved

  2. write-data to DQS timing

     TIMING_CFG_2[WR_DATA_DELAY]
        000b    0 clock delay
        001b  1/4 clock delay
        010b  1/2 clock delay
        011b  3/4 clock delay
        100b    1 clock delay
        101b  5/4 clock delay
        110b  3/2 clock delay
        111b      reserved

Alternatively you can use the BDI2000 to initial the DDR registers,
and DMA say from Flash to DDR to write patterns. Here's the
configuration file I wrote for our EA board based on the settings
from a running U-Boot (so the parameters were determined from
working SPD decoded values):

ftp://ftp.denx.de/pub/BDI2000/mpc8349ea_mds_pb.cfg

You could see how different the SPD derived settings are relative
to the settings in this configuration file.

Hope that helps.

Cheers,
Dave