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 <vbars...@ru.mvista.com>
Signed-off-by: Mikhail Zolotaryov <le...@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

Yes, but until u-boot is fixed this will break Sequoia/Rainier support.
Thanks,
Valentine.
_______________________________________________
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Reply via email to