OpenWrt/LEDE Project

  • Status Unconfirmed
  • Percent Complete
    0%
  • Task Type Bug Report
  • Category Base system
  • Assigned To No-one
  • Operating System All
  • Severity Low
  • Priority Very Low
  • Reported Version Trunk
  • Due in Version Undecided
  • Due Date Undecided
  • Private
Attached to Project: OpenWrt/LEDE Project
Opened by Aleksey Tregubov - 12.10.2020

FS#3381 - Trunk don't initialize pci cards at mt7621

Trunk does not initialize pci adapter cards properly.

I’m using unielec mt7621 board with kind of Atheros miniPCIe cards? in this test installed AR9287 adapter.

Here is lspci and part of dmesg output from 19.07.4:

root@OpenWrt:~# lspci -v
02:00.0 Network controller: Qualcomm Atheros AR9287 Wireless Network Adapter (PCI-Express) (rev 01)
        Subsystem: Qualcomm Atheros Device 30a4
        Flags: fast devsel, IRQ 255
        Memory at 60200000 (64-bit, non-prefetchable) [disabled] [size=64K]
        Capabilities: [40] Power Management version 3
        Capabilities: [50] MSI: Enable- Count=1/1 Maskable- 64bit-
        Capabilities: [60] Express Legacy Endpoint, MSI 00
        Capabilities: [100] Advanced Error Reporting
        Capabilities: [140] Virtual Channel
        Capabilities: [160] Device Serial Number 00-15-17-ff-ff-24-14-12
        Capabilities: [170] Power Budgeting <?>

[    2.261556] pci 0000:02:00.0: [168c:002e] type 00 class 0x028000
[    2.261628] pci 0000:02:00.0: reg 0x10: [mem 0x00000000-0x0000ffff 64bit]
[    2.261756] pci 0000:02:00.0: supports D1
[    2.261764] pci 0000:02:00.0: PME# supported from D0 D1 D3hot

Here is lspci and part of dmesg output from trunk:

02:00.0 Ethernet controller: Qualcomm Atheros AR5008 Wireless Network Adapter (rev 01)
        Flags: fast devsel, IRQ 255
        Memory at 60200000 (64-bit, non-prefetchable) [disabled] [size=64K]
        Capabilities: [40] Power Management version 3
        Capabilities: [50] MSI: Enable- Count=1/1 Maskable- 64bit-
        Capabilities: [60] Express Legacy Endpoint, MSI 00
        Capabilities: [100] Advanced Error Reporting
        Capabilities: [140] Virtual Channel
        Capabilities: [160] Device Serial Number 00-00-00-00-00-00-00-00
        Capabilities: [170] Power Budgeting <?>

[    1.604742] pci 0000:02:00.0: [168c:ff1c] type 00 class 0x020000
[    1.610801] pci 0000:02:00.0: reg 0x10: [mem 0x00000000-0x0000ffff 64bit]
[    1.617717] pci 0000:02:00.0: supports D1
[    1.621723] pci 0000:02:00.0: PME# supported from D0 D1 D3hot

You may see the the trunk cannot see correct PCI ID and some pci parameters like device serial numbers. Also any wifi modules does not work (mac80211, etc).


Marcin Jurkowski commented on 01.11.2020 15:44

Please post full dmesg output for both 4.14 and 5.4 kernels.

This is probably the same problem as reported in  FS#3093 . I also noticed this on Netgear R6220 but unfortunately it has not magically disappeared...

In my case adding a short 25ms delay in mt7621-pci driver has helped. This is still much shorter than in old 4.14 driver (100ms with one 50ms exception) but seems to solve the issue.

Try applying attached patch and check if that helps.

Aleksey Tregubov commented on 04.11.2020 11:42

Thanks a lot but trunks after October 20 work fine.

Should I compile version before october 20 and put dmesg from it here?

Marcin Jurkowski commented on 04.11.2020 23:19

That would help verify my hypothesis but since your problem is already gone there's no way this could help you :-)

So if you can check this or dig the logs from somewhere I'd be very obliged. Speaking of PCIe device probing, nothing has changed in upstream kernel or OpenWRT patches yet it started working for you. I have two supposedly identical R6220 devices: one worked flawlessly and the other (the same kernel version) would not initialize pcie2 card in ~90% cases.
I strongly suspect there's missing delay in new driver but devices are probed in parallel so actual intervals depend on what features are enabled and what devices are actually connected.

Aleksey Tregubov commented on 06.11.2020 18:34

I found old log from August 24, hope it will help you.

But you should note some interesting thing.

At this moment I cannot reproduce this issue. I tried to run custom built trunk and it runs fine. I did the next:

#git pull https://git.openwrt.org/openwrt/openwrt.git #git checkout 7f5f738466aca2cd8f5daf73f68f4d32b70d43b5
M feeds.conf.default
M target/linux/ramips/dts/mt7621.dtsi
M target/linux/ramips/dts/mt7621_unielec_u7621-06.dtsi
Previous HEAD position was c78e123d5a rtl838x: various fixes
HEAD is now at 7f5f738466 sunxi: Adapt U-Boot config to board rename

At feeds.conf.default I commented out telephony and freifunk, at dtsi – enable i2c and change serial console speed tp 57600 as used in u-boot at my device.

Aleksey Tregubov commented on 23.01.2021 23:07

Hi Martin!

Thanks a lot for idea! After applying this patch my board works very fine!

---
 drivers/staging/mt7621-pci/pci-mt7621.c | 1 +
 1 file changed, 1 insertion(+)


--- a/drivers/staging/mt7621-pci/pci-mt7621.c	2021-01-26 14:36:41.761773605 +0300
+++ b/drivers/staging/mt7621-pci/pci-mt7621.c	2021-01-28 14:23:04.015990292 +0300
@@ -502,6 +502,7 @@
 	int err;
 
 	rt_sysc_m32(PERST_MODE_MASK, PERST_MODE_GPIO, MT7621_GPIO_MODE);
+    mdelay(100);
 
 	mt7621_pcie_reset_assert(pcie);
 	mt7621_pcie_reset_rc_deassert(pcie);

Loading...

Available keyboard shortcuts

Tasklist

Task Details

Task Editing