[U-Boot-Users] 83xx SPD_EEPROM DDR2 Issues
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@videopresence.com
503.888.0968
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
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
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@selinc.com] Sent: Tuesday, June 03, 2008 3:31 PM To: rmcguire@videopresence.com Cc: 'Maggs Bill'; 'Steve Hensley'; u-boot-users@lists.sourceforge.net; u-boot-users-bounces@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
"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
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@selinc.com] Sent: Tuesday, June 03, 2008 5:34 PM To: rmcguire@videopresence.com Cc: 'David Hawkins'; 'Steve Hensley'; u-boot-users@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
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@selinc.com] Sent: Tuesday, June 03, 2008 5:34 PM To: rmcguire@videopresence.com Cc: 'David Hawkins'; 'Steve Hensley'; u-boot-users@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
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.
participants (3)
-
Bruce_Leonard＠selinc.com -
David Hawkins -
Russell McGuire