• State
  • Locked Locked
  • Replies 5 replies
  • Subscribers 101 subscribers
  • Views 8541 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

AM3894 PCIe Root complex: LTSSM stops in Polling compliance status

SACHIN KURAWATTI81378
Prodigy 100 points
Other Parts Discussed in Thread: AM3894

Hi,

 

We have a system in which, AM3894 and Xilinx FPGA is present. Below is details of the system.

  • AM3894 is configured as root complex
  • AM3894 X1 lane is connected to FPGA and the unused lane of the AM3894 is unconnected or left open.
  • Xilinx is 2.5Gts X1 lane End point

The system is inconsistent in detecting PCIe interface

We are able to see Xilinx Endpoint with LSPCI command on Linux. In the failure condition we have read LTSSM status bits. During link training failure LTSSM value is states Polling Compliance.

We are using the same software package as of 816x/389x EVM from Digital Spectrum.

Please can anyone suggest solution for this issue.

 

Regards,

SMK

  • 0
    TI__Expert 5685 points

    Hello,

    Please provide following:

    1) I assume FPGA board is powered separately, right? What is the POR sequence you are using?

    2) How is the 100MHz ref clk provided to FPGA?

    3) Can you provide the LTSSM dump - at least first few transitions?

    4) Which PSP release are you using?

       Hemant

  • 0 in reply to HemantPedanekar
    Intellectual 430 points
    1) I assume FPGA board is powered separately, right? What is the POR sequence you are using?

    Yes. We are powering on the FPGA after all the voltages on AM3894 processor module are stable. Since 0.9V is the last voltage in processor module, we are using the power good of  0.9V regulator to enable the power to FPGA.

    We are connecting the RSTOUTn  output of processor to reset of FPGA.The total POR duration is 580ms. (We also checked with 1.25sec POR duration, but result is same).

    1. The RSTOUTn is asserted low for around 216ms after the FPGA is configured(FPGA Done)
    2. 100MHz ref clk is stable 110ms before FPGA is configured. 

    Refer below image for better understanding.

    2) How is the 100MHz ref clk provided to FPGA?

    We are using the same clock generator used in DM816x EVM. One of the 100MHz clock o/p  is provided to AM3894 & other o/p clock is provided to FPGA.

    3) Can you provide the LTSSM dump - at least first few transitions?

    Attached pcie_working.TXT is for working condition.

    1805.pcie_working.TXT

    pcie_non_working.TXT is for non-working condition.

    5305.pcie_non_working.TXT

    4) Which PSP release are you using?

    linux-2.6.37-psp04.00.00.10.tar.gz which is given in the sdk ti-ezsdk_dm816x-evm_5_01_01_80

     

  • 0 in reply to Roshan Dsouza
    TI__Expert 5685 points

    Hello,

    I will probably require more time to analyze in detail but as quick comments I can suggest following:

    1) Can you try independently powering up FPGA board and make sure it is ON before 816x device starts (of course the reset driver from 816x has to be disconnected.

    2) AND/OR get similar state transition data from FPGA side?

    From the logs I do not see the LTSSM getting in to compliance state - it seems going from Detect to poll to detect mostly. Have you tried any other off the shelf PCIe card (e.g., the one mentioned in Root Complex driver user guide? Or try with another 816x EVM?

    If nothing works, can you also provide dump of DEBUG1 register too (@5100172c)?

     

    Thanks.

       Hemant

  • 0 in reply to HemantPedanekar
    Intellectual 430 points
    Hi Hemanth,
    Observations:
    1. processor resetout is connected to reset input to fpga.
    2. fpga ltssm moves to detect.active 719ms after processor resetout is de-asserted.
    3. pci local reset (PCI_LRST field of RM_DEFAULT_RSTCTRL Register) in processor is release 19.5s after processor resetout is de-asserted. After this processor ltssm is enabled.
    4. we have done a wiring on the board to isolate processor resetout from fpga. instead we are connected processor gpio as reset to fpga.
    5. along with this hardware change we have done a software change so that reset to fpga is de-asserted at the same time when pci local reset in processor is released.
    6. with the above change we observe that pcie link training is consistently working.
     
    questions
    1. how does pci local reset in processor effect pcie link training
    2. when exactly pci local reset need to be released
     
    Best regards,
    Roshan Dsouza
  • 0 in reply to Roshan Dsouza
    TI__Expert 5685 points

    Roshan,

    Roshan Dsouza said:
    5. along with this hardware change we have done a software change so that reset to fpga is de-asserted at the same time when pci local reset in processor is released.

     

    Can you confirm if you alter this sequence either as reset processor first or reset FPGA first, things don't work?

    Roshan Dsouza said:
    questions
    1. how does pci local reset in processor effect pcie link training
    2. when exactly pci local reset need to be released
     

    Local reset does not directly initiate re-training, you need to explicitly do so. In your case, can you check without doing local reset on processor side - that is, let the Root Complex driver run normally during boot (you may need to ensure that the GPIO is set up to take FPGA out of reset before this depending upon the observation you have with my question above).
       Hemant