MPC8641D PEX: programming OWBAR in Endpoint mode?

Chen, Tiejun Tiejun.Chen at
Fri Sep 24 00:10:26 EST 2010

> -----Original Message-----
> From: David Hagood [mailto:david.hagood at] 
> Sent: Thursday, September 23, 2010 7:11 PM
> To: Chen, Tiejun; linuxppc-dev at
> Subject: RE: MPC8641D PEX: programming OWBAR in Endpoint mode?
> On Thu, 2010-09-23 at 05:21 +0200, Chen, Tiejun wrote:
> > > I can get the device to show up on the host's PCI bus, I can
> > 
> > This only ensure you can access the PCIe configure space.
> Not quite: I can also read the BARs that I program, and the 
> memory behind them on the PPC.


> > 
> > > program the inbound ATMUs such that the BARS are updated when the 
> > > host (re-)scans them, but I cannot for the life of me get
> > 
> > What value are configured to IntBound REGs?
> I can program them at run time via sysfs on the PPC's side, 
> so there is no single set of values. However, I am pointing 
> them at the PPC's RAM space, and as I stated above, I can 
> read the PPC's RAM from the host side via the BARs.

I read your email again and something hint me. I notice you clarify you
already condigure InBound successfully. Right? If so I'm a bit confused.
For PCIe EP mode PEXIWBARs are not implemented in the memory-mapped
space. If you read any PEXIWBAR these registers always return zero
regardless of writing any value at first. 

You only can program 4 inbound BARs by type 0 configure action like
normal PCIe device.

> > How do you configure OWS of PEXOWAR?
> > 
> > I means you still access that if OWS is match the whole 
> target memory 
> > size even when '0' is as the internal platform address.
> As I understand it, not if the OWS is not correctly mapped on 
> the PPC side - the PEX outbound ATMU's OWBAR must be mapped 
> to a region of the PPCs address space that is also mapped to 
> PEX in the LAW. The LAW does NOT indicate that PPC address 0 
> is mapped to the PEX.

If there is no any law entry for PCIe the kernel should trap machine
check when you access PCIe space. And as my above comment I'm afraid you
mix up InBound and OutBound on EP mode? So you always read zero from
your so-called OutBound? I means that should be PEXIWBAR in fact. I'm
not sure but you can check this.

> > 
> > Out_be32 should be fine for atmu REGs. And also you can refe to the 
> > function, setup_pci_atmu & setup_one_atmu, on the file, 
> > arch/powerpc/sysdev/fsl_pci.c, to know how to access atmu 
> REGs. Often 
> > you should disable them, configure then enable/invoke atmu antry as 
> > normal configuring sequent.
> I have tried disabling the outbound ATMU when I program it, 
> with no change.
> I have looked at the functions you mention, and that is a 
> part of my confusion, as they aren't doing anything different 
> than I am.

I only means you can refer how to access these registers.

> > 
> > Additionally I'm a bit afraid your initial phase :) As you 
> know PCIe 
> > would be used as RC mode on Freescale PowerPC kernel. So I 
> don't know 
> > if you also drop this path on your kernel to conflict each other :)
> I have tried doing this under a kernel built without PCI 
> support with no change.




More information about the Linuxppc-dev mailing list