• State Resolved
  • Locked Locked
  • Replies 4 replies
  • Subscribers 32 subscribers
  • Views 1280 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.

XIO2213BZAY CONNECTION PROBLEM

WhiteHorse
Genius 4430 points

E2e,

 We have a customer using the XIO2213.  Their system has a iMX6 CPU, PCIe MUX (CBTL02043A) and the XIO2213.  The iMX6 PCIe connects to the XIO2213 through the CBTL02043A. They are experiencing a problem were the  XIO2213 does not always connect to their iMX6.  Can you recommend where to start looking for the problem.   I have a copy of the schematic, but need a way to get it do you privately.

Thanks for your help.

Regards,

WH

  • 0
    TI__Guru* 76130 points
    Hello,
    Does the connection problem happens at power-up?
    I would start looking at the REFCLK and PERST# at power-up.
    You can send me a private message through this E2E forum and you can also share your schematics there.
    Regards
  • 0 in reply to Elias Villegas M.
    Genius 4430 points
    Hi Elias,

    They have verified that after power-up, the reset PREST# is asserted until after the REF_CLK is up and stable.

    They tried installing a newer linux kernel (with greatly modified PCIe drivers)... With the new kernel/driver they are seeing link on most of the failing boards, however, for some reason, the OHCI driver is unable to read the boards registers.. Sometimes failing to set/verify the LPS bit in the Host Controller Control Register... (the driver reads it back to ensure that the LPS bit is set).

    Other times the OCHI driver successfully sets the LPS register, but then fails to read the from the Phy Control Register (0xEC)... in this case it is setting the the regAddr to 2, and waiting for rdDone before reading the value back. This times out after 1 second and fails the command. If I add a command to check the regAddr during this process, it does not return 2.

    This leads the customer to believe this is most likely a driver issue unless the new PCIe driver is linking and then losing link, they are not seeing any notifications in linux that the PCIe link is dropping out.

    If the problem is in the driver, it is most likely in the timing of the commands.
    After the driver sets the LPS bit, there is a 50ms sleep before it attempts to read it back... If this succeeds, the Phy Control Register read would follow a few commands later.

    The Linux kernel that fails to link to the PCIe is a Freescale branch of 3.10.17.
    The new Linux kernel that links on the PCIe is a Freescalse branch of 3.14.28.

    They have also tried back-porting the firewire driver from 3.10.17 to 3.14.28, but without success (they get the same failures)

    Note that on the boards that do not fail using 3.10.17, they are not having any trouble with the firewire driver or the PCIe, both link up and they are able to read/write to firewire hard drives without any problems.

    Is there any assistance TI can provide at the driver level?

    Thanks for your help.

    Regards,
    WH
  • 0 in reply to WhiteHorse
    TI__Guru* 76130 points
    Hello,
    Sorry, we don't have support for linux drivers.
    rEgards