Skip to contentSkip to conversation

83xx DDR2 667Mhz memory

U-Boot-Users Russell McGuire 3 participants 3 messages Apr 24, 2008 – Apr 30, 2008 1 message not in the archive

lore
Share & tools
lore

A message that is not in the archive (sent off-list or not yet received): mailman.128014.1209064835.5026.u-boot-users@lists.sourceforge.net

#1 lore raw

All,

Just curious if anyone has done any work with this near past.
I have had an 8360E board up for several months now and been happily working away with different types of Kingston S0-DIMM DDR2 memory.

512MB, 1204MB, DDR2 533Mhz memory. All work well, with U-boot. Using the SPD detectetion, things have just been automatically detected and worked wonderful.

Yesterday I went down and purchased two additional sticks of 1024MB DDR2 Crucial 667Mhz memory, as 533Mhz is in short supply. SPD detect still works in U-boot and everything is detected correctly. However, the u-boot will now hang when it tries to transfer execution into RAM. At first I figured this was a memory speed issue, since 667Mhz is not technically supported on the 8360E yet <Rev 2... I might be wrong on this?>, So I patched in a quick line of code to force the spd detection to limit to 533Mhz. Still doesn't work.

Any ideas? Again, same exact u-boot just different memory. SPD sees it all just fine, just can't use the RAM after its setup. Currently using a slightly older version of U-boot 1.3.0-dirty.

-Russ

#2 lore raw
Quoted 18 lines · Russell McGuire

All,

Just curious if anyone has done any work with this near past.
I have had an 8360E board up for several months now and been happily working away with different types of Kingston S0-DIMM DDR2 memory.

512MB, 1204MB, DDR2 533Mhz memory. All work well, with U-boot. Using the SPD detectetion, things have just been automatically detected and worked wonderful.

Yesterday I went down and purchased two additional sticks of 1024MB DDR2 Crucial 667Mhz memory, as 533Mhz is in short supply. SPD detect still works in U-boot and everything is detected correctly. However, the u-boot will now hang when it tries to transfer execution into RAM. At first I figured this was a memory speed issue, since 667Mhz is not technically supported on the 8360E yet <Rev 2... I might be wrong on this?>, So I patched in a quick line of code to force the spd detection to limit to 533Mhz. Still doesn't work.

Quoted 5 lines

Any ideas? Again, same exact u-boot just different memory. SPD sees it all just fine, just can't use the RAM after its setup. Currently using a slightly older version of U-boot 1.3.0-dirty.

-Russ

Hi Russ,

Any luck? I would be suspicious that the number of clocks changed (e.g. CL latencies) and the current code did not pick the changes out of the SPD fields properly. I would dump the two SPDs and compare them. If you can get datasheets on the RAM chips that are on the boards, that may also be helpful to compare.

Quite often, faster parts have longer latencies. My SPD decoding is knowledge getting a little rusty, but my recollection is that the memory controller configuration values and the SPD definitions did not clearly map 1:1 (had to massage SPD values to figure out/guess controller register values).

HTH,
gvb

P.S., as an added, free, bonus, here is a little diatribe on memory speed... It is slightly dated, obviously, but still valid.

Today we have PowerPCs running at 400-800MHz (and above) with the system bus running at 100MHz (and above). However, the systems which are running 100MHz on the system/memory bus have typically 18 clock cycles latency...

     100MHz / 18 = 5.56MHz

In the IBM PC-XT, created in 1981, the system bus was 4.77MHz! In the IBM PC-At, created in 1984, the system bus was 8MHz (originally 6MHz)

25 years after the debut of the PC-XT, we are clocking like mad but have basically the same data rates on our system bus!

Disclaimers:
* Bus width has increased from 2 bytes to 16 bytes, with resulting
linear scaling of data throughput.
* Pipelining on the memory bus can use many of the latency clock
cycles to queue up reads and writes, with resulting increases in throughput. However...
o The average pipelining success rate is much less than 100%.
o I/O typically doesn't support pipelining.
* IIRC, the IBM-XT could access memory mapped ISA boards with zero
wait states. Accessing I/O ports (in/out instructions) inserted wait states.

#3 lore raw
In reply to Russell McGuire
Quoted 2 lines

Any ideas? Again, same exact u-boot just different memory. SPD sees it

all

Quoted 5 lines

just fine, just can't use the RAM after its setup. Currently using a slightly older version of U-boot 1.3.0-dirty.

-Russ

Hi Russ,

I don't know what the current state is (I'm running a slightly older version than you), but we ran into a problem with the 83xx SPD code being able to recognize faster DDR2 memories. There was a whole series of nested if/else if statements figuring out if it was DDR400, DDR333, etc., and then figuring out effective data rates and CAS latencies from that. What we ran into was that (at the time) it would only figure out upto DDR400 and we're using 533. Since we're only using the one speed of RAM for this release of the product we just hardcoded values into registers and decided to look at fixing SPD later. Don't know if anyone else has yet. Know it doesn't help you much, but it gives you some place to look :(.

Bruce