Hi,
a customer of mine has designed a new processor board which is based on a Keystone II device, namely the AM5K2E04. Currently we’re in the bring-up phase of the project, i.e. we’re trying to get all relevant hardware units up and running. Unfortunately, we ran into problems when enabling the PCI Express controllers of the Keystone processor.
Our board acts as a PCIe root complex and uses both PCIe interfaces of the Keystone. PCIe #0 is connected to an FPGA, PCIe#1 is connected to a PCIe switch. Both interfaces use 2 lanes PCIe Gen 2. Our problem is that neither of the PCIe interfaces of the Keystone is able to establish a stable physical connection to its communication partner.
To look into this, we’ve modified the bootloader (UBoot) so that it continuously monitors the state of the PCIe controllers.
The bootloader does the following:
- It switches both controller into root complex mode
- It initializes the SerDes with the settings provided by TI
- It enables the PCIe power domains
- It triggers PCIe link training
After that, the bootloader enters an endless loop where it continuously reads and outputs a number of PCIe debug registers, most importantly the physical link state (LTSSM) In this loop we can see that the link training takes very, very long (seconds!). And even if the link comes up, it usually breaks down after some time (sometimes seconds, sometimes minutes). All this pretty much non-deterministically.
Because of that, we guess that there’s probably a hardware problem. But how can we proceed to diagnose this?
So our questions are:
- Do you have any advice on how to tackle problems related to PCIe link training / physical layer problems?
- Is there anything to consider when initializing the SerDes PHYs?
The SerDes spec (spruho3a.pdf) states that the customer should *never* use any settings other than those provided by TI. Are there any known use cases where customers needed special PHY settings?
Thanks
