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

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

[Russell McGuire]

Guys,

 

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.

 

Russell McGuire

Senior Systems Engineer

rmcguire at videopresence.com

503.888.0968

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.denx.de/pipermail/u-boot/attachments/20080603/2613cb10/attachment.htm 

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

[David Hawkins]

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

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

[Bruce_Leonard at selinc.com]

> 
> 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.
> 

Hay Russell,

I don't have patches, and I haven't worked on this in a long time because 
we have a single build option for our RAM.  However, I may have a pointer 
for you to look at if you haven't already.  Way back when we we're 
thinking about having SPD support I did spend some time digging through 
spd_sdram.c and found that some of the calculations were....I won't say 
broken, but not exactly acurate because of they way they were done.  I 
also found that the highest data rate speeds supported didn't go high 
enough to support all of the speeds DDR2 can have.  Like I said, it's been 
a long time and someone may have already fixed it, but it had to do with 
calculating max_data_rate, effective_data_rate, and caslat in spd_sdram(). 
 It was something I ment to fix and then never did because we didn't end 
up using it.  Hope this helps.  If not, sorry for the noise.

Bruce

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

[Russell McGuire]

Bruce,

I think you've hit upon something here.
After checking the SPD tables during the intial comparison for data rates,
it is clear that 1) the DDR2 bit fields are not defined properly. i.e. it
looks like the big if-if-else statement specifically does not have valid
DDR2 values defined for clk_cycle2 (30h, 3Dh, 50h) not DDR1, so we're going
need an extra 3 defined at a minimum. 

I haven't gone through the rest yet, but most likely if we want to keep SPD
working for DDR2, we'll have to add the DDR2 definitions SPD into the code,
as it looks like the DDR2 port is only partially complete.

-Russ

-----Original Message-----
From: Bruce_Leonard@selinc.com [mailto:Bruce_Leonard at selinc.com] 
Sent: Tuesday, June 03, 2008 3:31 PM
To: rmcguire at videopresence.com
Cc: 'Maggs Bill'; 'Steve Hensley'; u-boot-users at lists.sourceforge.net;
u-boot-users-bounces at lists.sourceforge.net
Subject: Re: [U-Boot-Users] 83xx SPD_EEPROM DDR2 Issues

> 
> 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.
> 

Hay Russell,

I don't have patches, and I haven't worked on this in a long time because 
we have a single build option for our RAM.  However, I may have a pointer 
for you to look at if you haven't already.  Way back when we we're 
thinking about having SPD support I did spend some time digging through 
spd_sdram.c and found that some of the calculations were....I won't say 
broken, but not exactly acurate because of they way they were done.  I 
also found that the highest data rate speeds supported didn't go high 
enough to support all of the speeds DDR2 can have.  Like I said, it's been 
a long time and someone may have already fixed it, but it had to do with 
calculating max_data_rate, effective_data_rate, and caslat in spd_sdram(). 
 It was something I ment to fix and then never did because we didn't end 
up using it.  Hope this helps.  If not, sorry for the noise.

Bruce

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

[Bruce_Leonard at selinc.com]

"Russell McGuire" <rmcguire@videopresence.com> wrote on 06/03/2008 
04:15:55 PM:

> 
> I haven't gone through the rest yet, but most likely if we want to keep 
SPD
> working for DDR2, we'll have to add the DDR2 definitions SPD into the 
code,
> as it looks like the DDR2 port is only partially complete.
> 
> -Russ
> 

Russ,

