[OLPC-devel] Re: [One Laptop Per Child] #53: LinuxBIOS sometimes hangs after "Jumping to LinuxBIOS"

[Zarro Boogs per Child]

#53: LinuxBIOS sometimes hangs after "Jumping to LinuxBIOS"
-------------------------------+--------------------------------------------
 Reporter:  wmb at firmworks.com  |        Owner:  mfoster   
     Type:  defect             |       Status:  new       
 Priority:  blocker            |    Milestone:  rev1 alpha
Component:  linuxbios          |   Resolution:            
 Keywords:                     |  
-------------------------------+--------------------------------------------
Changes (by tsylla):

  * owner:  rminnich => mfoster

Comment:

 I got Jordan's part number, and luckily, google got me to a datasheet for
 it. The part number is HYB25D256163CE-4.0, with a datasheet here:

 http://www.infineon.com/upload/Document/cmc_upload/documents/012/0395/HYB25D256163CE_Rev1.11.pdf#search=%22HYB25d256163CE-4.0%22

 The first funny thing I noticed is that this is *graphics* DDR. I can only
 speculate, but my guess is that is cheaper DRAM that didn't qualify to run
 at the faster CAS latencies of "normal" DDR.

 The CAS latency is the problem. Quanta's original recommended DDR timings
 included setting CAS2. From the datasheet, the -4 parts are only rated for
 CAS3 at 250MHz. OLPC is currently running at 222MHz, so the CAS latency is
 still probably too quick for the DRAM devices. (I would bet it would get
 very much worse if olpc were running DDR at 266) The PSC and Hynix devices
 from the early boards were either rated for CAS2 from the start, or at
 least can tolerate CAS2. I cannot check for sure, since I do not have
 datasheets for those devices. (does anyone have them?)

 On Jordan's board, byte lanes 0 and 1 were bad. Writing all FFs, followed
 by all 00s, would result in byte lanes 0 and 1 retaining the FFs. Ron was
 able to reproduce this, and we found that byte lanes 1, 2, and 3 were bad
 on his platform. Ron ran quite a few boot cycles at CAS2.5, and the board
 always booted past the Jumping to.. point. With CAS2, he was able to re-
 create the failure several times.

 On the last occurrence of the failure, we did an experiment that pretty
 clearly shows that this is CAS related. We first verified that bytes lanes
 1, 2, and 3 were behaving funny. Then I helped him re-program the MC to
 CAS2.5. After that, memory started working properly again.

 The worst part about this is that GX cannot run at CAS3. That setting does
 not exist in GX's registers. This means there is no "safe" way to run the
 infineon devices. You can run CAS2.5, and it will probably be pretty good,
 but it still really isn't meeting the Infineon datasheet spec. The olpc
 higher-ups will have to decide the correct path to address this.

 Assigning to Mark, to figure out why Quanta made this substitution. It
 doesn't seem valid. Also, it would be a good idea for someone to re-verify
 Quanta's recommended DDR timing values (those in LinuxBIOS). This issue
 sort of brings all of those settings into question. The settings need to
 be verified for all of the DRAM parts that have been loaded on olpc
 platforms.

-- 
Ticket URL: <http://dev.laptop.org/ticket/53#comment:26>
One Laptop Per Child <http://laptop.org/>