Initialization of PCIe root bridge on iMX7 dual may fail in Yocto 2.1

[kvv]

1. Brief description of our system (please tell if additional details are needed):

• customized board based on i.MX7 dual SoC
• Pericom PI7C9X2G404SL switch is connected to iMX7 via PCIe bus
• 4.1.29 kernel(from official NXP imx-4.1-krogoth Yocto branch) customized for our board

2. Description of the problem:

Synopsys PCIe root bridge gets 0 when it tries to read its classcode with PCI_CLASS_REVISION command during initialization. This happens in 50 % of cases. In other 50% of cases it's read correctly - we obtain "6040001". Moreover vendor and product IDs are always (100% of cases) reported/read properly as "16c3:abcd", plus other values/registers are also read normally.

We tried to work around the problem by:

• re-reading the Synopsis classcode two and more times;
• flushing caches;
• playing with delays during initialization;

but nothing has helped - the classcode remains 0 if the first reading of the register returned a zero value.

We managed to "solve" the problem by substituting the zero classcode with proper value during the initialization routine. With this hack, the Synopsys root brigde is initialized properly and a Pericom PCIe switch connected to the root bridge works well too.

3. Speculations and open questions:

At the moment we can't tell:

• whether the problem can be reproduced on reference NXP system with reference Yocto BSP;
• whether the problem can be reproduced with latest NXP kernel/BSP;
• whether it can be reproduced on our system when the Pericom PCIe switch is disconnected from the root bridge.

We will provide an update if we will manage to perform such experiments.

As a brief search for similar problems on Internet gave no results, we speculate that the problem is specific to our particular customized system, but we can't find a root cause. So any input will be greatly appreciated.

Best regards,
Viktor Krasnov.

[igorpadykov]

Hi Viktor

please try official nxp bsps described on

http://www.nxp.com/products/software-and-tools/software-development-tools/i.mx-software-and-tools/i....

4.1.29 kernel is not supported by nxp, for adding support of Pericom switches one can consider

NXP Professional Services:

http://www.nxp.com/support/nxp-professional-services:PROFESSIONAL-SERVICE

Best regards
igor
-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------

[kvv]

Hello Igor,

thanks for the feedback!

1)

please try official nxp bsps described on

I believe that we already use an official NXP BSP - an imx_4.1.15_1.0.0_ga branch from git://git.freescale.com/imx/fsl-arm-yocto-bsp.git. It may be a bit outdated but we can't switch to "imx-morty" as porting of existing code for our customized board will require a lot of time and additional testing.

2)

4.1.29 kernel is not supported by nxp,

Thanks for pointing this out. I've just discovered that our kernel is based on "linux-fslc" (FSL community BSP) and not on "linux-imx" (official Freescale repo). This is a bummer :smileysad:

I hope that relatively small efforts will be needed to switch to the official kernel. I will keep you informed when we will perform such experiment (now I'm very skeptical that the problem will magically disappear on official kernel).

3)

for adding support of Pericom switches one can consider NXP Professional Services

The Pericom switch works relatively well - this particular problem is related to the PCIe root bridge on iMX7 itself.

Best regards,
Viktor Krasnov.

[igorpadykov]

Hi Viktor 

also may be useful to look at

difference between Yocto Community BSP and Freescale BSP Release 

Best regards
igor

[kvv]

Hi Igor,

today we tried the official "linux-imx" kernel and were not able to reproduce the problem on it. Sometimes miracles do happen indeed.

After comparison with "linux-fslc" kernel, we discovered that the problem is not caused by the type of kernel, but is caused by our PCIe patches which add support of Pericom switch. We still can't find a root cause or explain the behavior, but we are sure that zeroes are read from registers of Synopsis root bridge during its initialization _only_when_ downstream PCIe ports on the Pericom switch are already enabled/activated (i.e. PRSNT signals on switch are asserted).

As the problem can be worked around both on "official" and "community" kernels (we will need to call a routine, which is in charge of assertion of PRSNT signals, only after the root bridge is initialized) this topic/question can be marked as resolved/closed.

Thanks again for your assistance!

Best regards,
Viktor Krasnov.

[kvv]

Hi Igor,

> also may be useful to look at difference between Yocto Community BSP and Freescale BSP Release

Thanks for the link, it will be very useful to make a decision which kernel to use as a basement for further development.

At the moment we are working on bring-up of the official "linux-imx" kernel on our board. I will update this issue as soon as we get first results.

Best regards,
Viktor Krasnov.