• State
  • Locked Locked
  • Replies 3 replies
  • Subscribers 101 subscribers
  • Views 1282 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.

TDA4VM: Unable to access PCIe Endpoint

Thomas Dedler
Intellectual 310 points

Part Number: TDA4VM

Hello,

I'm currently trying to use a J721E EVM to access via PCIe a Xilinx FPGA with PCIe IP core. The J721E is the RC, the FPGA the EP. As driver I use the LLD of the RTOS SDK 07_03_00_07, resp. pdk_jacinto_07_03_00_29.

Unfortunately, in the Jacinto SDK there is no PCIe example. Surprisingly, I found one in the Sitara SDK resp. PDK (pdk_am65xx_07_03_00_54, the path there is \pdk_am65xx_07_03_00_54\packages\ti\drv\pcie\example\sample\j721e\src). Based on this example I've built my own application to set up the PCIe controller. With this it is at least possible to establish a link between the the Jacinto and the FPGA. This is indicated by the PCIE_USER_LINKSTATUS register.

However, I'm not able to access any data on the FPGA. If I access the expected address ranges (see questions below), the debugger gets disconnected and I need a power cycle to be able to reconnect. It looks like some exception occurred.

I'm relatively new to PCIe, probably I've just made some beginner's mistake. So becoming clearer about how PCIe works (not only) on the Jacinto might already be part of the solution:

Since I'm relatively new to PCIe, maybe the problem can already be solved by just getting a correct understanding of how PCIe works (not only) on the Jacinto: 

Q1) As I understand, access to the config space of the EP is standardized and should always be possible. Thereto I took the Outbound ATU configuration from the Sitara example:

Now my expectation was that I just have to read from the base address configured in the ATU to get the data (which there was 0x18010000, and which is also on the Jacinto part of the PCI address space). According to my understanding, the read access will trigger the PCIe controller to send a Configuration Read TLB, which is completed by the EP. Is this assumption correct, or do I need any additional / other configuration to access the config space? Currently, reading from 0x18010000 does not work. 

Q2) As I've seen in the example that for an Outbound ATU memory region on one side, a matching inbound ATU memory region and a BAR on the other side is configured. My expectation for a read request was, that I have to read from the base address configured for the Outbound ATU region (in the example: 0x19000000). The PCIe controller will generate from this read access a Read Memory TLP. When this matches the configured BAR and Inbound Region on the EP, a Completion TLP is sent back to the RC and the data is presented to the originator of the read access. Here I also get an exception if I try to read from 0x19000000.

  • 0
    Intellectual 310 points

    In the meantime, I was able to access the configuration space, so Q1 is solved.

    The reason was that the address 0x18010000 used for the data region was not correct. I did not notice, that the Sitara example uses PCIE1 (where this address belongs to) and not to PCIE0 (which I was using). For PCIE0, the data region starts at 0x10000000.
    Even more confusing here was, that in the Reference Manual, only the PCIE1 registers are described, so the addresses matched with the example. Furthermore, the usage of data registers (PCIE_DATA_MEM_y) is not described at all. I hope, this will be improved in further revisions.

    So the current status is: link is available, the config space can be accessed, but Q2) remains open. Even when using the correct data registers for PCIE0, memory accesses still do not work.

    My expectation would be, that if I configure my outbound ATU for a specific PCIe address and write the same PCIe address to a BAR in the endpoints config space, the TLPs are accepted by the endpoint.

    Are there any other settings that need to be done? is there any difference on RC side if the EP uses DMA to access its memory or not (I would expect, this is not the case)?

  • 0 in reply to Thomas Dedler
    Expert 2611 points

    Hi Thomas,

    my experience with the TI PCI LLD are "mixed".

    First of all, the current TRM of TDA4 has a lot of missing information about PCIe module registers. The previous version of the TRM is for this case better suited.

    Secondly, the TI PCI LLD does support the "basic TI example", but not much more. (For example, there is no support for multiple physical functions on EP configuration)

    I have used the code as starting point but had put a lot of time in it, to make it more flexible and fixed some issues.

    I have also discovered, that some BAR/ATU settings got overwritten by LLD functions. So be carefull and double check the actual data within the PCIe module registers.

    I remember that memory access was not working if the actual configured memory address for the inbound ATU was not aligned to the BAR (departure) size. Maybe thats worth to check in your case.

    Your expectation is correct for my understanding. You would add an inbound ATU to map the PCIe address to an actual system address (for example some memory) of TDA4.

    Best regards
    Thomas

  • 0 in reply to Thomas Dorsch
    Intellectual 310 points

    Yes, I also noticed that the LLDs are not always trustworthy (not only for PCIe!) and switched more and more to writing the registers directly when I was trying new settings. Since the example is not included in the current SDK, I also assumed that there may be some bugs and worked myself through the documentation in parallel to using the driver. 

    The hint with the old TRM is very helpful. Coincidentally I still had an old version on my hard drive, and yes, it looks really much better than the new one. With this document, it wouldn't have taken so long to figure out the correct data addresses, as there all registers are clearly and completely documented.

    I'll also check to inbound configuration, maybe this helps. At least it's good to know that the basic understanding is correct, so thank you for he confirmation!