Hi Mike,
you wrote:
"Row address bits : 13
DDR0_02 = 0x020C0E01
DDR0_42 = 0x0006"
Register values above define that memory has 14 row address bits. The
correct setting is (for CAS Latency = 3):
DDR0_42 = 0x0106
Best regards,
Mikhail Zolotaryov
Mike Nuss wrote:
(t
.
P.S. Sequoia board also has DDR2 SDRAM from Micron.
Best regards,
Mikhail Zolotaryov
Mike Nuss wrote:
There was a fix a while back called "Correct memory size calculation for
Denali based boards" that corrected the data width detection in the 4xx
bootwrapper.
This seems to ha
Benjamin Herrenschmidt wrote:
On Wed, 2009-09-09 at 17:40 +0300, Mikhail Zolotaryov wrote:
Hi Tom,
In my case __dma_sync() calls flush_dcache_range() (it's due to
alignment) from a tasklet - no OOPS. It uses dcbf instruction instead of
dcbi - that's the difference as d
in 180 seconds..
Cheers,
Tom
Mikhail Zolotaryov wrote:
Hi Tom,
possible solution could be to use tasklet to perform DMA-related job
(as in most cases DMA transfer is interrupt driven - makes sense).
Tom Burns wrote:
Hi,
With the default config for the Sequoia board on 2.6.24, calling
pci_d
.
Regards,
Tom Burns
International Datacasting Corporation
Mikhail Zolotaryov wrote:
Hi,
Why manage cache lines manually, if appropriate code is a part of
__dma_sync / dma_sync_single_for_device of DMA API ? (implies
CONFIG_NOT_COHERENT_CACHE enabled, as default for Sequoia Board)
Prodyut
Hi,
Why manage cache lines manually, if appropriate code is a part of
__dma_sync / dma_sync_single_for_device of DMA API ? (implies
CONFIG_NOT_COHERENT_CACHE enabled, as default for Sequoia Board)
Prodyut Hazarika wrote:
Hi Adam,
Yes, I am using the 440EPx (same as the sequoia board).
Hi Leonid,
probably, the following article on PPC DMA could help:
http://lebon.org.ua/?p=5
Best regards,
Mikhail Zolotaryov
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
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
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 pag
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 bit
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 multipl
The solution is to print device_node full_name instead. After applying
the patch proposed, error string is like the following:
/plb/opb/ether...@ef600e00: reset timeout
Signed-off-by: Mikhail Zolotaryov
--- linux-2.6/drivers/net/ibm_newemac/core.c.orig 2009-03-10
20:24:12.0
However, "1" is decoded as 64 bit (8 byte), "0" - as 32 bit (4 byte) bus
by the kernel code. My understanding is this is not correct - patch
attached.
You are missing the Signed-off-by tag that is needed.
I'm sorry.
Signed-off-by: Mikhail Zolotaryov
Aside
Hi,
according to the PPC440EPx Embedded Processor User Manual (rev 1.14)
DDR0_14[REDUC] bit has the following meaning:
REDUC - Enable the half data path feature of the controller
0 = Standard operation using full 64/72-bit memory bus
1 = Memory data path width is 32/40 bits
However, "1" is de
14 matches
Mail list logo
