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

I am getting this. Does that mean my interrupts are mapped incorrectly?

 24:         23          0          0          0  MIPS GIC  31  mt7603e
 25:          2          0          0          0  MIPS GIC  32  mt76x2e

I'm starting to think that this is affecting those of us with boards that have an extra mPCIe slot for use with a 4G modem. I think we need to figure out where that slot is supposed to be mounted, and modify our .dts files.

I think it would be PCI0 irq 4, PCI1 irq 24 and PCI3 irq 25. Then depending on the board, the driver will assign the proper irq the proper “card” bases on slot number.

The generic irq should be in the .dtsi file. The board specifics should be in its own dts file. Some board might have the 2.4 on pci0 and 2.5 on pci1, other the other way around or on pci1 and pci2.

The interrupt assignment should be according to the MT7621 data sheet and can’t be changed. Slot assignment was a design decision by the board maker.

which part of the DTS file is specifying the PCI slot and which is specifying the interrupt?

Is pcieX { that specifies the slot, and the mt76@n,n that specifies the interrupt?

The MT76 part is only used by the driver to specify the eprom to get e.g. MAC address and frequency range as far as was reading the code.

The slots and interrupts should be defined in the pci-bridge part in the MT7621.dtsi. But as we found out, this part is not properly coded / working yet.

Hi,
I pulled using this command:
git clone https://git.lede-project.org/source.git lede

then got this:
OpenWrt SNAPSHOT r7060-7a20c7a05d / LuCI Master (git-18.149.30583-796d687)
Kernel Version
4.14.44

I still only see Radio 0, but I admit I am a bit out of my depth with this. What have I done wrong please?

Is defining them manually in the .dts file the way to go then, like kristrev did earlier
(https://gist.github.com/kristrev/8e8564ead93248de0c5b0fe8e9292689)

hey brainy I figured it out,

In your DTS file, just swap the pcien values around like this:

	pcie1 {
		mt76@0,0 {
			reg = <0x0000 0 0 0 0>;
			device_type = "pci";
			mediatek,mtd-eeprom = <&factory 0x8000>;
			ieee80211-freq-limit = <5000000 6000000>;
		};
	};

	pcie0 {
		mt76@1,0 {
			reg = <0x0000 0 0 0 0>;
			device_type = "pci";
			mediatek,mtd-eeprom = <&factory 0x0000>;
			ieee80211-freq-limit = <2400000 2500000>;
		};

this is working for me

&pcie {
	status = "okay";

	pcie1 {
		mt76@1,0 {
			reg = <0x0000 0 0 0 0>;
			device_type = "pci";
			mediatek,mtd-eeprom = <&factory 0x8000>;
			ieee80211-freq-limit = <5000000 6000000>;
		};
	};

	pcie0 {
		mt76@2,0 {
			reg = <0x0000 0 0 0 0>;
			device_type = "pci";
			mediatek,mtd-eeprom = <&factory 0x0000>;
			ieee80211-freq-limit = <2400000 2500000>;
		};
	};
};

However, not everything is perfect, it seems. Have a look at this.
interrupts

 24:      45152          0          0          0  MIPS GIC  31  mt7603e
 25:      70747          0          0          0  MIPS GIC  32  mt76x2e
01:00.0 Network controller: MEDIATEK Corp. Device 7603
02:00.0 Network controller: MEDIATEK Corp. MT7662E 802.11ac PCI Express Wireless Network Adapter

This requires another patch to fix the vIRQs. They should be increased by 1. I actually have no idea if this makes any difference in anything.

Those interrupts imply you should be using pcie1 and 2 for 2.4 and 5 GHz respectively.

I have created a separate branch dedicated to testing all of this: https://github.com/neheb/source/tree/pci

Make sure to read the commits messages. I changed the pcie format to force people to update their mappings. That and I disabled all of the ports by default, which is how it should be.

1 Like

I was thinking something similar. Maybe even add memory and io ranges and the interrupt per "slot". But I'm not sure if thats really how it should be.

It seems after doing extensive "google-ing" that we should only define the PCI-to-PCIe Bridge and the bridge should allocate the resources without having to specify whats in a slot. (Not that it worked :frowning: ). Which leads to some conclusion that we need both a proper DTS and maybe something is missing in the PCI code...

Look at mt7623.dtsi in linux-next. It does something similar.

On the latest master my wifi is not working. I have tried adding and omitting the information in my .dts file from my previous post. Unsure what else to try at the moment. Commit id is c8677ca89e53e3be7988d54280fce166cc894a7e

System log after trying to enable wifi:

Sat Jun  9 02:58:45 2018 daemon.warn [1488]: <warn>  Invalid sysfs path read for net/tmp.radio0
Sat Jun  9 02:58:29 2018 daemon.warn [1488]: <warn>  Invalid sysfs path read for net/tmp.radio1

cat /proc/interrupts

24:          2          0          0          0  MIPS GIC  31  mt76x2e
25:          2          0          0          0  MIPS GIC  32  mt76x2e

lspci

02:00.0 Network controller: MEDIATEK Corp. Device 7602
03:00.0 Network controller: MEDIATEK Corp. Device 7612

Can you try reading device_type = "pci" to the relevant sections?

That is already inside the dts file under each &pcie entry

Hi,
is it too early to try 18.06?

If it is possible, how do I get access to the 18.06 branch to clone?
Also can someone tell me the commands to clone, then checkout. (Cloned using
git clone https://github.com/openwrt/openwrt.git
git checkout openwrt-18.06

but checkout bombed with:
fatal: not a git repository (or any parent up to mount point /)
Stopping at filesystem boundary (GIT_DISCOVERY_ACROSS_FILESYSTEM not set).

.....I am a bit out of my depth here? Am I living dangerously, or will I be likely to get a reasonably working system??

After running the first command, change the directory to the cloned folder first (cd) before you run the checkout command.

Does 2.4 and 5 GHz WiFi works on openwrt-18.06 on MiR3G without problems?

Thanks for the help. Cloned 18.06. currently Making it!
(Cross fingers & toes!)

Off to bed. Will try it in the morning.

Thanks again, Doug