MT7621 PCIe DTS issues. (MT76 stopped working with latest updates)

neheb · May 31, 2018, 11:37pm

Please try this patch:

biangbiangmian · May 31, 2018, 11:54pm

Should I revert the interrupt values to the previous 24, 25, 26?

Currently compiling. I shouldn't have to do a make clean, should I?

biangbiangmian · June 1, 2018, 12:20am

That didn't seem to work with the default values, still getting downnload failed for the mt7603, but I am trying with the updated interrupts.

EDIT: I had some &pci annotations in my .dts file for my board which were contradictory, so I have removed those and testing again with the interrupt values of 24,25,26.

robimarko · June 1, 2018, 12:31am

You gotta make clean off course

biangbiangmian · June 1, 2018, 12:55am

Here's the .dtsi file from a known working version (much older kernel though)

biangbiangmian · June 1, 2018, 1:05am

It has been reported that a bug fix has been added to master.

github.com/openwrt/mt76

OpenWRT build issues - Can't find MT76 wireless drivers

opened 05:19PM - 22 May 18 UTC

closed 10:32AM - 07 Jun 18 UTC

CR-Ryan

We just pulled the latest OpenWRT code, and ran into build issues right away. … - Both radios will not come up - The default wireless config is incomplete Here is the default wireless config that is generated: "config wifi-device 'radio0' option type 'mac80211' option channel '36' option hwmode '11a' option path 'pci0000:00/0000:00:00.0/0000:01:00.0' option htmode 'VHT80' option disabled '1' config wifi-iface 'default_radio0' option device 'radio0' option network 'lan' option mode 'ap' option ssid 'OpenWrt' option encryption 'none'" We replaced that config with a known good one, and when we do a wifi reboot, we get these errors: _Tue May 22 16:23:38 2018 daemon.notice netifd: radio1 (1746): Could not find PHY for device 'radio1' Tue May 22 16:23:38 2018 daemon.notice netifd: radio1 (1761): WARNING: Variable 'data' does not exist or is not an array/object Tue May 22 16:23:39 2018 daemon.err hostapd: Configuration file: /var/run/hostapd-phy1.conf Tue May 22 16:23:40 2018 daemon.err hostapd: Could not set interface wlan1 flags (UP): Operation timed out Tue May 22 16:23:40 2018 daemon.err hostapd: nl80211: Could not set interface 'wlan1' UP Tue May 22 16:23:40 2018 daemon.notice hostapd: nl80211: deinit ifname=wlan1 disabled_11b_rates=0 Tue May 22 16:23:40 2018 daemon.err hostapd: nl80211 driver initialization failed. Tue May 22 16:23:40 2018 daemon.notice hostapd: wlan1: interface state UNINITIALIZED->DISABLED Tue May 22 16:23:40 2018 daemon.notice hostapd: wlan1: AP-DISABLED Tue May 22 16:23:40 2018 daemon.notice hostapd: wlan1: CTRL-EVENT-TERMINATING Tue May 22 16:23:40 2018 daemon.err hostapd: hostapd_free_hapd_data: Interface wlan1 wasn't started Tue May 22 16:23:40 2018 kern.err kernel: [ 1318.987207] mt76x2e 0000:01:00.0: MCU message 20 (seq 3) timed out Tue May 22 16:23:40 2018 daemon.notice netifd: radio0 (1745): cat: can't open '/var/run/wifi-phy1.pid': No such file or directory Tue May 22 16:23:40 2018 daemon.notice netifd: radio0 (1745): WARNING (wireless_add_process): executable path /usr/sbin/wpad does not match process path () Tue May 22 16:23:40 2018 daemon.notice netifd: radio0 (1745): Command failed: Invalid argument Tue May 22 16:23:40 2018 daemon.notice netifd: radio0 (1745): Device setup failed: HOSTAPD_START_FAILED_ We interpreted these errors to mean that the wireless drivers are missing - is that correct? Is anyone else having issues on the latest code? (18.06)

You need to remove some pcie lines from the dts file. But a fix has already
been commited to master for a lot of, maybe even all, devices affected.

sotux · June 1, 2018, 2:48am

