Question, PCIe on i.MX7D SABRE cannot work

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

Question, PCIe on i.MX7D SABRE cannot work

3,402 Views
Aemj
Contributor IV

Dear team,

Though some similar posts are seen in this community, I would like to ask about the PCIe issue mentioned in below.
My customer is working on the issue that PCIe port cannot come up on your i.MX7D SABRE board(Rev.D).

The environment is as below;

[board]

MCIMX7SABRE Rev.D

 

[BSP]

krogoth_4.1.15-2.0.1

 

[build option]

MACHINE=imx7dsabresd

DISTRO=fsl-imx-fb

 

[build target]

core-image-base

 

[kernel configuration]

Bus support  --->

[*] PCI support

[*] Message Signaled  Interrupts (MSI and MSI-X)

     PCI host controller drivers  --->

      [*] Freescale i.MX6 PCIe controller

-*- PCI Express Port Bus support

[*]   Root Port Advanced Error Reporting support

[*]   PCI Express ASPM control

 

[device tree]

default(imx7d-sdb.dtb)

 

[pci driver]

default(all pci driver)

 

And the below is the log of LinuxBSP boot-up;

 ----------------------------

33800000.pcie supply pcie-bus not found, using dummy regulator

imx6q-pcie 33800000.pcie: phy link never came up

imx6q-pcie 33800000.pcie: failed to initialize host

imx6q-pcie: probe of 33800000.pcie failed with error -22

 ---------------------------

Could you show me how they can do to make PCIe work?

Thanks,

Miyamoto

Labels (1)
0 Kudos
9 Replies

1,874 Views
Yuri
NXP Employee
NXP Employee

Hello,

 According to “Known issues and workarounds for i.MX 7Dual SABRE-SD” of

“i.MX_Linux_Release_Notes.pdf” :

 

PCIe Hardware Cannot probe up PCIe devices on Rev. C board.
Hardware rework is required. Rework: Change C459&C458 caps to 0 ohm resistors.

 

The same is correct for the rev. D.

 

Regards,

Yuri.

------------------------------------------------------------------------------

Note: If this post answers your question, please click the Correct Answer

button. Thank you!

0 Kudos

1,874 Views
Aemj
Contributor IV

Hello Yuri,

Thanks for your support.

The customer checked the rework of C459&C458 of the i.MX7 SABRE board.

And they found there are no C459&C458 on the board, and they found R644,R645 instead of that.

And they found the revision number printed on the board is D1.

Actually, they obtained the SABRE board recently.

It seems that the schema is not corresponding to the board.

For the D1 board, was the PCIe operation tested?

Thanks,

Miyamoto

0 Kudos

1,874 Views
bernhardfink
NXP Employee
NXP Employee

My 2 cents with regards to PCIe on the i.MX7 board:

  • very minor changes between Rev C and Rev D boards, so for this topic both board revision can be treated the same way
  • the rework "C459&C458 on the board, and R644,R645 instead" is OK, the external PCI clock is used
  • at the time the board was built it wasn't clear whether the internal ref clock is good enough for PCIe certification, so the default configuration uses the external PCIe clock device, on all board revisions
  • in fact the internal PCIe ref clock in the i.MX7 is good enough to pass the certification. However, an external clock is for sure more accurate and provides therefore more margin.
  • the board could be reworked in such a way that the internal clock is used
  • I have the PCIe interface on my Rev C board running with WLAN cards. This requires modifications in the Kernel and in the meta layer structure of Yocto:

    imx6q-pcie 33800000.pcie: PCI host bridge to bus 0000:00
    pci_bus 0000:00: root bus resource [io 0x1000-0xffff]
    pci_bus 0000:00: root bus resource [mem 0x40000000-0x4fefffff]
    pci_bus 0000:00: root bus resource [bus 00-ff]
    PCI: bus0: Fast back to back transfers disabled
    PCI: bus1: Fast back to back transfers disabled
    pci 0000:00:00.0: BAR 0: assigned [mem 0x40000000-0x400fffff]
    pci 0000:00:00.0: BAR 8: assigned [mem 0x40100000-0x401fffff]
    pci 0000:00:00.0: BAR 6: assigned [mem 0x40200000-0x4020ffff pref]
    pci 0000:01:00.0: BAR 0: assigned [mem 0x40100000-0x4010ffff 64bit]
    pci 0000:00:00.0: PCI bridge to [bus 01]
    pci 0000:00:00.0: bridge window [mem 0x40100000-0x401fffff]
    pcieport 0000:00:00.0: Signaling PME through PCIe PME interrupt
    pci 0000:01:00.0: Signaling PME through PCIe PME interrupt
    ath9k 0000:01:00.0: enabling device (0140 -> 0142)
    ieee80211 phy0: Atheros AR9287 Rev:2 mem=0xc09e0000, irq=305

  • if you need a helping hand for that, don't hesitate to contact me.

Regards,

Bernhard.

0 Kudos

1,874 Views
anil_sasidharan
Contributor I

Hi Bernhard Fink,

 

We are trying to get a WiFi module working with PCIe interface on Embedded Artists i.MX7 Dual COM board for one of the ongoing projects. At present we are checking kernel version 4.1.15 (based on NXP's sources).

For some strange reason, PCIe legacy interrupts are not working. Have you experienced similar issues with i.MX7 platforms? If yes, how to fix it?

As an additional experiment, PCI-MSI interrupts are enabled in the same kernel and tested, but the interrupts still not working. Really appreciate any help on this.

 

Warm Regards,

Anil

0 Kudos

1,874 Views
bernhardfink
NXP Employee
NXP Employee

Hi Anil,

so you pass the PCIe init (the WiFi module is detected), but the interrupts are not working?

You use the BSP from Embedded Artists?

I have seen threads with regards to this, I need to dig a little bit into it.

Regards,

Bernhard.

0 Kudos

1,874 Views
anil_sasidharan
Contributor I

Hi Bernhard,

Thanks for your reply. 

Yes, WiFi module is getting detected, however PCIe interrupts (both MSI and Legacy) are not working.

We use the BSP from Embedded Artists. We tried with kernel 4.1.15.

What could be the possible reasons for lack of interrupts? Any specific kernel config or source change required?


Warm Regards,

Anil

0 Kudos

1,874 Views
jacobpostman
Contributor II

Hi bernhardfink,

In your post from February, you mention that the imx7d sabre board can be reworked so that the internal reference clock is used rather than the external pcie clock generator (U42, PI6CFGL201BZDIEX or 9FGV0241).

1. What rework is needed to use the internal reference clock?

2. Are there any changes required to the kernel or dts?

Thank you,

Jacob

0 Kudos

1,874 Views
SLICE
Contributor IV

Hi Bernhard,

Thanks a lot for your detailed info!

I will share with the customer.

Thanks,

Miyamoto

0 Kudos

1,874 Views
Yuri
NXP Employee
NXP Employee

Hello,

  You may try using the D1 release, but strictly speaking,   from Table 11 (PCIE recommendations)

of "Hardware Development Guide for i.MX7Dual " :

"i.MX differential clock is not compliance with PCIe standard. NXP recommends including an external

clock source that meets the PCIe jitter specification untils the i.MX 7DS PCIe jitter compliance can be

assessed."

 

http://www.nxp.com/assets/documents/data/en/user-guides/IMX7DSHDG.pdf

Regards,

Yuri.

0 Kudos