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.
Hi Tobias, can you try this with mainline Linux. Also make sure the pcie power enable and reset pins are
defined properly in the dts file.
Hope this helps
Thank you very much for your quick response!
However, I don't have a dts file. Kontron didn't supply any device tree, just a rather big bunch of patches against the 3.0.101 kernel to make it run on the SMARC. Therefore I can't easily compile a mainline kernel for my system. Or do you think that it should be possible to boot a kernel with the dts of another mx6 board, to get it at least to the step where it detects PCIe devices?
it's a Kontron aSMX6i Quadcore and Singlecore (I have both modules here and both show the same behaviour). I got it running with mainline kernel using a sabresd device tree file. However, the problem with my intel wireless card is still the same.
Now I tried an Atheros card which gets detected immediately but doesn't work either. It shows a very strange behaviour with timeouts and repetitions during authentication and/or association and never gets a connection to an AP. On a x86 Linux box also this device runs flawlessly.
Yes, Sinan's suggestion is a good one.
There are two recent patches (haven't made into mainline yet) that improves the mx6 pci driver detection capability:
You can also run mainline U-boot and activate the PCI driver there to see if U-boot detects your PCI card.
Also, I tested it with am Intel PCI 7260HMW card and it is detected 100% of the times if I use mainline U-boot and also in a mainline kernel with the 2 patches that I mentioned before applied.
ok, I applied the two patches, unfortunately without any effect:
i2c i2c-2: IMX I2C adapter registered
Switched to clocksource mxc_timer1
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: bus0: Fast back to back transfers disabled
PCI: bus1: Fast back to back transfers enabled
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]
I tried it with mainline 3.16.2 and the mx6q-sabresd device tree. Of course it produces a massive load of errors, however PCIe seems to work with the PCIe card that also works with our 3.0.101 kernel. The Intel 7260 still doesn't work. I will now try to apply the two patches you mentioned earlier...
Using the imx6q-sabresd.dtb doesn't look like a good aproach. This dtb is for mx6q and you use a mx6solo. The PCI reset and power up would also be adapted to your board.
Are you able to try PCI detection in U-boot first?
I was looking for pci power enable and reset lines on my board and found out that the pci reset line is NOT connected to the imx6 SoC. It is connected to a CPLD on the SMARC module. Of course this CPLD has no clue about things going on in the driver and therefore a reset will never arrive at the device. Is there any way to find out if this might cause my problems with the Intel 7260 module?
Bill you would most likely need both reset and power enable working on your board. Can you hook up a scope there on those pins and see what's going on
during the probe. If you don't have power and/or reset it not being toggled, you won't detect the card. Perhaps you can check this.
Well, the strange thing is that other cards do work, more or less: an old intel wireless 6300 works and an ath9k device is detected. It doesn't work though, but I think that this is another story.
So, I think the power line should be ok. But I have profound doubts regarding the reset line. From the schematics of the SMARC module I can tell that it is connected to a CPLD on the SMARC module and not to the SoC. So I think it can't be toggled by the kernel. Tomorrow I will try to route one of the GPIO lines to the PCIe reset line, hopefully this will bring up some results!
Does the manufacture give you the CPLD code ? I would think the reset toggling is sw controllable via cpld regs.
GPIO route to reset sounds like a good idea, hope it works.
I would just make sure the reset is toggled at the right moment in accordance with pwr_en. Perhaps you can measure both. But more
importantly you can perhaps identify who is toggling the reset line. Even it is coming out of cpld someone must be asking cpld
to toggle it at a certain moment. I don't think cpld would just toggle it as part of init. If you identify what pins eventually
causes cpld to toggle reset line, you can then add those pins to u-boot (there is already a weak definition for reset and power)
or for kernel in your device tree. I would use mainline u-boot and kernel as I know that support is there now and
also Fabio is confirming this. Please try to see if both power and reset are toggled correctly with right timing (you
can compare what you see to another board, say sabresd) and find out how you can control cpld to toggle reset.
Hope this helps.
the kernel has control over the reset line via a GPIO pin. I made a modification to the kernel (toggling the line 3 times) and could clearly measure these results. Unfortunately I don't have other boards, only the Kontron SMARC.
Hi Bill, if you have now control over reset and power enable pins directly from kernel, latest mainline should have the support
and you should see you pcie card. Latest mainline u-boot also has support for pcie and you can try that as well. Meanwhile I will see if
I can have access to Kontron board here to test it out for you.
that would be really helpful because I didn't see the device with kernel 3.16.2. :smileysad:
I have used the DTS file for sabresd and modified it to use GPIO 3,13 as pcie reset line (which was verified to work by measuring with a scope). In the meantime I will try to get a mainline uboot with pcie support running on my board.
Thank you very much for your help!
Hi Bill, it is perhaps easier for me to focus on the pcie card you have. Kontron cards are not easily available here in Canada.
You had said that you tried other cards (ath9k) and you had no problem so perhaps it is better to focus on your PCIe card.
Fabio already reported that he had no problem with that card but I'll see if I can find one and test.
Fabio, not sure if you are still monitoring this but if you do, can you please let me know on which board you tested this
out. I think you have sabresd, also let me know what board version you have. I'll try to reproduce the PCIe issue
with this card hopefully on another board.