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

So it's either the first or third. My guess is the first.

It's 5f7396ebef according to another bisector: https://github.com/openwrt/mt76/issues/173

This fixes ZBT WE1326. The same bogus 00000 lines are in the MIR3G.dts and R6220.dts files.

Thanks to mangix on irc!

I don't quite understand how this is supposed to fix ZBT WE1326. The reg attribute is supposed to make it possible for the code to map the mt76@0,0 section to a particular PCI slot.

The reg for mt76@0,0 was never an issue. It was always mt76@1,0. I deleted both in the patch since they're both specified in mt7621.dtsi.

As far as why this is happening, the PCI driver before the relevant changes had values hardcoded. After the change, it uses DTS to get the right information.

Just chiming in to say I am seeing the exact same issues with an MT7621 SoC, using MT7602EN, MT7612EN and MT7603EN, using the latest 18.06, and also 17.01.4. Tried using the mt76 packages.

With the latest "git pull" patches, it still doesn't work. It seems it needs the interrupt code back:


Mac 1200R v2 (MT7628 + MT7612e)

[   12.812021] mt76_wmac 10300000.wmac: ASIC revision: 76280001
[   12.827958] mt76_wmac 10300000.wmac: Firmware Version: _e2_mp
[   12.839413] mt76_wmac 10300000.wmac: Build Time: 20150211175503
[   12.869648] firmware init done
[   13.042381] ieee80211 phy0: Selected rate control algorithm 'minstrel_ht'
[   13.063371] mt76x2e 0000:01:00.0: card - bus=0x1, slot = 0x0 irq=4
[   13.075855] mt76x2e 0000:01:00.0: ASIC revision: 76120044
[   13.122026] mt76x2e 0000:01:00.0: ROM patch build: 20141115060606a
[   13.157995] mt76x2e 0000:01:00.0: Firmware Version: 0.0.00
[   13.168906] mt76x2e 0000:01:00.0: Build: 1
[   13.177011] mt76x2e 0000:01:00.0: Build Time: 201507311614____
[   13.231432] mt76x2e 0000:01:00.0: Firmware running!

ZBT WE1326 (MT7621 + MT7603 + MT7612e)

[    0.000000] Linux version 4.14.44 (drbrains@debian) (gcc version 7.3.0 (OpenWrt GCC 7.3.0 r6953-aa30eb5b07)) #0 SMP Wed May 30 04:38:19 2018
..
[   12.485416] mt7603e 0000:02:00.0: ASIC revision: 76030010
[   12.493599] mt7603e 0000:02:00.0: Firmware Version: ap_pcie
[   12.499197] mt7603e 0000:02:00.0: Build Time: 20160107100755
[   13.517188] MCU message -1 (seq 1) timed out
[   13.521444] mt7603e 0000:02:00.0: Download request failed
[   13.526989] mt7603e: probe of 0000:02:00.0 failed with error -145
[   13.536101] mt76x2e 0000:01:00.0: ASIC revision: 76120044
[   13.567834] mt76x2e 0000:01:00.0: ROM patch build: 20141115060606a
[   13.577557] mt76x2e 0000:01:00.0: Firmware Version: 0.0.00
[   13.583036] mt76x2e 0000:01:00.0: Build: 1
[   13.587110] mt76x2e 0000:01:00.0: Build Time: 201507311614____
[   13.607198] mt76x2e 0000:01:00.0: Firmware running!
[   14.637186] mt76x2e 0000:01:00.0: MCU message 1 (seq 1) timed out

With latest patch (git pull) DTS:

&pcie {
	status = "okay";

	pcie0 {
		mt76@0,0 {
			mediatek,mtd-eeprom = <&factory 0x8000>;
			ieee80211-freq-limit = <5000000 6000000>;
		};
	};

	pcie1 {
		mt76@1,0 {
			mediatek,mtd-eeprom = <&factory 0x0000>;
			ieee80211-freq-limit = <2400000 2500000>;
		};
	};
};

