Hello,
I am trying to run an i.MX powered SMARC module (Kontron sAMX6i SMARC and corresponding evaluation board) with the Intel 7260 WLAN NIC which is connected via PCIe.
I am using Linux 3.0.101 on the SoC and the PCIe connection can be established when other PCIe devices are connected. The 7260 however is not recognized by the kernel, lspci doesn't yield any output at all.
The system log however shows some information regarding PCIe when the 7260 module is plugged in:
[ | 0.354277] iMX6 PCIe PCIe RC mode imx_pcie_pltfm_probe entering. |
[ | 0.464199] PCIE: imx_pcie_pltfm_probe start link up. |
[ | 1.067762] link up failed, DB_R0:0x004a4a02, DB_R1:0x08000000! |
[ | 1.067774] IMX PCIe port: link down! |
without any module in the PCIe slot the output is:
[ | 0.404498] iMX6 PCIe PCIe RC mode imx_pcie_pltfm_probe entering. |
[ | 0.514218] PCIE: imx_pcie_pltfm_probe start link up. |
[ | 1.119397] link up failed, DB_R0:0x00948200, DB_R1:0x08200000! |
[ | 1.119409] IMX PCIe port: link down! |
Following the advice found in some post here I forced PCIe GEN1 and the output changed but the module didn't work neither:
[ | 0.919414] iMX6 PCIe PCIe RC mode imx_pcie_pltfm_probe entering. |
[ | 1.048486] PCIE: imx_pcie_pltfm_probe start link up. |
[ | 1.658725] link up failed, DB_R0:0xa0f7bcc2, DB_R1:0x08005300! |
[ | 1.664689] IMX PCIe port: link down! |
Can anyone tell me where to find an explanation of the bits in the DB_R0/1 registers and why this device does not work with the iMX6 SoC? A normal x86 Linux box has no problems to detect the WLAN NIC so I think the NIC itself should be ok.
Thanks Fabio, sounds good. I have two C2 boards, I will see if I can grab the PCIe card in a local store and try to see what might be
causing the issue.
Regards
Sinan Akman
My card part model number is: 7260HMW BN.
This is the log from U-boot and the kernel:
U-Boot 2014.10-rc2-16937-gc860eed (Sep 11 2014 - 10:57:58)
CPU: Freescale i.MX6Q rev1.2 at 792 MHz
Reset cause: POR
Board: MX6-SabreSD
I2C: ready
DRAM: 1 GiB
MMC: FSL_SDHC: 0, FSL_SDHC: 1, FSL_SDHC: 2
00:01.0 - 16c3:abcd - Bridge device
01:00.0 - 8086:08b1 - Network controller
.....
root@freescale /$ dmesg | grep pci
[ 0.369525] imx6q-pcie 1ffc000.pcie: PCI host bridge to bus 0000:00
[ 0.369546] pci_bus 0000:00: root bus resource [io 0x1000-0x10000]
[ 0.369564] pci_bus 0000:00: root bus resource [mem 0x01000000-0x01efffff]
[ 0.369582] pci_bus 0000:00: root bus resource [bus 00-ff]
[ 0.369686] pci 0000:00:00.0: [16c3:abcd] type 01 class 0x060400
[ 0.369734] pci 0000:00:00.0: reg 0x10: [mem 0x00000000-0x000fffff]
[ 0.369772] pci 0000:00:00.0: reg 0x38: [mem 0x00000000-0x0000ffff pref]
[ 0.369952] pci 0000:00:00.0: supports D1
[ 0.369968] pci 0000:00:00.0: PME# supported from D0 D1 D3hot D3cold
[ 0.371199] pci 0000:01:00.0: [8086:08b1] type 00 class 0x028000
[ 0.371337] pci 0000:01:00.0: reg 0x10: [mem 0x00000000-0x00001fff 64bit]
[ 0.371842] pci 0000:01:00.0: PME# supported from D0 D3hot D3cold
[ 0.385577] pci_bus 0000:01: busn_res: [bus 01-ff] end is updated to 01
[ 0.385746] pci 0000:00:00.0: BAR 0: assigned [mem 0x01000000-0x010fffff]
[ 0.385774] pci 0000:00:00.0: BAR 8: assigned [mem 0x01100000-0x011fffff]
[ 0.385796] pci 0000:00:00.0: BAR 6: assigned [mem 0x01200000-0x0120ffff pref]
[ 0.385820] pci 0000:01:00.0: BAR 0: assigned [mem 0x01100000-0x01101fff 64bit]
[ 0.385895] pci 0000:00:00.0: PCI bridge to [bus 01]
[ 0.385919] pci 0000:00:00.0: bridge window [mem 0x01100000-0x011fffff]
[ 0.386525] pcieport 0000:00:00.0: Signaling PME through PCIe PME interrupt
[ 0.386544] pci 0000:01:00.0: Signaling PME through PCIe PME interrupt
[ 0.386565] pcie_pme 0000:00:00.0:pcie01: service driver pcie_pme loaded
root@freescale /$ uname -r
3.17.0-rc5-next-20140919
Hello Fabio,
I tried with kernel 3.16.2 to which I applied the two patches that you mentioned earlier. Do you know if there are any other relevant patches to PCIe in 3.17.0? My network card is the same, Intel 7260HWB. On monday when I return in office I will check the exact revision of the card and post it here.
We have seen lots of activity lately in the PCI area. Please give linux-next tree a try so that we make sure we have all the recent patches that have not made into mainline yet.
BTW, linux-next 20140919 is broken today and you would need this patch so it can build:
Hello Fabio,
this is the output with 3.17.0-rc6:
Switched to clocksource mxc_timer1
imx6q-pcie 1ffc000.pcie: missing *config* reg space
imx6q-pcie 1ffc000.pcie: phy link never came up
imx6q-pcie 1ffc000.pcie: PCI host bridge to bus 0000:00
pci_bus 0000:00: root bus resource [io 0x1000-0x10000]
pci_bus 0000:00: root bus resource [mem 0x01000000-0x01efffff]
pci_bus 0000:00: No busn resource found for root bus, will use [bus 00-ff]
pci 0000:00:00.0: [16c3:abcd] type 01 class 0x060400
pci 0000:00:00.0: reg 0x10: [mem 0x00000000-0x000fffff]
pci 0000:00:00.0: reg 0x38: [mem 0x00000000-0x0000ffff pref]
pci 0000:00:00.0: supports D1
pci 0000:00:00.0: PME# supported from D0 D1 D3hot D3cold
PCI: bus0: Fast back to back transfers disabled
PCI: bus1: Fast back to back transfers enabled
pci_bus 0000:01: busn_res: [bus 01-ff] end is updated to 01
pci_bus 0000:00: busn_res: [bus 00-ff] end is updated to 01
pci 0000:00:00.0: BAR 0: assigned [mem 0x01000000-0x010fffff]
pci 0000:00:00.0: BAR 6: assigned [mem 0x01100000-0x0110ffff pref]
pci 0000:00:00.0: PCI bridge to [bus 01]
pci 0000:00:00.0: PCI bridge to [bus 01]
pci_bus 0000:00: resource 4 [io 0x1000-0x10000]
pci_bus 0000:00: resource 5 [mem 0x01000000-0x01efffff]
3.17-rc6 still does not have the following two commits:
Hello Fabio,
I applied the first patch, the second one seems to be already included. I recompiled the kernel and tested it, nothing has changed. :-(
dmesg | grep pci
imx6q-pcie 1ffc000.pcie: missing *config* reg space
imx6q-pcie 1ffc000.pcie: phy link never came up
imx6q-pcie 1ffc000.pcie: PCI host bridge to bus 0000:00
pci_bus 0000:00: root bus resource [io 0x1000-0x10000]
pci_bus 0000:00: root bus resource [mem 0x01000000-0x01efffff]
pci_bus 0000:00: No busn resource found for root bus, will use [bus 00-ff]
pci 0000:00:00.0: [16c3:abcd] type 01 class 0x060400
pci 0000:00:00.0: reg 0x10: [mem 0x00000000-0x000fffff]
pci 0000:00:00.0: reg 0x38: [mem 0x00000000-0x0000ffff pref]
pci 0000:00:00.0: supports D1
pci 0000:00:00.0: PME# supported from D0 D1 D3hot D3cold
pci_bus 0000:01: busn_res: [bus 01-ff] end is updated to 01
pci_bus 0000:00: busn_res: [bus 00-ff] end is updated to 01
pci 0000:00:00.0: BAR 0: assigned [mem 0x01000000-0x010fffff]
pci 0000:00:00.0: BAR 6: assigned [mem 0x01100000-0x0110ffff pref]
pci 0000:00:00.0: PCI bridge to [bus 01]
pci 0000:00:00.0: PCI bridge to [bus 01]
pci_bus 0000:00: resource 4 [io 0x1000-0x10000]
pci_bus 0000:00: resource 5 [mem 0x01000000-0x01efffff]
Are you able to toggle the PCI reset lines from the kernel now?
Could Kontron help with this issue?
Yes, the kernel does trigger the reset line (I verified it with a scope)
And no, still no response from Kontron...
Hi Bill, do you have access to a sabresd board, this way we would be all on the
same page for testing.
Also, is there any chance your card is broken. Does that card work on any
other board ?
Perhaps you mentioned all these already, I browsed the previous comments
but I might have missed it.
I can't get a Kontron board here, if you know of any source in North America
where I can purchase let me know.
Please let us know if you can have access to sabresd and/or confirm your card
does work fine on other boards.
Regards
Sinan Akman
Hello,
we finally resolved this issue, in the end it was a problem with pcie clock signal that was very unclean, likely due to unproper termination. Kontron is still analysing this issue and we are waiting for a final solution.
Hi Bill, thanks for the update. Was this an issue only on your own board or general issue on that particular Kontron model.
You could then perhaps update with what Kontron comes up with for other Kontron users who might check here for
similar issues.
Regards
Sinan Akman
It seems to be a general issue since Kontron promised us to change the SMARC modul
Hi Sinan,
the card works flawlessly in an x86 notebook, so I think it isn't broken.
I don't have a sabresd board here, but I think Fabio already tested on a sabresd and the card worked.
I use a mainline/vanilla kernel, so we should have the same software base, the only difference is the hardware in my case.
No, I don't have any information about the Programming of this CPLD. Today we will attach a scope and/or route the GPIO to the reset line.
I also asked the manufacture more information about the connection between reset line and SoC. In the source code of the patched old Kernel (3.0.101) I found a GPIO pin which is used for toggling the reset signal, but I don't know if it is connected to the reset line or the CPLD.
Well, after measuring and routing I hope to know more about this issue!
I could not try PCI detection in uboot because Kontron provided only an uboot binary which was build without PCIe support :smileysad:
In the meantime I tried a quadcore which showed exactly the same behaviour