Maker Pro
Maker Pro

PCI configuration transaction problem

G

Guenter Ebermann

Jan 1, 1970
0
We have designed a PMC card for FlexRay (time triggered bus sytem used
in the automotive sector) based applications.

Our Setup (PMC Card):
- CPU: MPC5200B (acts as PCI-Arbiter)
- PCI Bridge: PI7C8150B (driven in asynchronous mode)
- components also connected to the extended local bus of the MPC5200B:
Flash, USB, FPGA, CPLD

We are using our PMC card plugged into a PCI slot (via a PMC Carrier
Card) to use it in normal PC's.

We have succesfully made startups of the whole board.

At last we are trying to test the PCI unit and we discovered the
following problem when trying to make PCI configuration read accesses
from the host PC (linux 2.4.27, debian sarge) to the target MPC5200B
(RedBoot, initializing the PCI unit):

When the computer (host) starts, the linux-kernel is able to correctly
read out the Vendor and Device-ID from the PCI Bridge and the MPC5200
device, during traversing the PCI bus upon boot to configure all
connected devices. This can be tested using lspci (pciutils package)
after booting (this command reads out the PCI data structures of
the kernel) or enabling PCI debug messages in the kernel and watch
console output during boot time.

After booting we made several tests to read out the configuration
section of the PCI bridge in a loop comparing them with previous
reads. This test went ok.

But when we are trying to read the PCI configuration section of the
MPC5200B, we get differing results mostly every time. We read out the
configuration section by reading from the proc file system (e.g. xxd
/proc/bus/pci/devices/02/0a.0 reading the whole configuration
area). The kernel then makes a PCI Type 1 configuration transaction to
the PCI bridge, which in turns makes a PCI Type 0 transaction to the
MPC5200B for each byte we want to read.

We also issue setpci -d<VENDOR><DEVICE> VENDOR_ID/DEVICE_ID to trigger
exactly one PCI read transaction from the MPC5200 confiuration area.
For the Vendor and Device ID registers we get 0xFFFFFFFF. This is
strange since the linux kernel itself read out the right values during
boot time.

Furthermore, when we read out the PCI status registers of the Bridge,
we see that Bit 29 (Received Master Abort) and Bit 31 (Detected Parity
Error on secondary side) are both set to 1. When we read out the status
registers of the MPC5200 the parity error bit is set there too.

Do you have any idea, what could cause such a behaviour?
Thanks!
Guenter Ebermann

P.S.: We can send parts of our schematic to interested partys.
 
G

Guenter Ebermann

Jan 1, 1970
0
I am posting this answer here, just if other people has
similar problems making startups with their pci-boards.

Our problem was with the clock: We connected the
clock output from the MPC5200B to the an internal
prescaler of the Asynchrous PCI bridge just to feed-back
the prescalers output to the real clock intput of the Bridge.

As we connected the MPC5200 clock output directly to the
bridge clock input the board worked (PCI transactions ...).

The bridge just had the possibility of the prescaler to
directly connect an oscillator to it and use the output
of the prescaler as clock input for the secondary PCI bus.
It was not meant to be used as clock source if another
device generates the clock (in our case the MPC5200), as
this will generate a phase shift in how the MPC5200 generates
the clock and the Bridge sees the clock (because if the bridge's
internal prescaler).
 
Top