On 02/25/2010 02:03 PM, Scott Wood wrote:

Benjamin Herrenschmidt wrote:

quoted

On Thu, 2010-02-25 at 07:25 -0700, Gary Thomas wrote:

quoted

I may have been too hasty pronouncing this fixed. Indeed, the
SATA interface now works, but my video card (Fujitsu Coral-P)
does not work when it's mapped at the bottom of the PCI space :-(

With the bridge mapped, the video ends up at a non-zero address
(0xC8000000..0xCFFFFFFF). If it gets mapped to 0xC0000000, it
fails to respond to MMIO accesses.

Any ideas how I might get around this? Is there a way to force
the PCI allocator to start somewhere other than [relative] zero?

I'm not familiar with the way the FSL bridge works, but it would
be possible to invert MMIO and DMA on your PCI bus. IE. Have MMIO go
from 0....2G and DMA from 2G..4G for example. Provided the FSL bridge
can offset the DMA back down to 0 (memory). Can it ?

It can, but I don't see how that would help, if the problem is that the video card doesn't like the low 30 bits of its MMIO address being zero.

Gary, can you check that the MMIO addresses are going to the PCI bus as-is, and aren't being translated down to zero? I.e. POTARn should equal POBARn, and likewise in the device
tree's pci node's ranges.

Hmm, that doesn't match with how I've always had this setup.  I have:
   POTAR0 = 0x00000000
   POTBR0 = 0x000C0000        (0xC0000000 >> 12)

My device tree mappings are:
   ranges = <0x02000000 0x0 0xC0000000 0xC0000000 0x0 0x10000000
             0x01000000 0x0 0x00000000 0xB8000000 0x0 0x00100000>

n.b. I don't run U-Boot on these platforms (being the author
of RedBoot and all... :-)

-- 
------------------------------------------------------------
Gary Thomas                 |  Consulting for the
MLB Associates              |    Embedded world
------------------------------------------------------------