That's pretty much jives with my recollection.  One other thing that leaps 
to mind was the calculation for max_bus_clk.  I hand cranked through that 
with a high clock rate as input and due to rounding errors got a bogus 
value.  I don't remember the details right off the top of my head but it 
seems to me that the net result was I started with a bus clock that should 
have landed max_data_rate in one of those if-if-else-if cases, but it 
didn't.  So I think that whole function (and especially the max_bus_clk 
calculation) needs to be gone through.  Good luck.  I'd help but I have my 
own issues with MTD :(.

Bruce

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

[Russell McGuire]

All,

Correct, I did some math and they almost work out for DDR1 values
However into DDR2 clocks speeds it gets increasingly bad.

Going through the SPD tables I have found, it looks like there is not a
mathematical way to convert those values, as they are in nanoseconds but
only some are actually linear. Some values like 0x3D for spd->clk_cycle
can't be converted using a formula, easy enough to put into a case
statement. 0x3D is intended to be 3.75ns and 0x30 is 3.00ns. So 0x0D would
be 0.75ns? Doesn't work in my book. However 0x25 is a nice easy clear 2.5ns.
Whomever put Hex values to represent decimal numbers probably chose a poor
idea. I am just hoping that most RAM isn't putting 'exact' values in SPD
tables, but rather an industry standard value that is going to work with the
intended SODIMM / DIMM, our code should be using lookup tables if so, not
math formulas. 

I have already written a flat case statement with correct values. Easy to
see now why it was breaking, as the CAS latencies were all hosed over for
the faster memory.

-Russ

-----Original Message-----
From: Bruce_Leonard@selinc.com [mailto:Bruce_Leonard at selinc.com] 
Sent: Tuesday, June 03, 2008 5:34 PM
To: rmcguire at videopresence.com
Cc: 'David Hawkins'; 'Steve Hensley'; u-boot-users at lists.sourceforge.net
Subject: RE: [U-Boot-Users] 83xx SPD_EEPROM DDR2 Issues

"Russell McGuire" <rmcguire@videopresence.com> wrote on 06/03/2008 
04:15:55 PM:

> 
> I haven't gone through the rest yet, but most likely if we want to keep 
SPD
> working for DDR2, we'll have to add the DDR2 definitions SPD into the 
code,
> as it looks like the DDR2 port is only partially complete.
> 
> -Russ
> 

Russ,

That's pretty much jives with my recollection.  One other thing that leaps 
to mind was the calculation for max_bus_clk.  I hand cranked through that 
with a high clock rate as input and due to rounding errors got a bogus 
value.  I don't remember the details right off the top of my head but it 
seems to me that the net result was I started with a bus clock that should 
have landed max_data_rate in one of those if-if-else-if cases, but it 
didn't.  So I think that whole function (and especially the max_bus_clk 
calculation) needs to be gone through.  Good luck.  I'd help but I have my 
own issues with MTD :(.

Bruce

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

[Russell McGuire]

Guys,

I think I have found a reason / partial fix, after getting some parameters
tweaked and pimping out the debug routine to printf() almost the entire SPD
table here is what I found.

1) The SPD tables for DDR1 and DDR2 are dfferent by about 10-15%. We'll need
to add a separate SPD struct to fully make this elegant, for now I think
enough of it is similar to gut shoot a quick fix. i.e. byte 23, 24, 25 etc
have different meanings.

2) Some DIMMs are supporting 50-Ohm ODT termination, however some newer
DIMMs have disabled this feature. The spd->dev_attr holds the actual value,
0x03 is with ODT 50Ohm and 0x01 is without.  The 0x01 is for weak drivers.

Right now the code doesn't deal with anything on the dev_attr field. 
Turning on 2T timing seems to correct for this problem.

So the real question begins, what happens now?? Impedance can be worked
around by excessively slowing the memory bus to compensate for the noise
made by unmatched impedance. However, it would be nice to make this match,
and actually use what we pay for. I know Freescale has some bits in the 83xx
that deal with ODT and Impedance on the drivers. We'll need to add code to
handle this, but more importantly I need to find what it means if the 50-Ohm
ODT is not there in the DIMM, and how we compensate.
 
3) Lastly the cheap, but global fix to have the SPD code work for all newer
memory types is to modify the picos_to_clks() function. I added a simple
"#ifdef CFG_DDR2_LOOSE_TIMING" option that simply adds one extra clk++; This
made all the PC4200 and PC5300 RAM I had work.

None of these is the 'correct' fix, but if somebody wants the code I'll be
happy to post. I will be working with Freescale to find info on the
ODT-50-ohm problem and possible other solutions.

-Russ


-----Original Message-----
From: Bruce_Leonard@selinc.com [mailto:Bruce_Leonard at selinc.com] 
Sent: Tuesday, June 03, 2008 5:34 PM
To: rmcguire at videopresence.com
Cc: 'David Hawkins'; 'Steve Hensley'; u-boot-users at lists.sourceforge.net
Subject: RE: [U-Boot-Users] 83xx SPD_EEPROM DDR2 Issues

"Russell McGuire" <rmcguire@videopresence.com> wrote on 06/03/2008 
04:15:55 PM:

> 
> I haven't gone through the rest yet, but most likely if we want to keep 
SPD
> working for DDR2, we'll have to add the DDR2 definitions SPD into the 
code,
> as it looks like the DDR2 port is only partially complete.
> 
> -Russ
> 

Russ,

That's pretty much jives with my recollection.  One other thing that leaps 
to mind was the calculation for max_bus_clk.  I hand cranked through that 
with a high clock rate as input and due to rounding errors got a bogus 
value.  I don't remember the details right off the top of my head but it 
seems to me that the net result was I started with a bus clock that should 
have landed max_data_rate in one of those if-if-else-if cases, but it 
didn't.  So I think that whole function (and especially the max_bus_clk 
calculation) needs to be gone through.  Good luck.  I'd help but I have my 
own issues with MTD :(.

Bruce

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

[Bruce_Leonard at selinc.com]

> 
> None of these is the 'correct' fix, but if somebody wants the code I'll 
be
> happy to post. I will be working with Freescale to find info on the
> ODT-50-ohm problem and possible other solutions.
> 
> -Russ
> 

Is there a correct fix?  You sort of implied that even a look up table 
wouldn't solve the problem and that was the direction I was going to take 
if I ever got back to it.  It would be nice to see this fixed for both 
DDR1 and DDR2.