linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
From: Jon Loeliger <jdl@freescale.com>
To: Vince Asbridge <vasbridge@sanblaze.com>
Cc: u-boot@lists.denx.de, 'Stephen Shirron' <sshirron@sanblaze.com>,
	'linuxppc-embedded' <linuxppc-embedded@ozlabs.org>
Subject: Re: [PATCH] RE: Some memory (DDR2 ECC Dual Rank) just doesn't work! Can anyone pointme to how to debug this hang?
Date: Thu, 14 Aug 2008 11:31:05 -0500	[thread overview]
Message-ID: <48A45DC9.2060601@freescale.com> (raw)
In-Reply-To: <0b1f01c8fe27$81d6b250$4b01a8c0@sanblaze.com>

Vince Asbridge wrote:
> Stephane,
> 
> Thanks so much for your prompt reply.
> 
> We will pursue your suggestions, and let the forum know what we find.  We're
> at 1.3.0 uboot version.
> 
> Vince
> 
>> -----Original Message-----
>> From: Fillod Stephane [mailto:stephane.fillod@thomson.net] 
>> Sent: Thursday, August 14, 2008 8:06 AM
>> To: Vince Asbridge; linuxppc-embedded
>> Cc: u-boot@lists.denx.de
>> Subject: [PATCH] RE: Some memory (DDR2 ECC Dual Rank) just 
>> doesn't work! Can anyone pointme to how to debug this hang?
>>
>> Vince Asbridge wrote:
>>> We have an 8548 design, which implements a DDR2 on a SODIMM 
>> We have an 
>>> issue with dual rank memory (specific part number Viking 
>> VR5DR287218EBSS1), which is a 1G ECC Registered SODIMM part, 
>> with two ranks.
>>> Our platform wires CS0 and CS1 to the SODIMM slot. 
>>> At uBoot, all is well.  Memory is discovered as ECC 533, 1G 
>> DDR2 64Bit 4 beat bursts, and mtest can read and write all 1G 
>> of the SODIMM.
>> [...]
>>> Other DDR2s (identical except for vendor and # of ranks), 
>> work perfectly! 
>>> Anyone got a clue what I could look at to try to figure this out? 
>>> We've tried enable / disable ECC at uboot We've tried 
>> enable / disable 
>>> Interleaving at uboot uboot always works (and can read/write entire 
>>> DDR), Linux always hangs on boot!
>> U-Boot is too gentle when testing SDRAM. Make sure the caches 
>> are enabled under U-Boot, and put on heavy stress with DMA, 
>> pipelined prefetch's, etc.
>> This is what your CPU is enduring under Linux. 
>>
>> Your question is definitely a question for the U-Boot mailing list.
>> BTW, what is the version of U-Boot in use? U-Boot is still 
>> missing the following patch:
>>
>> MPC85xx BA bits not set for 3-bit bank address DIMM of CS1
>>
>> The current implementation set the number of bank address bits
>> (BA) in the processor for CS0 but not for CS1. 
>>
>> Signed-off-by: Stephane Fillod <stephane.fillod@thomson.net>
>>
>> --- u-boot/cpu/mpc85xx/spd_sdram.c
>> +++ u-boot/cpu/mpc85xx/spd_sdram.c
>> @@ -365,6 +365,7 @@
>>                 ddr->cs1_config = ( 1<<31
>>                                     | (odt_rd_cfg << 20)
>>                                     | (odt_wr_cfg << 16)
>> +                                   | (ba_bits << 14)
>>                                     | (spd.nrow_addr - 12) << 8
>>                                     | (spd.ncol_addr - 8) );
>>                 debug("DDR: cs1_bnds   = 0x%08x\n", ddr->cs1_bnds);
>>
>>
>>
>> Otherwise, recompile with -DDEBUG and CFG_CMD_SDRAM, grab the 
>> Viking datasheet and a scope, and a full cup of coffee/tea 
>> much needed during cross-checking :-)
>>


That bug fix, along with many, many others, as well as some
new support for multiple controllers and such are all present
in the DDR re-write patch set that Kumar just posted.  You may
want to try that code too.  It will be replacing the entire
85xx/86xx and eventually the 83xx line of memory controller
initialization.  It also contains some support for a pretty
useful interactive DDR configuration setup mechanism too.

jdl

  reply	other threads:[~2008-08-14 16:31 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-08-14 12:05 [PATCH] RE: Some memory (DDR2 ECC Dual Rank) just doesn't work! Can anyone pointme to how to debug this hang? Fillod Stephane
2008-08-14 16:05 ` Vince Asbridge
2008-08-14 16:31   ` Jon Loeliger [this message]
2008-08-26 21:28 ` Wolfgang Denk

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=48A45DC9.2060601@freescale.com \
    --to=jdl@freescale.com \
    --cc=linuxppc-embedded@ozlabs.org \
    --cc=sshirron@sanblaze.com \
    --cc=u-boot@lists.denx.de \
    --cc=vasbridge@sanblaze.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).