Hi Guys:
Sequoia uses on board discrete memory with one rank. So one chip
select would be fine.
Turning on both won't matter, since the other cs is never used.
Feng Kan
Stefan Roese wrote:
On Wednesday 11 March 2009, Valentine Barshak wrote:
I've been looking at the docs once again
On Wednesday 11 March 2009, Valentine Barshak wrote:
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.
On Thu, 2009-03-12 at 07:02 +0100, Stefan Roese wrote:
I'll apply the U-Boot patch today. But as Josh pointed out, we should
try to
find a way for the bootwrapper to work in all cases.
uboot is passing some kind of bt_t to the wrapper or a full
device-tree ?
Ben.
On Thursday 12 March 2009, Benjamin Herrenschmidt wrote:
On Thu, 2009-03-12 at 07:02 +0100, Stefan Roese wrote:
I'll apply the U-Boot patch today. But as Josh pointed out, we should
try to
find a way for the bootwrapper to work in all cases.
uboot is passing some kind of bt_t to the
On Thu, 2009-03-12 at 09:05 +0100, Stefan Roese wrote:
Both is possible. Older U-Boot versions only passed the bd_t struct to the
kernel. For those U-Boot's the wrapper is needed. More recent U-Boot versions
support passing a device-tree blob to the kernel. U-Boot patches the correct
On Thursday 12 March 2009, Benjamin Herrenschmidt wrote:
On Thu, 2009-03-12 at 09:05 +0100, Stefan Roese wrote:
Both is possible. Older U-Boot versions only passed the bd_t struct to
the kernel. For those U-Boot's the wrapper is needed. More recent U-Boot
versions support passing a
Stefan Roese wrote:
Either get the mem
size from there or some flag or version in there can indicate if it's
been fixed.
I don't think that we have some flag and/or version information in the bd_info
struct. And extending this struct doesn't sound like a good idea to me.
May I suggest an
On Thu, Mar 12, 2009 at 09:24:13AM +0100, Stefan Roese wrote:
On Thursday 12 March 2009, Benjamin Herrenschmidt wrote:
On Thu, 2009-03-12 at 09:05 +0100, Stefan Roese wrote:
Both is possible. Older U-Boot versions only passed the bd_t struct to
the kernel. For those U-Boot's the wrapper is
On Thursday 12 March 2009, Josh Boyer wrote:
Yes, that's also how I use it on canyonlands... now, the wrapper could
probably be used to look at the bd_t anyways, no ?
Sure.
Do newer U-Boot versions pass both the dtb and the bd_t?
Both is possible. The user can choose by using different
Benjamin Herrenschmidt wrote:
The problem is that the controller is hardwired to use only one
chipselect, even if both are enabled in the DDR0_10 on PPC440EPx/GRx
processors
Mikhail, can you verify that Valentine's patch works for you ?
Ben, unfortunately on my board(s) I don't have both
Valentine wrote:
The problem is that the controller is hardwired to use only one
chipselect, even if both are enabled in the DDR0_10 on PPC440EPx/GRx
processors.
It's new information for me. Is this problem described by some ERRATA or
manual, could you please point me to the document (and
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
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
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
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
On Thu, Mar 12, 2009 at 01:08:59AM +0300, Valentine wrote:
So, probably the best way would be to fix that in u-boot
amcc/sequoia/sdram.c by doing mtsdram(DDR0_10, 0x0100); instead
of mtsdram(DDR0_10, 0x0300);
Sorry, for confusion, but after reviewing the docs, I think that
only
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
Valentine Barshak wrote:
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.
Well, from my point of view original kernel code is correct in this part.
Adding one bit into memory address means
Mikhail Zolotaryov wrote:
Valentine Barshak wrote:
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.
Well, from my point of view original kernel code is correct in this part.
Adding one bit into
Yes, you could phrase it that way. According to the PPC440EPx manual,
the total memory size is calculated based on the following formula:
memsize = cs * (1 (col+row)) * bank * dpath;
So, if both chipselects are used, we add an extra bit to the memory
address to distinguish between these
20 matches
Mail list logo