After removed these lines, my devices (youhua wr1200js, mt7603e + mt7612e) 5G wifi not work, but the firmware loading correct. The 5G wifi not work (mt7612e attached on pcie1)

biangbiangmian · June 1, 2018, 4:40am

On the latest master, with mt7621 chipset, U7621-06 board, using mt76 drivers, I am still getting this:

[   13.726939] PCI: Enabling device 0000:00:00.0 (0004 -> 0006)                 
[   13.732804] mt7603e 0000:01:00.0: ASIC revision: 76030010                    
[   13.740924] mt7603e 0000:01:00.0: Firmware Version: ap_pcie                  
[   13.746496] mt7603e 0000:01:00.0: Build Time: 20160107100755                 
[   14.828816] MCU message -1 (seq 1) timed out                                 
[   14.833071] mt7603e 0000:01:00.0: Download request failed                    
[   14.838638] mt7603e: probe of 0000:01:00.0 failed with error -145            
[   14.847503] PCI: Enabling device 0000:00:01.0 (0004 -> 0006)                 
[   14.853351] mt76x2e 0000:02:00.0: ASIC revision: 76120044                    
[   14.879445] mt76x2e 0000:02:00.0: ROM patch build: 20141115060606a           
[   14.889290] mt76x2e 0000:02:00.0: Firmware Version: 0.0.00                   
[   14.894765] mt76x2e 0000:02:00.0: Build: 1                                   
[   14.898858] mt76x2e 0000:02:00.0: Build Time: 201507311614____               
[   14.928817] mt76x2e 0000:02:00.0: Firmware running!                          
[   15.948812] mt76x2e 0000:02:00.0: MCU message 1 (seq 1) timed out

biangbiangmian · June 1, 2018, 5:21am

Do we need this patch when using the latest master with your fix?

neheb · June 1, 2018, 5:54am

That patch is totally broken. I'm still investigating what the problem could be. For now, revert

02f815d1907cdd7e042415a2b4a749c819087168
e07baec9faf487fd143976636025b5da55e13c20
13c814797437392c538138f2e6563d4a68db779c

to get working wifi.

kristrev · June 1, 2018, 7:38am

If you were referring to my patch, then yes, it seems like you can drop it. While it solves the issue for me (and some other users), it seems, like commit 02f815d1907cdd7e042415a2b4a749c819087168 from neheb, to not help everyone and it is not the correct fix for the problem.

I took a look today at two mt7621-devices, one with working wifi and one without (WG3526 and WE1326). On WG3526, the following interrupts are used for wifi (cat /proc/interrupts):

 23:      84765          0          0          0  MIPS GIC  11  mt7603e
 24:      27389          0          0          0  MIPS GIC  31  mt76x2e

On the WE1326, I see the following:

 24:          0          0          0          0  MIPS GIC  11  mt76x2e

No interrupt 23 for the mt7603 (no interrupt 23 at all), and the mt7612 card does not work. If I apply my patch (updating the interrupt map), I see the following:

 23:         23          0          0          0  MIPS GIC  32  mt7603e
 24:       3010          0          0          0  MIPS GIC  31  mt76x2e

Wifi now works. I unfortunately am not able to check how the mapping looked before the bad commit.

EDIT: Here is the mapping on the WE1326 after reverting the bad commit + commits that depended on it:

 24:       2792          0          0          0  MIPS GIC  31  mt76x2e
 25:      13123          0          0          0  MIPS GIC  32  mt7603e

I.e., the same as I see after my patch.

drbrains · June 1, 2018, 8:39am

I haven’t figured it out completely yet, but it should be “just” DTS related. For some reason the PCIe bridge needs to be properly defined. All PCIe0 - 2 need their own ranges etc.

Going over the warnings, I’m getting similar warnings on the MT7628, but the(pci) driver will work because it will use the default values. Since on the MT7621 the WiFi is on slot 1 and 2 on the PCIe bus and not on 0 it won’t work.

Their were a lot of problems with this on other SoCs. Unfortunately DTS is messy and poorly documented at best.

Two options: revert the pci driver back and let it be “hard coded” or get a proper DTS.

biangbiangmian · June 1, 2018, 8:43am