The MT7628 doesn't have the problem and its DTS file still has the reg <000..> etc code. But from the log it shows that its getting an IRQ assigned.

@drbrains I saw the same (remvoing reg had no effect) and submitted the following patch yesterday: https://patchwork.ozlabs.org/patch/922327/. After updating the interrupt mapping (on a WE1326), wifi works again for me. Here is the change, would be great if you could test it:

This change looks evil. Can you try changing pcie0 and 1 to 1 and 2?

My device (Youhua wr1200js, 7603e + 7612e) also meets this problem, the 5G wifi doesn't work now.
After I reverted Commit 8ccdf809, 2.4G & 5G wifi both worked.

I reverted my change and tried changing the pcie numbering, but with the same result. Both wifi radios still give the same error message (MCU timed out).

The motivation behind my change, was that I instrumented mt7621-pci.c to write which IRQ was set before/after the "bad" commit. Before the commit, IRQ 24/25 was set for pcie1/2, while IRQ 24/23 was set after.

So I tried various combination in the DTS file. No effect. I think we should start looking at the pci driver code. Somehow the parts to allocate IRQs is missing/faulty. As for IRQ numbers: 4, 24 and 25 as in the MT7621.dtsi are correct according to the datasheet.

I tried putting the MT76 at pcie1 and pcie2 as this is where they are suppose to be, but it seems more cosmetic then anything else.

Where do i can get the DS of MT7621?

Literaly first thing when you google MT7621 datasheet,there is also a programming guide available

1 Like

ftp.mqmaker.com refused to connect. :frowning:

IRQ 24/23 is either a typo or an endianness issue. That doesn't sound right.

I will try to double check tomorrow, but I believe it is correct. I see that irq in the old version of the driver is written without any endianess conversion.

I may be close to solving this. So currently I have a few patches on the mailing list that fix some mt7621.dtsi warnings. The pci fixes currently cause this error:

[ 2.176977] pci 0000:00:00.0: bridge configuration invalid ([bus 00-00]), reconfiguring
[ 2.193140] pci 0000:00:01.0: bridge configuration invalid ([bus 00-00]), reconfiguring
[ 2.209383] pci 0000:00:02.0: bridge configuration invalid ([bus 00-00]), reconfiguring

I'm currently looking at mt7623.dtsi from the linux kernel to see any inconsistencies. The interrupt map seems to be different, and it seems to match the reg values of the pcie ports. Will do some more testing to see if that's the issue.

edit: so according to /proc/interrupts, my main board has the pcie devices on interrupts 23,24, and 25. my test board has them on 24,25,26... this is confusing more than enlightening.

If it's any help, I have been seeing this issue for longer than 2 weeks. I got a sample board with an mt7603e on the 23rd of March 2018, tried to load the then current 4.9 build, and the wifi would not work. As reported by others, on the latest 4.14 (LEDE 18) build I could get 5G wifi working under certain circumstances (oddly, If I loaded a Ralink driver), but it would drop out regularly. Also there is no real ability to control the transmit power.

Chipset: MT7621 SoC
WiFi: MT7603e, MT7612e
Board: UniElec U7621-06 256MB RAM

I will be testing changing the interrupts to the following values. mt7621.dtsi

		#interrupt-cells = <1>;
		interrupt-map-mask = <0xF0000 0 0 1>;
		interrupt-map = <0x10000 0 0 1 &gic GIC_SHARED 4 IRQ_TYPE_LEVEL_HIGH>,
				<0x20000 0 0 1 &gic GIC_SHARED 24 IRQ_TYPE_LEVEL_HIGH>,
				<0x30000 0 0 1 &gic GIC_SHARED 25 IRQ_TYPE_LEVEL_HIGH>;

		status = "disabled";

		resets = <&rstctrl 23 &rstctrl 24 &rstctrl 25>;
		reset-names = "pcie0", "pcie1", "pcie2";
		clocks = <&clkctrl 23 &clkctrl 24 &clkctrl 25>;
		clock-names = "pcie0", "pcie1", "pcie2";