I had also declared the switch in the meantime, not sure if needed though, since it's indeed a single port device. Maybe just a different switch port than 4? I could see no external phy on the PCB, and as far as I recall, MT7621 has built-in switch phy's already? (I've seen ipq devices which use a dedicated phy even though there are phys in the built-in switch already...)
Thanks, I will look at some more devices and trial-and-error the settings until successful 
pushed a few changes, LAN port is now working, it was missing the pinmux boilerplate: (thanks @aiyion)
ðernet {
pinctrl-0 = <&mdio_pins>, <&rgmii1_pins>;
};
when enabling mt76 firmware debug output (echo "1" > /sys/kernel/debug/ieee80211/phy0/mt76/fw_debug_wm), the same error occurs on both radios when trying to enable any of them:
for phy0:
[ 138.449919] ieee80211 phy0: WM: ( 126.595948:18:CMD-E)Rx Hdr Translation enable=1, CheckBssid=0, InsVlan=0, RemVlan=0, QosTid=0, Mode=0
[ 138.462151] ieee80211 phy0: WM: ( 126.596009:19:CMD-E)Rx Hdr Translation BL Count=1
[ 138.470295] ieee80211 phy0: WM: ( 126.596039:20:CMD-E)Rx Hdr Translation BL setting idx=0, enable=1, ether-type=0x888e
[ 138.481532] ieee80211 phy0: WM: ( 126.627564:21:CMD-S)ProtectCtrl!! Protection Index = 1, DBDC = 0
[ 138.493844] ieee80211 phy0: WM: ( 126.639893:22:INIT-S)Error: Search Key for CSD Rx Failed,Please check Input condition
[ 138.504634] ieee80211 phy0: WM: ( 126.639924:23:INIT-S)K[38]-band[0]-bw[1]-n_rx[3]-dbdc_en[1]-dbdc_idx[0]
[ 138.514382] ieee80211 phy0: WM: Wifi ASSERT @ build/csp/7915/asic2.0/projects/wifi_rebb_ram/../../../../../../wifi/base/7915/prj/exthal/cal/hal_cal_bb.c:1377
for phy1:
[ 100.618256] ieee80211 phy0: WM: ( 88.809937:21:CMD-E)Rx Hdr Translation enable=1, CheckBssid=0, InsVlan=0, RemVlan=0, QosTid=0, Mode=0
[ 100.630660] ieee80211 phy0: WM: ( 88.809998:22:CMD-E)Rx Hdr Translation BL Count=1
[ 100.638489] ieee80211 phy0: WM: ( 88.810029:23:CMD-E)Rx Hdr Translation BL setting idx=0, enable=1, ether-type=0x888e
[ 100.649503] ieee80211 phy0: WM: ( 88.810334:24:CMD-S)ProtectCtrl!! Protection Index = 1, DBDC = 1
[ 100.658521] ieee80211 phy0: WM: ( 88.813996:25:INIT-S)Error: Search Key for CSD Rx Failed,Please check Input condition
[ 100.669620] ieee80211 phy0: WM: ( 88.814026:26:INIT-S)K[38]-band[1]-bw[1]-n_rx[3]-dbdc_en[1]-dbdc_idx[1]
Any ideas what Search Key for CSD Rx Failed would mean, am I lacking some further configuration here, or this just an issue with current mt76 (since building unstable OpenWrt master), which might soon be addressed anyways?
pushed a few more changes
uart2-gpios was required)rssileds package and configstill not working:
rootfs is not aligned to erase block, thus file-system is read-only, sysupgrade not working, maybe also the reason for mt76 driver crashing firmware?
Checking the contents of firmware partition, the 128 bytes elx-header is no longer present there, only the 27051956 uImage header, so the uploaded elx image is being unpacked (and de-xor'ed) by the bootloader recovery upon flashing already.
Will further experiment tomorrow, otherwise I guess we're quite close to a PR 
// edit: oh wow, only 3 consecutive posts allowed
Fixed rootfs alignment to eraseblock, but no improvements regarding mt76 or sysupgrade.
Someone more knowledgeable about the sysupgrade process should have a look at this, it turns out nand_do_upgrade $1 might not be enough.
Regarding the wireless driver, maybe backporting to the last stable OpenWrt could make it work, someone should attempt this before opening an issue with mt76, I will not find the time during the rest of this week. Any further ideas what configuration etc. could be missing here?
Filler comment to enable you to post again 
Even though I have no answers to your questions, I am rooting for you! 
Some additional information: Power can directly be supplied by a 12V power supply. Inner pin is GND, outer pin is +12V. Currnet consumption is about 300mA.
Output of mtd:
device nmbm0 <nmbm0>, # parts = 4
#: name size offset mask_flags
0: u-boot 0x00080000 0x00000000 0
1: u-boot-env 0x00080000 0x00080000 0
2: factory 0x00080000 0x00100000 0
3: firmware 0x07680000 0x00180000 0
active partition: nmbm0,0 - (u-boot) 0x00080000 @ 0x00000000
defaults:
mtdids : nmbm0=nmbm0
mtdparts: mtdparts=nmbm0:512k(u-boot),512k(u-boot-env),512k(factory),-(firmware)
I downgraded to the previous version of package\kernel\mt76\Makefile, with this version iwinfo wlan0/wlan1 scan shows all available wireless networks
Update: Switching to https://github.com/openwrt/mt76/commit/4bf2607362fc64fc4cb7d662feb736b7536c0811 also seems to fix the problem (package/kernel/mt76/patches/100-aggregation-definitions.patch must be removed before build, the patch is already included in the latest commit).
That's great to hear! So it is just the nand sysupgrade issue remaining.
By the way, I see a multitude of changes were introduced to mt76 with 2403428c75c25301996567cdde57e2230e14d766, could you try rebasing the branch to latest OpenWrt master and re-test?
I hope I can find some time by the middle of the week to rebase and try this as well, after retrieving my remaining devices from the store
// edit
Awesome, I was wondering already which of the changes would make the exact difference.
Merged master in https://github.com/RolandoMagico/openwrt/commits/dapx1860, iwinfo wlan0/wlan1 list working
Is the RSSI LED indicator working when connecting to a 5GHz network?
Is this the RSSI LED:
Doesn't work in my setup. Connected to a 5GHz wifi and connected with a client while running as 5GHz AP.
But it's flashing after configuring the LED:
Thanks, I guess we'll need to have another look at that... It is set in /base-files/etc/board.d/01_leds for the interface wlan0, which was mapped to the 5ghz radio as far as I recall (hoping the order of enumeration did not change due to recent patches in mt76).
As far as I see, wlan0 is the 2.4GHz network:
wlan0 ESSID: unknown
Access Point: A8:63:7D:2F:05:A8
Mode: Client Channel: unknown (unknown)
Center Channel 1: unknown 2: unknown
Tx-Power: 3 dBm Link Quality: unknown/70
Signal: unknown Noise: unknown
Bit Rate: unknown
Encryption: unknown
Type: nl80211 HW Mode(s): 802.11bgnax
Hardware: 14C3:7915 14C3:7915 [MediaTek MT7915E]
TX power offset: none
Frequency offset: none
Supports VAPs: yes PHY name: phy0
wlan1 ESSID: unknown
Access Point: 00:0C:43:26:59:97
Mode: Client Channel: unknown (unknown)
Center Channel 1: unknown 2: unknown
Tx-Power: 3 dBm Link Quality: unknown/70
Signal: unknown Noise: unknown
Bit Rate: unknown
Encryption: unknown
Type: nl80211 HW Mode(s): 802.11nacax
Hardware: 14C3:7915 14C3:7915 [MediaTek MT7915E]
TX power offset: none
Frequency offset: none
Supports VAPs: yes PHY name: phy1
But there is also no LED activity when using the 2.4GHz Wifi as AP or client
Finally back at my device, rebased to master, wifi working so far.
rssileds package was not contained in rootfs (might as well blame it on an unclean build, whatever), installed manually via opkg, nothing happens, reboot, everything gone... jffs2 not yet persistent, whatever. added rssileds manually via menuconfig, still not working... see there are not even uci entries generated for the LED rules, whatever... look at source code of rssileds.c, wonder why there is not even an interface wlan0 on the device, but only phy0-sta0, which at least works as an argument for iwinfo to display some rssi value; not sure if phy0-sta0 is soemthing we would like to hardcode for rssi display settings though, or how other devices from the target can just use wlan0 instead 
5 GHz MAC is not correct, wonder how to set this when there is only a single dts node for the pcie device, due to DBDC. I'll check other DBDC devices, maybe needs a duplicate dts node or fix-wifi-mac etc.
It's incremented from the MAC found in the EEPROM usually, check the WAX202 DTS e.g..
Rebased, compared MAC addresses to OEM mapping, using label + 1 for 2.4Ghz and label + 4 for 5 GHz now. Still no idea about jffs2 persistence.
intermediate result:
jffs2 complains about wrong magic number at the start of mtd6 partition, and indeed:
root@OpenWrt:/# hexdump /dev/mtd6
0000000 bb77 2e5d 4b97 d2a5 bb77 2e5d 4b97 d2a5
*
0000080 e956 0f62 ffff ffff ffff ffff ffff ffff
0000090 ffff ffff ffff ffff ffff ffff ffff ffff
*
0020000
this should not be there, resulting in
[ 36.349729] jffs2: Cowardly refusing to erase blocks on filesystem with no valid JFFS2 nodes
[ 36.362493] jffs2: empty_blocks 0, bad_blocks 362, c->nr_blocks 363
besides wondering how there could be no 1-byte hexadecimal output option in hexdump, but ascii/decimal and octal, this turns out to be 128 bytes of 0xFF padding as well as the DEADCODE marker appended by pad-rootfs being XOR'ed with the ELX pattern. When the uploaded image file is being de-XOR'ed by the Recovery flasher, it apparently uses a wrong value to determine the size of the XOR'ed payload, stopping too early (but curiously still writing this to flash).
I'll try to add more padding after the pad-rootfs end marker (maybe that's what the -x option is for 
), I think it should be at least 132 bytes (0x80 bytes of padding + 4 bytes deadcode marker).
Maybe that's just a bug in the bootloader, and since we don't have the RSA key for now to flash via OEM, we cannot really compare if the issue would exist there as well.
I don't have device in hand to test (yet) but wasn't be better to use ubi partition in the way 'mt7621_asus_rt-acx5p.dtsi' use ? It must be created first by splitting 'firmware' partition to "kernel" and "ubi/overlay"
I saw this with many devices in mt7621, and it might be a good idea regarding the additional layer of bad blocks management this would put on top, but I feel too inexperienced to evaluate what would be the best solution to use here.
Also, can we just introduce this regardless of what the stock firmware previously did to that flash area? (It seems so, if it was previously used as raw flash only).
As far as I understand, only the squashfs + jffs2 would be contained within the ubi partition, while the kernel is placed directly into NAND flash, only using the FTL provided by Mediatek. This means during sysupgrade, the kernel is overwritten, assuming this would happen less frequently so no bad blocks would arise, though rootfs_data would be more robust since having the additional UBI layer?
But it seems this would not work with any sort of dynamic mtd-split, but rather requires using a fixed-size kernel partition, which may seem to be a regression.
target/linux/ramips/image$ grep -rn "KERNEL_SIZE :=" mt7621.mk
205: KERNEL_SIZE := 4096k
295: KERNEL_SIZE := 4096k
312: KERNEL_SIZE := 4096k
341: KERNEL_SIZE := 4096k
356: KERNEL_SIZE := 4352k
402: KERNEL_SIZE := 4096k
552: KERNEL_SIZE := 4096k
907: KERNEL_SIZE := 8192k
941: KERNEL_SIZE := 4096k
975: KERNEL_SIZE := 4096k
1025: KERNEL_SIZE := 4096k
1133: KERNEL_SIZE := 4096k
1180: KERNEL_SIZE := 4096k
1200: KERNEL_SIZE := 4096k
1230: KERNEL_SIZE := 4096k
1272: KERNEL_SIZE := 4096k
1300: KERNEL_SIZE := 4096k
1474: KERNEL_SIZE := 4352k
1507: KERNEL_SIZE := 4096k
1673: KERNEL_SIZE := 4096k
1708: KERNEL_SIZE := 4096k
1761: KERNEL_SIZE := 4096k
1818: KERNEL_SIZE := 4096k
1832: KERNEL_SIZE := 4096k
2063: KERNEL_SIZE := 3145728
2230: KERNEL_SIZE := 4096k
2313: KERNEL_SIZE := 4096k
2576: KERNEL_SIZE := 8192k
2602: KERNEL_SIZE := 4096k
For the moment, the kernel is slightly above 2.6 MiB, but exceeding the 4 MiB limit could likely fall into the hardware lifespan of these device, which would require a lot more fiddling in the distant future (most probably involving the loss of UBI bad blocks information, which might be a bad thing for devices aged over so many years).
But again, I don't really want to make this decision here.
Regarding the ELX vs. padding: just adding 132 bytes of zero-padding after the DEADC0DE marker before shoving this into elx-header will only result in more garbage (i.e. exactly those 132 bytes of XOR'ed zeroes) to be appended, so the size of the payload must be somehow determined based on kernel and/or filesystem headers maybe?
// edit: the elx-header recipe in include/image-commands.mk would just stat the input file and write that value into the header:
echo -ne "$$(printf '%08x' $$(stat -c%s $@) | fold -s2 | xargs -I {} echo \\x{} | tr -d '\n')" | \
dd bs=8 count=1 conv=sync; \
Maybe further experimentation should be towards messing with that value in the elx header; Unfortunately I won't find the time for this during the rest of this week.
But You might test this on device. This solution will be investigated in PR anyway by devs.
'firmware' partition space is your to take and 4MB kernel limit might be more related to uBoot kernel loader .For some devices we use lzma-loader to overcome uBoot limits. No worries there.