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.

Linux/AM5716: PCIe byte access issue

Part Number: AM5716
Other Parts Discussed in Thread: XIO3130, , AM5728

Tool/software: Linux

We are using the AM5716 with an XR17V358 (PCIe uart) connected through an XIO3130 PCI Express Switch.  The OS is Linux 4.4.32 kernel that was supplied in the TI SDK.  We are using PCIe-0 in X1.

Linux detects and enumerates the root complex. the XIO3130 and the ports on the XR17V358 but we have found that byte access to the uarts returns the correct value only if the address is on a 4 byte boundary.

If we issue a dword read on a 4 byte boundary, the 4 bytes are read correctly.

Any idea what is causing this behaviour?

  • Please see AM571x Errata i870.
  • My understanding is that errata i870 applies to EP mode not RC mode which we are using.

    I have also seen errata i909 but our device tree defines the memory range as 0x20013000-0x2fffffff.

    I see another post regarding a similar problem on the am5728 (e2e.ti.com/.../2212507)
  • Hello,

    i870 applies to both EP and RC modes.

  • You are correct. Although it is not clear in the description of errata i870, it does appear to apply to both EP amd RC modes.
    I set the PCIE_SS1_AXI2OCP_LEGACY_MODE_ENABLE bit in the CTRL_CORE_SMA_SW_7 Control Module register
    and the correct byte values are now returned even for non 32 bit aligned addresses.
    However this is not a practical workaround for our situation because this sets all byte enables to 1
    in the Read TLP.
    This is a problem for us because our endpoint device is an XRV17358 (uart) where the 8 bit registers
    contain interrupt status, rx data etc in the same 4 byte region.
    Reading the interrupt status register appears to result in the endpoint device to also reading the
    RX data register. Now when the interrupt service routine checks if there is any data, there isn't any.

    Is there another solution for this issue?

  • Hello,

    I agree that the description of the issue could be made a bit more clear. I've filed an internal document update request to add clarification to i870; it should appear in the next revision of the Errata document.

    No, there is no other workaround for this particular issue.