Hi Thomas,

first of all thank you for your invaluable help!

On 02/18/2014 09:27 PM, Thomas Petazzoni wrote:

Dear Gerlando Falauto,

On Tue, 18 Feb 2014 18:29:56 +0100, Gerlando Falauto wrote:

quoted

I tried these settings (a long time ago) and everything seemed to work
fine. Except, we now have a different problem.
Essentially, this device requires 128MB for a given BAR to provide a
PCI-to-localbus bridge. (another BAR provides the configuration space to
configure chip select regions and so on).
Apparently, only the first 64MB of this BAR seem to work correctly with
the new driver. As soon as you exceed that, reads (always?) return 0.
Other BARs (which are then of course assigned a higher region) seem to
work just fine, so it looks like a per-BAR limitation.

This was not a problem with a 3.0 kernel. Do you have any idea what
could be wrong here?
I'm currently using a 3.10 kernel, where your patches for the pci-mvebu
driver were forcibly brought in (without full support for the MBUS
description at device tree level though).

[...]

quoted

mvebu-pcie pcie-controller.1: PCIe0.0: link up
mvebu-pcie pcie-controller.1: PCI host bridge to bus 0000:00
pci_bus 0000:00: root bus resource [io  0x1000-0xfffff]
pci_bus 0000:00: root bus resource [mem 0xe0000000-0xefffffff]
pci_bus 0000:00: root bus resource [bus 00-ff]
pci 0000:00:01.0: [11ab:7846] type 01 class 0x060400
PCI: bus0: Fast back to back transfers disabled
pci 0000:00:01.0: bridge configuration invalid ([bus 00-00]), reconfiguring
pci 0000:01:00.0: [10ee:0008] type 00 class 0x050000
pci 0000:01:00.0: reg 10: [mem 0x00000000-0x00000fff]
pci 0000:01:00.0: reg 14: [mem 0x00000000-0x07ffffff]
pci 0000:01:00.0: reg 18: [mem 0x00000000-0x00000fff]
pci 0000:01:00.0: reg 1c: [mem 0x00000000-0x007fffff]
pci 0000:01:00.0: reg 20: [mem 0x00000000-0x00001fff]
pci 0000:01:00.0: reg 24: [mem 0x00000000-0x00000fff]
pci 0000:01:00.0: supports D1 D2
pci 0000:01:00.0: PME# supported from D0 D1 D2 D3hot
PCI: bus1: Fast back to back transfers disabled
pci_bus 0000:01: busn_res: [bus 01-ff] end is updated to 01
pci 0000:00:01.0: BAR 8: assigned [mem 0xe0000000-0xebffffff]
pci 0000:01:00.0: BAR 1: assigned [mem 0xe0000000-0xe7ffffff]

So I guess this one is the 128 MB BAR, right?

That's correct.

quoted

pci 0000:01:00.0: BAR 3: assigned [mem 0xe8000000-0xe87fffff]
pci 0000:01:00.0: BAR 4: assigned [mem 0xe8800000-0xe8801fff]
pci 0000:01:00.0: BAR 0: assigned [mem 0xe8802000-0xe8802fff]
pci 0000:01:00.0: BAR 2: assigned [mem 0xe8803000-0xe8803fff]
pci 0000:01:00.0: BAR 5: assigned [mem 0xe8804000-0xe8804fff]

So in total, for the device 0000:01:00, the memory region should go
from 0xe0000000 to 0xe8804fff. This means that a 256 MB window is
needed for this device, because only power of two sizes are possible
for MBus windows.

Can you give me the output of /sys/kernel/debug/mvebu-mbus/devices ? It
will tell us how the MBus windows are configured, as I suspect the
problem might be here.

Here it goes:

[00] disabled
[01] disabled
[02] disabled
[03] disabled
[04] 00000000ff000000 - 00000000ff010000 : nand
[05] 00000000f4000000 - 00000000f8000000 : vpcie
[06] 00000000fe000000 - 00000000fe010000 : dragonite
[07] 00000000e0000000 - 00000000ec000000 : pcie0.0

So there's something wrong: a 256MB window should go all the way up to 
0xf0000000, and we have 192MB instead and I don't know how that would be 
interpreted.
I couldn't figure out where this range comes from though, as in the 
device tree I now have a size of 256MB (I stupidly set it to 192MB at 
some point, but I now changed it):

# hexdump -C /proc/device-tree/ocp at f1000000/pcie-controller/ranges
  | cut -c1-58
00000000  82 00 00 00 00 00 00 00  00 04 00 00 00 04 00 00
00000010  00 00 00 00 00 00 20 00  82 00 00 00 00 00 00 00
00000020  e0 00 00 00 e0 00 00 00  00 00 00 00 10 00 00 00
                                                ^^^^^^^^^^^
00000030  81 00 00 00 00 00 00 00  00 00 00 00 f0 00 00 00
00000040  00 00 00 00 00 10 00 00
00000048

But apart from that, what I still don't understand is how that could 
have anything to do with my problem. The memory area I'm not able to 
access starts at 0xe4000000.
BAR0, on the other hand, spawns 0xe8802000-0xe8802fff and seems to work 
fine.

Any ideas?

Thanks a lot!
Gerlando