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.

Linux/AM5726: PCIe bridge issue

Part Number: AM5726
Other Parts Discussed in Thread: XIO2001

Tool/software: Linux

Hi All,

We are developing our custom board with AM5726 sitara processor. Our product is intended to work as a network camera as well as WiFi access point. 

Our WiFi card is mini-pci compatible and connected to AM572x processor on PCI-e interface. We have XIO bridge in between this 2, to convert from PCI-mini to PIC-e and vice a versa. 

While development, we have run into an issue. The issue is, we have to disable "Message Signaled Interrupts (MSI and MSI-X)" option from linux- Kernel, to make WiFi working.

Prompt: Message Signaled Interrupts (MSI and MSI-X) x
x Location: x
x -> Bus support

If we keep this option enable, then we are not able to see any interrupt entry for our WiFi card in /proc/interrupts

And if we disable this option, PCI interface works good, but we can not see any "/dev/video*" node entry, being generated on board. To create video node entry, we have to keep "Message Signaled Interrupts", option enabled.  This entry is equally essential for us, as we are interfacing imager on video parallel port of AM5726 and capturing live data.

So,here the question is, how can we run both of our use cases, with single kernel configuration?

Kindly help us on this issue.

Thanks,

Krinali Shah

  • The software team have been notified. They will respond here.
  • Hi, Krinali,

    Please indicate the release version of ProcSDK you are using. If you are not using ProcSDK release 3.2, please upgrade to 3.2. I believe in 3.1 release, legacy interrupts and MSI don't co-exist. I have a XIO2001 connected to my AM572x IDK with a PCI Ethernet card plugged into the XIO bridge. I see the device and its interrupt.

    root@am57xx-evm:~# ifconfig
    enp2s2 Link encap:Ethernet HWaddr 1C:7E:E5:23:EB:B7
    inet addr:192.168.10.100 Bcast:192.168.10.255 Mask:255.255.255.0
    inet6 addr: fe80::1e7e:e5ff:fe23:ebb7%131536/64 Scope:Link
    UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
    RX packets:0 errors:0 dropped:0 overruns:0 frame:0
    TX packets:35 errors:0 dropped:0 overruns:0 carrier:0
    collisions:0 txqueuelen:1000
    RX bytes:0 (0.0 B) TX bytes:5622 (5.4 KiB)

    eth0 Link encap:Ethernet HWaddr 16:75:8A:A2:D2:CC
    UP BROADCAST MULTICAST MTU:1500 Metric:1
    RX packets:0 errors:0 dropped:0 overruns:0 frame:0
    TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
    collisions:0 txqueuelen:1000
    RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)

    root@am57xx-evm:~# cat /proc/interrupts
    CPU0 CPU1
    16: 0 0 CBAR 32 Level gp_timer
    17: 0 0 GIC 29 Edge arch_timer
    18: 12508 3961 GIC 30 Edge arch_timer
    22: 0 0 CBAR 4 Level l3-dbg-irq
    23: 0 0 WUGEN 10 Level l3-app-irq
    25: 8 0 CBAR 232 Level dra7xx-pcie-main
    26: 38 0 CBAR 233 Level dra7-pcie-msi

    434: 0 0 PCI-MSI 0 Edge PCIe PME, aerdrv
    467: 38 0 dummy 3 Edge enp2s2
    468: 0 0 pinctrl 584 Edge 48020000.serial
  • Hi Chang,

    We are using ti-processor-sdk-linux-am57xx-evm-03.00.00.04
    I can see the interrupts if I disable "CONFIG_MSI" option from kernel, as I have explained in my original post. But, if I enable this option, I can not see my WiFi card routed through any interrupt pin.
    What configurations do you use?

    Thanks,
    Krinali Shah
  • Hi, Krinali,

    Release 3.0.0.4 is definitely too old, and Legacy Interrupts don't co-exist with MSI. Please upgrade to at least 3.2.0.5 which fixed the coexistence issue. I use default configuration which has the following:

    CONFIG_PCI_MSI=y

    Rex
  • Hi Rex,

    Thanks for your quick help.
    Is there any other option then upgrading a kernel?
    Because, we are using third party WiFi card, and they have built their driver with linux-4.4.12.
    If we move to higher version of linux kernel, I believe they also have to re-port their entire driver on new kernel.
    With existing linux-kernel-4.4.12, can I accommodate this co-existence changes?

    Thanks,
    Krinali Shah
  • Hi, Krinali,

    ProcSDK 3.2 is Kernel 4.4.41. They should be compatible.

    Rex