83xx DDR2 667Mhz memory
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
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
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.
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