Well, seeing as it's a breaking change, I vote for reverting to what works, and working on this in a research branch

sotux · June 1, 2018, 9:47am

My router's (youhua wr1200js) irq with both 2G & 5G wifi working is

 22:    9849273          0          0          0  MIPS GIC  11  mt7603e
 23:    2567647          0          0          0  MIPS GIC  31  mt76x2e

Mushoz · June 1, 2018, 9:52am

I fully agree with this sentiment.

robimarko · June 1, 2018, 9:55am

It looks like everything was reverted couple of minutes ago

biangbiangmian · June 1, 2018, 10:15am

With the latest commits (after reverting all of those bad commits) here is what I have

[   12.808012] mt7603e 0000:01:00.0: ASIC revision: 76030010
[   12.816069] mt7603e 0000:01:00.0: Firmware Version: ap_pcie
[   12.821690] mt7603e 0000:01:00.0: Build Time: 20160107100755
[   12.860445] firmware init done
[   13.031107] ieee80211 phy0: Selected rate control algorithm 'minstrel_ht'
[   13.038678] bus=0x2, slot = 0x1, irq=0xff
[   13.042756] PCI: Enabling device 0000:00:01.0 (0004 -> 0006)
[   13.048586] mt76x2e 0000:02:00.0: ASIC revision: 76120044
[   13.081403] mt76x2e 0000:02:00.0: ROM patch build: 20141115060606a
[   13.093126] mt76x2e 0000:02:00.0: Firmware Version: 0.0.00
[   13.098615] mt76x2e 0000:02:00.0: Build: 1
[   13.102723] mt76x2e 0000:02:00.0: Build Time: 201507311614____
[   13.130538] mt76x2e 0000:02:00.0: Firmware running!

bmork · June 1, 2018, 10:23am

I'm not sure what was intended, but I believe it would be slightly more useful to log "irq" instead of "dev->irq" at this point.

kristrev · June 1, 2018, 10:24am

I think that I see what goes wrong for the WE1326. Now that the commits are reverted, my patch is not needed any more, but I will export my notes so that a) I don't lost them and b) I can be told how wrong I am.

Earlier, the value of irq was set in the large if-clause that was removed by commit 5f7396ebef09b224edf08b0bda113613a42f0928. The wifi cards on the 3526 are on bus 1, slot 0 (5Ghz) and bus 2, slot 1 (2.4GHz). When the wifis are enabled, pcie_link_status is six for both of them. The RALINK_INT_PCIE-values seems to map directly to the interrupts specified in the dtsi. The IRQ for the 5Ghz was set to PCIE1 (24) and 2.4GHz set to PCIE2 (25). At least those were the IRQ values specified when I made the change suggested by @bmork.

The hardware interrupt number is obtained by doing GIC_SHARED_HWIRQ_BASE + x (where X is either 4, 24 or 25). GIC_SHARED_HWIRQ_BASE is defined as GIC_NUM_LOCAL_INTRS, which is seven. This is why we see GIC 11, 31 and 32. See /drivers/irqchip/irq-mips-gic.c and /arch/mips/include/asm/mips-gic.h for these values.

After commit 5f7396ebef09b224edf08b0bda113613a42f0928, the pcie_link_state check + static IRQ assigned for the different buses are removed. Instead, the values from the DTS is used directly. A consequence of this is that the 5GHz wifi (mt76x2, first pci device) in the 1326 is incorrectly assigned IRQ 11. The correct interrupt is 31, i.e., GIC shared 24. The correct interrupt for the 2.4GHz is 32, i.e., GIC shared 25.

In order to ensure the correct IRQ mapping on the WE1326, the GIC shared numbers needs to be updated to 24 for 0x1000 and 25 for 0x2000. This is what I did in my patch, and is why it worked.

biangbiangmian · June 1, 2018, 10:52am

Not out of the woods yet it seems. The devices are showing up and everything seems normal, until I try to enable the wifi. Last time all I needed to do was install wpad-mini. I have tried both wpad-mini and wpad (full), but still unable to broadcast wireless (or join it to other networks a la WDS).

Edit:
Tested with mt7612, mt7603, and mt7602, same result.