PCIe enumeration

Kjetil,

Are you running any PCIe driver customized for C6678 for the PCIe bus enumeration please?

Can you read vendor ID from the existing device correctly please?

If not, does the vendor ID be read from the PCIe remote configuration region of C6778, i.e. 0x21802000?

Is the CFG_SETUP register being setup correctly for the target PCIe device on the bus, i.e. the bus/device/function numbers are set correctly please?

We would like to see if your software driver is working to read vendor ID correctly from the existing device first. Thanks.

Hi,

We are using our own driver, that utilizes cslr definitions from the c6678 PDK.

If CFGSETUP is configured to point to a existing device. I can read the correct vendor ID from the remote configuration window. (0x21802000)

However, if CFGSETUP is configured to point to a non-existing device, the value read from 0x21802000 appears to be random. Thus it can not be used to perform reliable enumeration.

-

Kjetil

1. Have you tried to set the TYPE bit to 0 or 1 in the CFG_SETUP register to see any difference of reading from the non-existing device please?

2. There is one wiki page talking about  PCIe RC driver user guide for TI81xx, which is using the similar PCIe module as C667x. You can take a look to see if any idea about the enumeration, such as the Numbering and Topology.

http://processors.wiki.ti.com/index.php/TI81XX_PCI_Express_Root_Complex_Driver_User_Guide

3. It would be helpful to use the PCIe bus analyzer to locate the issue such as to see if the C6678 issues the command correctly or the return packets from endpoint or PCIe bridge carry the correct values.

Hi,

1. Changing the type bit of the CFGSETUP register changes the behaviour. (Changing from type 1 to type 0). The device connected directly to the DSP responds to all Type 0 accesses, regardless of the actual bus,device settings. Which I guess is OK. (According to the PCIe base specification (2.1 chapter 7.3.1), only type 0 configuration request targeting device 0 on a physical link is allowed, so accesses to any other device on the local pcie bus should be filtered away by the driver)

2. I had a look at the RC driver for Linux and it confirmed my assumptions about the setup/handling of Bus#0 and Bus#1. (Bus#0 is a virtual bus mapping to the local configuration window. Bus#1 is the external bus going to the downstream device (Should generate Type 0 configuration accesses, and all other buses should generate Type 1 accesses)

3. Unfortunately I do not have access to a PCIe bus analyzer.

Can you confirm that the PCIe core in the C6678 should return 0xFFFFFFFF on all configuration space accesses that are terminated by unsupported request ?

Hi again,

I had a closer look at the RC driver for the TI81XX, and it appears to be the "ti81xx_pcie_fault" interrupt handler that is generating the 0xFFFFFFFF return value on this device. Which is hooked into the fault signals of the internal DSP Bus, and not the PCIe peripheral.

Does the C6678 operate in a similar manner, or should the PCIe peripheral return 0xFFFFFFFF on reception of external error messages on the PCIe interface ?

Kjetil,

I am not familiar with the RC driver. But I think the C667x should handle the fault signals of the internal DSP bus similarly as the TI81xx (although TI81xx is using ARM).