From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from buildserver.ru.mvista.com (unknown [213.79.90.228]) by ozlabs.org (Postfix) with ESMTP id D345DDDFA9 for ; Thu, 12 Mar 2009 09:13:43 +1100 (EST) Message-ID: <49B8367B.5060402@ru.mvista.com> Date: Thu, 12 Mar 2009 01:08:59 +0300 From: Valentine MIME-Version: 1.0 To: Josh Boyer Subject: Re: [PATCH] PowerPC 440EPx/GRx fix memory size calculation References: <49B58779.9040905@lebon.org.ua> <20090310195013.GA27835@ru.mvista.com> <20090311103716.GE26415@zod.rchland.ibm.com> <49B80BA3.1090301@ru.mvista.com> <20090311215728.GA12676@zod.rchland.ibm.com> In-Reply-To: <20090311215728.GA12676@zod.rchland.ibm.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Cc: linuxppc-dev@ozlabs.org, Stefan Roese , lebon@lebon.org.ua List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Josh Boyer wrote: > On Wed, Mar 11, 2009 at 10:06:11PM +0300, Valentine Barshak wrote: >> Josh Boyer wrote: >>> On Tue, Mar 10, 2009 at 10:50:13PM +0300, Valentine Barshak wrote: >>>> I was just going to submit a patch for that too. >>>> Indeed, the denali_fixup_memsize() miscalculated a couple of address >>>> field widths. We were lucky to eventually get the right result, >>>> because the effect of the first error was killed by the other one. >>>> According to the AMCC 440EPX/GRX user manual, >>>> the Chip Select width is always fixed at 1 bit no matter >>>> what is actually read from register DDR_10. >>>> The workaround is to use a predefined chipselect value for 440EPx/GRx. >>>> Also, setting the REDUC bit (REDUC = 1) enables 32-bit data path. >>>> If REDUC = 0, full data path of 64 bits is used. >>>> >>>> Signed-off-by: Valentine Barshak >>>> Signed-off-by: Mikhail Zolotaryov >>> I've been looking over this one a bit more. At the moment, I'm inclined >>> to queue this up in my -next branch. I would like to see if Mikhail >>> could test it though, and have Valentine answer the question in the hard >>> wired part. >> I've been looking at the docs once again and actually I couldn't find an >> explanation there. And I don't have that e-mail from AMCC support that >> I got a while back regarding the issue anymore. >> There might have been some misunderstanding. >> The docs (PPC440EPX UM 19.2 Device Address Mapping) say that the chip >> select field width is always fixed at one bit, but this doesn't actually >> mean that there's always one chip select used. >> The patch works fine on Sequoia and another Sequoia-like board with 1GB >> RAM installed, but it might not work with 2GB RAM. I've tried to play >> with DDR0_10 settings and Sequoia works fine regardless of what's >> actually written to DDR0_10. >> So, probably the best way would be to fix that in u-boot >> amcc/sequoia/sdram.c by doing mtsdram(DDR0_10, 0x00000100); instead of >> mtsdram(DDR0_10, 0x00000300); >> Sorry, for confusion, but after reviewing the docs, I think that >> only REDUC interpretation has to be fixed. The chips select part should >> be fixed in u-boot sdram code for Sequoia as was originally proposed by >> Mikhail. > > Ok, so we're back to using Mikhail's original patch then? > > josh Yes, but until u-boot is fixed this will break Sequoia/Rainier support. Thanks, Valentine.