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.

While enumerating the DM816x PCIe bus (programming bridges, etc.) we receive a Data abort exception while attempting to read configuration memory.

While enumerating the DM816x PCIe bus (programming bridges, etc.) we receive a Data abort exception while attempting to read configuration memory.  The exception appears to occur we attempt to read the venderID/deviceID of a non-existent bus/device/function.  The PCIe spec indicates that non-existent devices should read as 0xFFFF, which lets us know there is no device there.  Reading from existing BDFs does not cause the exception.  What is causing this exception?  How can we avoid it?

  • Hi James,

    In what mode you are using the DM816x PCIe - in RC or EP?

    James Reilly99 said:
    The PCIe spec indicates that

    Which PCIe spec?

    James Reilly99 said:
    we receive a Data abort exception

    Can you provide the exact console output when you get this exception?

    See also if the below e2e threads will be in help:

    Regards,
    Pavel

  • RC.

    The PCI Express base specification.

     

  • I can describe the console output to you. "Data Abort" appears, followed by a stack trace dump, and the hex address of the machine language instruction that caused the exception. The instruction is writing a B/D/F value to the PCIESS register that controls PCIe addressing. The VxWorks kernel then restarts.
  • James Reilly99 said:
    The PCI Express base specification.

    Can you provide me a link to that spec?


    Are you using EZSDK or DVR RDK or esle? Are you aligned with the last version of the DM816x linux kernel code base?

    http://arago-project.org/git/projects/?p=linux-omap3.git;a=shortlog;h=refs/heads/ti81xx-master

    When processor attempted to access bad address, there will be data abort. It is expected that you would see processor aborts on reading invalid region of a device connected over PCIe. The application must know the region it tries to access is valid - else be prepared for abort.

    See also if the below links will be in help:

    Regards,
    Pavel

  • Here is a link to the PCI express special interest group.  However, I think you must be a member to download the specification.

    https://www.pcisig.com/specifications/pciexpress/

    We're using VxWorks, not Linux.

    Attempting to read the device id and vendor id from configuration memory is a valid memory access during bus enumeration.  Here is a link to a wiki page that describes bus enumeration.  Please see the quoted paragraph below.

    http://en.wikipedia.org/wiki/PCI_configuration_space

    "If no response is received from the device's function #0, the bus master performs an abort and returns an all-bits-on value (FFFFFFFF in hexadecimal), which is an invalid VID/DID value, thus a device driver can tell that the specified combination bus/device/function (B/D/F) is not present. So, when a read to a function ID of zero for a 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."

     

  • James,

    James Reilly99 said:

    Here is a link to the PCI express special interest group.  However, I think you must be a member to download the specification.

    https://www.pcisig.com/specifications/pciexpress/

    This seems to be 3.1 spec, while DM816x PCIe peripheral conforms to the PCI Express Base 2.0 Specification. Can you if you have the same within the 2.0 spec?

    Regards,
    Pavel

  • I do not have a copy of the 2.0 spec, but this description of the original PCI bus (see link below) shows that this method of enumerating devices was in the original PCI spec. That is, it has been part of the standard from the beginning and inherited subsequently by PCI Express 1.0, 2.0, 3.0, and 3.1.
    en.wikipedia.org/.../PCI_Configuration_Space
  • The "Unhandled fault" problem is similar to our problem. We are accessing configuration memory though. I think he is addressing device memory via a BAR.
  • I downloaded the Linux source code for the TI DM816xx and looked at the PCIe RC device driver.  It includes an exception handler for 'data abort'.  The handler replaces the value read from PCIe memory space with all 1s. 

  • It appears that these memory exceptions are normal.  They occur whenever a read is attempted to a non-existent PCIe device.  In pcie.c (part of the BSP) there is code that uses vxMemProbe to read without generating an exception.  It is in the pcConfigReadRemote function.  If the read fails, 0xFFFFFFFF is returned.

    I've started using this functoin to read from pci config space.  I no longer get the exception.  However, I still cannot read anything except bus zero config space.  The bridges should be configured, assuming that writes to config memory work, but still, any attempt to read from any bus other than zero returns 0xFFFFFFFF.