[PATCH] PowerPC 440EPx/GRx fix memory size calculation

Josh Boyer jwboyer at linux.vnet.ibm.com
Thu Mar 12 08:57:28 EST 2009


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 <vbarshak at ru.mvista.com>
>>> Signed-off-by: Mikhail Zolotaryov <lebon at lebon.org.ua>
>>
>> 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



More information about the Linuxppc-dev mailing list