• State Resolved
  • Locked Locked
  • Replies 2 replies
  • Subscribers 98 subscribers
  • Views 22001 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

PCIe Enumeration Procedure

Scott Olson
Intellectual 280 points

I have a c6678 EVM LE connected to a PEX8606 RDK (PCIe switch) which is also connected to a motherboard (to supply power and refclk).  I have set the upstream port on the PEX RDK to the port the TI c6678 EVM is plugged into.  It is my understanding that I must enumerate the PCIe bus in order to communicate between c6678 and PEX PCIe switch.  I have some example code that was sent to me to enumerate the bus but I am having a difficult time debugging it, because I am unclear on what exactly enumerating the bus means, and why it is necessary.  Are there any relevant code samples that show how to enumerate the PCIe bus from the c6678?  

Thanks!

-Scott

  • 0
    TI__Genius 12065 points

    Scott,

    Since there is no direct method for the BIOS or OS to determine which PCI/PCIe slots have devices installed (nor the functions the device implements) the PCI/PCIe bus(es) must be enumerated. Usually the bus enumeration will be done by the system's firmware/device drivers or the operating system in the host/Root Complex.

    Bus enumeration is performed by attempting to read the Vendor- and Device ID register for each combination of bus number and device number, at the device's function #0.

    If there is no device that implements the function zero (i.e., vendor and device ID registers), the host performs an abort and returns all 1s in binary (hexadecimal FFFFFFFF). All ones is an invalid VID/DID value, thus a device driver can tell that the specified combination bus/device/function (B/D/F) does not exist. So, when a read to a function ID of zero for given bus/device causes the master (initiator) to abort, it must then be presumed that no working device exists on that bus because devices are required to implement function number zero. In this case, reads to the remaining functions numbers (1–7) are not necessary as they also will not exist.

    When a read to a specified BDF combination vendor ID register succeeds, the BIOS or OS knows it exists. It write all 1s to the BARs, and read back the devices requested memory size in the form of 0s where don't care address is. The design implies that all address spaces used are a power of two and are naturally aligned. At this point BIOS or OS program the memory mapped and I/O port addresses the function will respond to into the devices' BAR configuration register. These addresses stay valid as long as the system remains turned on. On power off, all these settings are lost and on the next system boot, the configuration procedure is repeated all over again. 

    You can take a look at the PCI/PCIe protocol standard document at PCISIG or other documents regarding to the details of the bus enumeration.

    It looks like you plan to plug C6678 device into the PCIe slot on the motherboard as an endpoint, you may need to run the PCIe host/root complex driver on the motherboard host in order to find and configure the C6678 device and the other PCIe devices, such as the PCIe switch.

    While there is no Root Complex driver provided for C6678 by TI, there are RC driver on Linux for the other TI devices (such as TI81xx) which have the similar PCIe module as C6678. Please take a look at the following wiki page and hope it helps.

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

  • 0 in reply to Steven Ji
    Intellectual 280 points

    Hi Steven, I don't plan on using a motherboard at all... For the hardware prototyping I am using a motherboard solely to provide power and REFCLK to the PCIe switch dev board.  My intention is to use the C6678 to enumerate the switch and anything connected to the switch.  I have read over the link you supplied and it is helpful.  The information you provided is about 100 times more helpful than the PCIe protocol standard.  That is an awfully written document when approached from the perspective of writing software to interface with PCIe devices.