This related product appears to be in the support list: https://openwrt.org/toh/wavlink/wavlink_wl-wn570ha1
Are these not more-or-less identical?
It seems firmware from https://openwrt.org/toh/hwdata/netgear/netgear_ex6120 works! I have done limited testing but it seems both 2.4 and 5GHz display appropriate scanning results (have not tested txpwr) and LAN port works @ 100Mbit. WAN port untested. Flash method is identical to the RP-N53 method earlier in this thread. I specifically used this image: https://downloads.openwrt.org/releases/21.02.1/targets/ramips/mt7620/openwrt-21.02.1-ramips-mt7620-netgear_ex6120-squashfs-sysupgrade.bin
EDIT: It seems firmware for the Netgear EX3700/EX3800 works as well, https://openwrt.org/toh/netgear/ex3700_ex3800 and used firmware https://downloads.openwrt.org/releases/21.02.1/targets/ramips/mt7620/openwrt-21.02.1-ramips-mt7620-netgear_ex3700-squashfs-sysupgrade.bin
The WAN port does not readily show up in either firmware.
Interesting and disappointing the WAN port doesn't work... that's the PoE port; how the device is powered, and also its uplink. It's fairly useless without that.
Also, according to the advertising material, wavlink reckons the WAN port is 1gbps, and when I connect the WAN port to a switch (using the stock firmware) the switch port lights up green (1g) rather than orange (100m), so it seems the WAN port actually is 1g?
The reference manual for the switch chip describes a wiring configuration where it has 1x 1g port and several 100m ports, so I guess they wired it that way, and I guess these other devices didn't? There must be a software/configuration difference required to respond to the difference in wiring? 
The pictures of the motherboard show a RTL8211F, and the spec says it's a switch chip with 1x 1g port option (and several 100m ports). At least that supports the advertising propaganda, and I guess that chip distinguishes this device from those other devices you've tested. Perhaps a firmware starting from one of those devices you've shown working with an additional driver for RTL8211F needs to be added?
https://www.wavlink.com/en_us/product/WL-WN572HG3.html
TECHNICAL SPECIFICATIONS
Model: WN572HG3
Ports:
1 x 10/100/1000Mbps WAN
1 x 10/100Mbps LAN
RTL8211F: https://datasheet.lcsc.com/szlcsc/1909021205_Realtek-Semicon-RTL8211F-CG_C187932.pdf
Based on the stock firmware, the chip seems to be init as follows:
[ 29.688000] FFFFFF80:3F:5D:FFFFFFD5:13:FFFFFFA3
[ 29.696000] Raeth v3.1 (Tasklet)
[ 29.704000]
[ 29.704000] phy_tx_ring = 0x01882000, tx_ring = 0xa1882000
[ 29.720000]
[ 29.720000] phy_rx_ring0 = 0x01884000, rx_ring[0] = 0xa1884000
[ 29.736000]
[ 29.736000] phy_rx_ring0 = 0x01884000, rx_ring[0] = 0xa1884000
[ 29.752000]
[ 29.752000] Read PhyID ID0:FFFF ID1:FFFF!!
[ 29.760000]
[ 29.760000] Read PhyID ID0:1C ID1:C916!!
[ 29.772000] RTL8211F
[ 29.776000] 0x19:863
[ 29.780000] 0x0:1040
[ 29.780000]
[ 29.788000] SMACCR1 -- : 0x0000803f
[ 29.796000] SMACCR0 -- : 0x5dd513a3
[ 29.804000] esw_update_led 4
[ 29.804000] ESW: Link Status Changed - Port4 Link UP
[ 29.804000] esw_update_led 1
[ 29.804000] ESW: Link Status Changed - Port1 Link UP
[ 29.836000] CDMA_CSG_CFG = 81000000
[ 29.840000] GDMA1_FWD_CFG = 20710000
As per the stock firmware, the WAN port seems to be at port 4. Looking through the scripts, it configures an RT6855 switch as follows:
config-vlan.sh 3 LLLLW - config Ralink RT6855/MT7620/MT7621 ESW with VLAN and WAN at port 4 - within the script, it calls the config6855Esw() function with parameter LLLLW
config6855Esw()
{
#LAN/WAN ports as security mode
switch reg w 2004 ff0003 #port0
switch reg w 2104 ff0003 #port1
switch reg w 2204 ff0003 #port2
switch reg w 2304 ff0003 #port3
switch reg w 2404 ff0003 #port4
switch reg w 2504 ff0003 #port5
#LAN/WAN ports as transparent port
switch reg w 2010 810000c0 #port0
switch reg w 2110 810000c0 #port1
switch reg w 2210 810000c0 #port2
switch reg w 2310 810000c0 #port3
switch reg w 2410 810000c0 #port4
switch reg w 2510 810000c0 #port5
#set CPU/P7 port as user port
switch reg w 2610 81000000 #port6
switch reg w 2710 81000000 #port7
switch reg w 2604 20ff0003 #port6, Egress VLAN Tag Attribution=tagged
switch reg w 2704 20ff0003 #port7, Egress VLAN Tag Attribution=tagged
if [ "$1" = "LLLLW" ]; then
#set PVID
switch reg w 2014 10001 #port0
switch reg w 2114 10001 #port1
switch reg w 2214 10001 #port2
switch reg w 2314 10001 #port3
switch reg w 2414 10002 #port4
switch reg w 2514 10001 #port5
#VLAN member port
switch vlan set 0 1 11110111
switch vlan set 1 2 00001011
At this point, I think we need to figure out:
- How to init the RT8211F chip & talk to it
- How to replicate what the "switch" binary is doing above
- How to appropriately modify the Netgear EX3700/3800/6120 DTS to reflect the port configuration
The newest stock firmware for these seems to have disabled console login, fortunately an older firmware that allows it is still available - filename is WN572HG3-WAVLINK_WO_20200717.bin
I'd like to correspond those addresses with the reference (page 31):
Be nice to have a reference for the switch registers. There's enough information to guess at it though, and that script doesn't look appropriate for this device to me. It's configuring 8 ports builtin to the CPU's SoC, port 0-3 LAN, port 4 WAN, port 5 LAN (no pins on chip), port 6-7 CPU, and there's nothing there that looks like an external port configuration.
That log + config script you paste are both from the stock firmware right? Not from the 'similar' openwrt firmware?
That switch config script looks like it's not the one used for this device... it just looks like it's only configuring the integrated switch without the presence of the RTL8211F. And the startup log does mention the RTL8211F, so that's encouraging, but it must be init somewhere else. Interesting that the startup log names port 4, which if that is the RTL8211F would appear to alias the name of one of the internal switch ports usually used for the WLAN. I wonder how the RTL8211F reaches the CPU...?
Sorry, that's all extremely obvious, I'm just kinda thinking aloud 
I think I can guess at how the connection to the CPU is made. Again, from the manual above, the MT7620A mentions 2 interfaces:
Switch:
5p FE SW + RGMII(1)
4p FE SW + RGMII(2)
Pretty odd that it includes 2 switches; a 5 port switch and a 4 port switch. But it looks like the pinouts for both interfaces can operate as a RGMII interfaces instead for external hardware, if the device wanted to support ie 1g interfaces. Weird they didn't go with 2x 1g interfaces, because using the internal FE switch for a single 100m port is pretty lame! How many cents did they save by not adding a second RTL8211F?
I guess in this device RGMII(1) is configured as the internal 5p FE switch and connected to the LAN port, and RGMII(2) is connected to the RTL8211F by RGMII and connected to WAN.
So it appears the RTL8211F is not memory mapped, not an independent PHY (probably no driver/etc is required), it will look essentially invisible to the MT7620A, it'll probably just be a configuration detail to set the second PHY as RGMII rather than that second '4p FE SW'. Mildly surprised that's not the default tbh!
Probably a matter of poking one value to the right register... if only there was a good hardware reference for MT7620A...
Right on, this was discussed over the last 24h with PaulFertser on IRC & it's basically the conclusion we came to as well. I've locally created a new DTS for this one & started making some modifications, unfortunately this & devices over RGMII are unexplored territory for me! I'll keep poking at it. In the meantime I've also mapped out the GPIOs:
| GPIO | FUNCTION | STATE |
|---|---|---|
| 1 | Reset Button | Active Low |
| 12 | Wifi Signal Mid LED | Active High |
| 13 | Wifi Signal High LED | Active High |
| 41 | LAN LED | Active High |
| 43 | Wifi Signal Low LED | Active High |
| 44 | WAN LED | Active High |
| 72 | Wifi LED | Active High |
It seems the power LED is not on a GPIO, I haven't seen the stock firmware manipulate it either.
Regarding the init scripts & boot log, I can post copies of them here (the bootlog is reasonably helpful for identifying which scripts run - an init system doesn't seem to be at the center of it, it's moreso chains of shell scripts), though it's likely easier to grab the firmware and open up the squashfs for the scripts themselves. Based on the conditional logic within them, I'm reasonably confident the code above is what runs & carries out the internal switch config.
EDIT: Looks like I'm limited to 3 posts! I understand the spam concerns, but it'd be great to get this lifted...
Here's the bootlog: https://pastebin.com/raw/vxr1KQiR
I'd paste it in-line, but there's a 32k character limit for forum posts... and no way to attach files/logs... further limitations!
Regarding another device using a Realtek chip like this over RGMII, there may be something one of these? https://github.com/openwrt/openwrt/tree/master/target/linux/ramips/dts
The reference for RTL8211F which I linked up-thread has some interesting details on page 19.
It talks about RGMII interface and the management interface for setting control registers.
It kinda looks like you communicate with the chip using special ethernet frames... but it also mentions MDC and MDIO pins, so maybe not.
Surely this isn't the only OpenWRT device that features an RTL8211F for 1g ports? There must be an example of this configuration somewhere...
EDIT:
Scratch that, it looks more like the management interface is a weird serial bus off to the side!
I would have to guess then that MT7620A has something like a UART (perhaps is a standard part of RGMII) which buffers control data for transmission. There's probably an interface presented to the MT7620A in a reasonable way.
That said, I would bet there's a >0% chance that the default power-on state will 'just work'. This is a 1g ethernet port chip... what else could the user possibly want to do with it? Defaults are probably all the normal defaults you expect from a 1g ethernet port, and we may not need to communicate with it at all.
I still reckon it's not impossible that we just need to find the MT7620A register that says to use RGMII on the second interface and poke the right value...
Using that firmware downgrade, I can use webcmd.shtml to execute commands as root, but that's a big pain. If I try and telnet to 2323, it connects, but i try and login with root/[password], it's rejected... did you work out the root login?
EDIT: It's admin2860/[password]. Not 'root'.. I wouldn't have guessed that!
Looking for other devices that have the chip we're interested in...
Here's an MT7260A device with 2x gbe ports, so I suspected 2x RTL8211F's for each RGMII interface (like this wavlink should have!!). Photos of the board show the two RTL8211F chips as I anticipated. Sadly this device is listed not working 
... I wonder how much it's not working though?
Here's the supporting patch: https://www.mail-archive.com/openwrt-devel@lists.openwrt.org/msg55794.html
Here's another one that appears to have our hardware configuration:
https://git.openwrt.org/?p=openwrt/openwrt.git;a=commit;h=ed40173dfcbc8a870d1747dea3f9a265d0205369
Here's some possibly interesting fragments:
https://openwrt-devel.openwrt.narkive.com/o5H5luyC/openwrt-support-rtl8211cl-gigabit-driver
https://openwrt-devel.openwrt.narkive.com/jNTj4sTd/what-should-i-do-if-i-want-to-use-the-rgmii-interface-on-ralink-rt3052
https://patchwork.ozlabs.org/project/netdev/patch/1429698120-17882-1-git-send-email-Shengzhou.Liu@freescale.com/
Looks like it might be necessary to send a couple of reset commands on boot.
This looks very interesting, from the Comfast device at the top: https://www.mail-archive.com/openwrt-devel@lists.openwrt.org/msg55794.html
+++ b/target/linux/ramips/dts/mt7620a_comfast_cf-e538ac.dts
@@ -0,0 +1,158 @@
+// SPDX-License-Identifier: GPL-2.0-or-later OR MIT
+/dts-v1/;
+
+#include "mt7620a.dtsi"
+
...
+
+ðernet {
+ status = "okay";
+ pinctrl-names = "default";
+ mtd-mac-address = <&factory 0xe000>;
+ pinctrl-0 = <&rgmii1_pins &rgmii2_pins &mdio_pins>;
+ mediatek,portmap = "llllw";
+
+ port@4 {
+ status = "okay";
+ phy-mode = "rgmii";
+ phy-handle = <&phy4>;
+ };
+
+ port@5 {
+ status = "okay";
+ phy-mode = "rgmii";
+ phy-handle = <&phy5>;
+ };
+
+ mdio-bus {
+ status = "okay";
+
+ phy4: ethernet-phy@4 {
+ reg = <0x04>;
+ phy-mode = "rgmii";
+ };
+
+ phy5: ethernet-phy@5 {
+ reg = <0x05>;
+ phy-mode = "rgmii";
+ };
+ };
+};
+
+&gsw {
+ mediatek,port4 = "gmac";
+};
And the second device (Phicomm K2G)'s DST confirms:
--- /dev/null
+++ b/target/linux/ramips/dts/K2G.dts
@@ -0,0 +1,139 @@
+/dts-v1/;
+
+#include "mt7620a.dtsi"
...
+&pinctrl {
+ state_default: pinctrl0 {
+ gpio {
+ ralink,group = "i2c", "uartf";
+ ralink,function = "gpio";
+ };
+ };
+};
+
+ðernet {
+ pinctrl-names = "default";
+ pinctrl-0 = <&rgmii2_pins &mdio_pins>;
+ mtd-mac-address = <&factory 0x28>;
+ mediatek,portmap = "llllw";
+
+ port@5 {
+ status = "okay";
+ phy-handle = <&phy5>;
+ phy-mode = "rgmii";
+ };
+
+ mdio-bus {
+ status = "okay";
+
+ phy5: ethernet-phy@5 {
+ reg = <5>;
+ phy-mode = "rgmii";
+ };
+ };
+};
There might be sufficient information there to frankenstein a working solution...
Good finds! I tried doing something similar as the Phicomm K2G, but no dice - it doesn't seem to complain, but link-up still not detected.
That said, even U-Boot seems to be able to initialize & make use of the RTL8211F! When flashing firmware, if LAN disconnected and WAN is used instead, it'll detect it as 10/100 and use it for the TFTP file retrieval process. Chances are, bespoke support is not needed.
I've retrieved the GPL sources (keep in mind - this FTP will not provide you with contents when browsing, you need to retrieve the file directly, it's 1,784,547,728 bytes in size) and will look through them to see how they configure things.
I think we're basically there! Should just need some finishing touches and testing, then I'll submit via git & hopefully we can have this one auto-supported from now on!
root@OpenWrt:/# swconfig dev switch0 show
Global attributes:
enable_vlan: 1
mib: Switch MIB counters
PPE_AC_BCNT0: 0
PPE_AC_PCNT0: 0
PPE_AC_BCNT63: 0
PPE_AC_PCNT63: 0
PPE_MTR_CNT0: 0
PPE_MTR_CNT63: 0
GDM1_TX_GBCNT: 0
GDM1_TX_GPCNT: 0
GDM1_TX_SKIPCNT: 0
GDM1_TX_COLCNT: 0
GDM1_RX_GBCNT1: 0
GDM1_RX_GPCNT1: 0
GDM1_RX_OERCNT: 0
GDM1_RX_FERCNT: 0
GDM1_RX_SERCNT: 0
GDM1_RX_LERCNT: 0
GDM1_RX_CERCNT: 0
GDM1_RX_FCCNT: 0
GDM2_TX_GBCNT: 0
GDM2_TX_GPCNT: 0
GDM2_TX_SKIPCNT: 0
GDM2_TX_COLCNT: 0
GDM2_RX_GBCNT: 0
GDM2_RX_GPCNT: 0
GDM2_RX_OERCNT: 0
GDM2_RX_FERCNT: 0
GDM2_RX_SERCNT: 0
GDM2_RX_LERCNT: 3
GDM2_RX_CERCNT: 0
GDM2_RX_FCCNT: 0
mirror_monitor_port: 0
arl_table: address resolution table
Port 0:
mib: Port 0 MIB counters
TxGPC : 0
TxBOC : 0
TxGOC : 0
TxEPC : 0
RxGPC : 0
RxBOC : 0
RxGOC : 0
RxEPC1 : 0
RxEPC2 : 0
enable_mirror_rx: 0
enable_mirror_tx: 0
pvid: 0
link: port:0 link:down
Port 1:
mib: Port 1 MIB counters
TxGPC : 25
TxBOC : 0
TxGOC : 5252
TxEPC : 0
RxGPC : 21
RxBOC : 0
RxGOC : 2128
RxEPC1 : 0
RxEPC2 : 0
enable_mirror_rx: 0
enable_mirror_tx: 0
pvid: 1
link: port:1 link:up speed:100baseT full-duplex
Port 2:
mib: Port 2 MIB counters
TxGPC : 0
TxBOC : 0
TxGOC : 0
TxEPC : 0
RxGPC : 0
RxBOC : 0
RxGOC : 0
RxEPC1 : 0
RxEPC2 : 0
enable_mirror_rx: 0
enable_mirror_tx: 0
pvid: 0
link: port:2 link:down
Port 3:
mib: Port 3 MIB counters
TxGPC : 0
TxBOC : 0
TxGOC : 0
TxEPC : 0
RxGPC : 0
RxBOC : 0
RxGOC : 0
RxEPC1 : 0
RxEPC2 : 0
enable_mirror_rx: 0
enable_mirror_tx: 0
pvid: 0
link: port:3 link:down
Port 4:
mib: Port 4 MIB counters
TxGPC : 150
TxBOC : 0
TxGOC : 47354
TxEPC : 0
RxGPC : 51
RxBOC : 0
RxGOC : 3468
RxEPC1 : 0
RxEPC2 : 17
enable_mirror_rx: 0
enable_mirror_tx: 0
pvid: 2
link: port:4 link:up speed:1000baseT full-duplex
Port 5:
mib: Port 5 MIB counters
TxGPC : 0
TxBOC : 0
TxGOC : 0
TxEPC : 0
RxGPC : 0
RxBOC : 0
RxGOC : 0
RxEPC1 : 0
RxEPC2 : 0
enable_mirror_rx: 0
enable_mirror_tx: 0
pvid: 0
link: port:5 link:down
Port 6:
mib: Port 6 MIB counters
TxGPC : 55
TxBOC : 0
TxGOC : 4660
TxEPC : 0
RxGPC : 198
RxBOC : 0
RxGOC : 57944
RxEPC1 : 0
RxEPC2 : 23
enable_mirror_rx: 0
enable_mirror_tx: 0
pvid: 0
link: port:6 link:up speed:1000baseT full-duplex
Port 7:
mib: Port 7 MIB counters
TxGPC : 0
TxBOC : 0
TxGOC : 0
TxEPC : 0
RxGPC : 0
RxBOC : 0
RxGOC : 0
RxEPC1 : 0
RxEPC2 : 0
enable_mirror_rx: 0
enable_mirror_tx: 0
pvid: 0
link: port:7 link:down
VLAN 1:
vid: 1
ports: 1 6t
VLAN 2:
vid: 2
ports: 4 6t
Wiphy phy1
wiphy index: 1
max # scan SSIDs: 4
max scan IEs length: 2257 bytes
max # sched scan SSIDs: 0
max # match sets: 0
Retry short long limit: 2
Coverage class: 0 (up to 0m)
Available Antennas: TX 0 RX 0
Supported interface modes:
* IBSS
* managed
* AP
* AP/VLAN
* monitor
* mesh point
Band 1:
Capabilities: 0x2fe
HT20/HT40
SM Power Save disabled
RX Greenfield
RX HT20 SGI
RX HT40 SGI
TX STBC
RX STBC 2-streams
Max AMSDU length: 3839 bytes
No DSSS/CCK HT40
Maximum RX AMPDU length 65535 bytes (exponent: 0x003)
Minimum RX AMPDU time spacing: 2 usec (0x04)
HT TX/RX MCS rate indexes supported: 0-15, 32
Frequencies:
* 2412 MHz [1] (20.0 dBm)
* 2417 MHz [2] (20.0 dBm)
* 2422 MHz [3] (20.0 dBm)
* 2427 MHz [4] (20.0 dBm)
* 2432 MHz [5] (20.0 dBm)
* 2437 MHz [6] (20.0 dBm)
* 2442 MHz [7] (20.0 dBm)
* 2447 MHz [8] (20.0 dBm)
* 2452 MHz [9] (20.0 dBm)
* 2457 MHz [10] (20.0 dBm)
* 2462 MHz [11] (20.0 dBm)
* 2467 MHz [12] (20.0 dBm) (no IR)
* 2472 MHz [13] (20.0 dBm) (no IR)
* 2484 MHz [14] (20.0 dBm) (no IR)
valid interface combinations:
* #{ managed, AP, mesh point } <= 8,
total <= 8, #channels <= 1
HT Capability overrides:
* MCS: ff ff ff ff ff ff ff ff ff ff
* maximum A-MSDU length
* supported channel width
* short GI for 40 MHz
* max A-MPDU length exponent
* min MPDU start spacing
max # scan plans: 1
max scan plan interval: -1
max scan plan iterations: 0
Supported extended features:
* [ RRM ]: RRM
* [ CQM_RSSI_LIST ]: multiple CQM_RSSI_THOLD records
* [ CONTROL_PORT_OVER_NL80211 ]: control port over nl80211
* [ SCAN_RANDOM_SN ]: use random sequence numbers in scans
* [ SCAN_MIN_PREQ_CONTENT ]: use probe request with only rate IEs in scans
* [ CONTROL_PORT_NO_PREAUTH ]: disable pre-auth over nl80211 control port support
* [ DEL_IBSS_STA ]: deletion of IBSS station support
* [ SCAN_FREQ_KHZ ]: scan on kHz frequency support
* [ CONTROL_PORT_OVER_NL80211_TX_STATUS ]: tx status for nl80211 control port support
Wiphy phy0
wiphy index: 0
max # scan SSIDs: 4
max scan IEs length: 2247 bytes
max # sched scan SSIDs: 0
max # match sets: 0
Retry short limit: 7
Retry long limit: 4
Coverage class: 0 (up to 0m)
Device supports AP-side u-APSD.
Device supports T-DLS.
Available Antennas: TX 0x3 RX 0x3
Configured Antennas: TX 0x3 RX 0x3
Supported interface modes:
* IBSS
* managed
* AP
* AP/VLAN
* monitor
* mesh point
* P2P-client
* P2P-GO
Band 2:
Capabilities: 0x1ff
RX LDPC
HT20/HT40
SM Power Save disabled
RX Greenfield
RX HT20 SGI
RX HT40 SGI
TX STBC
RX STBC 1-stream
Max AMSDU length: 3839 bytes
No DSSS/CCK HT40
Maximum RX AMPDU length 65535 bytes (exponent: 0x003)
Minimum RX AMPDU time spacing: No restriction (0x00)
HT TX/RX MCS rate indexes supported: 0-15
VHT Capabilities (0x318001b0):
Max MPDU length: 3895
Supported Channel Width: neither 160 nor 80+80
RX LDPC
short GI (80 MHz)
TX STBC
RX antenna pattern consistency
TX antenna pattern consistency
VHT RX MCS set:
1 streams: MCS 0-9
2 streams: MCS 0-9
3 streams: not supported
4 streams: not supported
5 streams: not supported
6 streams: not supported
7 streams: not supported
8 streams: not supported
VHT RX highest supported: 0 Mbps
VHT TX MCS set:
1 streams: MCS 0-9
2 streams: MCS 0-9
3 streams: not supported
4 streams: not supported
5 streams: not supported
6 streams: not supported
7 streams: not supported
8 streams: not supported
VHT TX highest supported: 0 Mbps
Frequencies:
* 5180 MHz [36] (20.0 dBm)
* 5200 MHz [40] (20.0 dBm)
* 5220 MHz [44] (20.0 dBm)
* 5240 MHz [48] (20.0 dBm)
* 5260 MHz [52] (20.0 dBm) (no IR, radar detection)
* 5280 MHz [56] (20.0 dBm) (no IR, radar detection)
* 5300 MHz [60] (20.0 dBm) (no IR, radar detection)
* 5320 MHz [64] (20.0 dBm) (no IR, radar detection)
* 5500 MHz [100] (20.0 dBm) (no IR, radar detection)
* 5520 MHz [104] (20.0 dBm) (no IR, radar detection)
* 5540 MHz [108] (20.0 dBm) (no IR, radar detection)
* 5560 MHz [112] (20.0 dBm) (no IR, radar detection)
* 5580 MHz [116] (20.0 dBm) (no IR, radar detection)
* 5600 MHz [120] (20.0 dBm) (no IR, radar detection)
* 5620 MHz [124] (20.0 dBm) (no IR, radar detection)
* 5640 MHz [128] (20.0 dBm) (no IR, radar detection)
* 5660 MHz [132] (20.0 dBm) (no IR, radar detection)
* 5680 MHz [136] (20.0 dBm) (no IR, radar detection)
* 5700 MHz [140] (20.0 dBm) (no IR, radar detection)
* 5720 MHz [144] (20.0 dBm) (no IR, radar detection)
* 5745 MHz [149] (20.0 dBm) (no IR)
* 5765 MHz [153] (20.0 dBm) (no IR)
* 5785 MHz [157] (20.0 dBm) (no IR)
* 5805 MHz [161] (20.0 dBm) (no IR)
* 5825 MHz [165] (20.0 dBm) (no IR)
* 5845 MHz [169] (disabled)
* 5865 MHz [173] (disabled)
valid interface combinations:
* #{ IBSS } <= 1, #{ managed, AP, mesh point, P2P-client, P2P-GO } <= 8,
total <= 8, #channels <= 1, STA/AP BI must match, radar detect widths: { 20 MHz (no HT), 20 MHz, 40 MHz, 80 MHz }
HT Capability overrides:
* MCS: ff ff ff ff ff ff ff ff ff ff
* maximum A-MSDU length
* supported channel width
* short GI for 40 MHz
* max A-MPDU length exponent
* min MPDU start spacing
max # scan plans: 1
max scan plan interval: -1
max scan plan iterations: 0
Supported extended features:
* [ VHT_IBSS ]: VHT-IBSS
* [ RRM ]: RRM
* [ CQM_RSSI_LIST ]: multiple CQM_RSSI_THOLD records
* [ CONTROL_PORT_OVER_NL80211 ]: control port over nl80211
* [ TXQS ]: FQ-CoDel-enabled intermediate TXQs
* [ AIRTIME_FAIRNESS ]: airtime fairness scheduling
* [ AQL ]: Airtime Queue Limits (AQL)
* [ SCAN_RANDOM_SN ]: use random sequence numbers in scans
* [ SCAN_MIN_PREQ_CONTENT ]: use probe request with only rate IEs in scans
* [ CONTROL_PORT_NO_PREAUTH ]: disable pre-auth over nl80211 control port support
* [ DEL_IBSS_STA ]: deletion of IBSS station support
* [ SCAN_FREQ_KHZ ]: scan on kHz frequency support
* [ CONTROL_PORT_OVER_NL80211_TX_STATUS ]: tx status for nl80211 control port support
Holy shit! That's super awesome!
Well done! What did you have to do in the end? Any surprises?
Is vlan1 or 2 the wan in the default config?
Does OpenWRT have a built-in feature to express signal strength in an LED series (probably a concept present on many devices), or is that just not gonna work? It's not worth the time to write software that maps the signal strength to an LED series, but I might have guesses that there'd be an existing service for that...
LMK when I can test it! 
.. I have around 8 people that will be so happy they can reach the internet from their homes.
It'll be interesting to see if the wlan works well. I have another device that I flashed OpenWRT on recently and the 5g wifi barely works. Drops every few minutes, disappears and reappears sometimes. (TP-Link EAP235-WALL)
Hopefully that's a device support thing and not a reliable OpenWRT experience.
No big ones, moreso figuring out the appropriate incantations in the DTS - and using port 4 for WAN instead of 5 (thus corresponding to the first muxed RGMII interface as opposed to the second dedicated one, at least from my understanding). WAN is on VLAN 2 in the default config.
Signal strength metering is not configured by default, but there's a package you can script up to do this, looks reasonably straightforward.
Until I finalize & commit it, here's a test bin that should do most everything, let me know what you run into. Keep in mind, 5GHz might be broken txpwr-wise (known bug) & I'm not sure if we have support for the onboard PA (it's in the DTS but who knows!). For 5GHz I suggest you do some actual range testing with a device and compare it against another 5GHz AP.
There is currently no LED trigger code that can take the status of either 2.4 or 5GHz radios, so I've left the WiFi status LED floating & it can be manually configured/pointed to whatever is most desired within the UCI config/interface.
The WiFi Signal High LED is used by OpenWrt to indicate boot, failsafe & upgrade status (as the power LED cannot be used for that purpose). The WiFi Signal LEDs are otherwise left floating, and they can be configured to whatever is desired as above. Signal strength metering via RSSI can be done (for either 2.4 or 5GHz, but not both). That said, as choices must be made regarding what RSSI signal thresholds should trigger which LEDs & what radio should be acted upon (currently either 2.4 or 5GHz, but not both), I figured it's best left to the end user to address with the above package.
Please test it and let me know!
To note regarding the above GPIOs, turns out they're all active LOW! I will update the wiki to reflect this.
I've uploaded the extracted firmware - perhaps someone with greater skill can look at the firmware upload pages & CGI binaries & figure out what values the updater is looking for, then we can potentially create a bin used for initial flashing without requiring the backdoor method or opening up the unit.
I'm available to give it a good test run today. What method do you use to flash your new firmware?
I don't really want to take it apart and wire up a serial header. I don't have a serial interface for my PC...
I did everything via serial using a cheap CP2102 USB-TTL converter. If you got telnet via the backdoor, I think you could download the firmware to the device (several ways to accomplish this - including the device's own firmware upload functionality) and flash it with mtd. I'm pretty sure this is how their CGI-BIN scripts do it as well, based on looking at strings in the files. That said, the chance of bricking it is higher this way & I have not tested it.
Are you aware of any guides using MTD this way with devices like this?
EDIT:
Specifically: mtd_write write filename.bin [device]
There are many mtd objects in /dev... how do I pick the right one?
Is this image you link a full flash image, or is it just the OS partition? (ie bootloader/nvram partitions should not be overwritten)?
# cat /proc/mtd
dev: size erasesize name
mtd0: 00800000 00010000 "ALL"
mtd1: 00030000 00010000 "Bootloader"
mtd2: 00010000 00010000 "Config"
mtd3: 00010000 00010000 "Factory"
mtd4: 007b0000 00010000 "Kernel"
I guess I should either overwrite mtd0 or mtd4 with your image... which one? 
EDIT:
I guessed /dev/mtd4 (Kernel), because head -c 100 /dev/mtd4 appeared very similar to the first 100 bytes of your .bin file. and /dev/mtd0 was totally different... so I guessed your bin was a kernel image.
It flashed... reboot, and now not sure if it's bricked, or booted... it doesn't attempt to seek a dhcp lease, not sure how to access it now, if it did boot at all 
EDIT:
Actually, I can see the WAN port light flashing furiously after it turns on (did you hook up the WAN activity light in that image?), I can see a dhcp lease for a device called "OpenWrt", maybe that's it?
manu@Manu-Win10:/mnt/c/Users/Manu/Downloads$ nmap 192.168.0.27
Starting Nmap 7.80 ( https://nmap.org ) at 2022-01-18 23:27 AEST
Nmap scan report for 192.168.0.27
Host is up (0.00053s latency).
All 1000 scanned ports on 192.168.0.27 are closed
Nmap done: 1 IP address (1 host up) scanned in 39.94 seconds
I can't telnet, or ssh, I see no ports open... what state does OpenWrt boot by default?
Can't work out how to interact with it at all any more.
EDIT:
Sorry, I'm such an idiot! It's configured as a router by default, and the default firewall blocks all external ports. I connected to the LAN port instead and I can reach the device. It flashed correctly, I'll test the firmware now.
Well I've been testing it today. I've tested it as an AP and a client, also as both with WDS. I'm seeing a lot of problems... first, it seems to work for a short while and then drops it's connection to the upstream AP, and only returns when I reboot. It seems the local AP goes down at the same time, and the device becomes inaccessible.
When it is working, it connects to the upstream AP and the bridge interface receives a DHCP lease as it should, but the upstream network never seems to be able to access the device. If I connect to the device's AP, then I can access the device using the assigned IP. Weird that I can reach it from downstream, but not from upstream. The firewall is completely disabled.
How can I diagnose problems like this? Are there logs that note interface events that may cause it to fail like this?
I've been testing it successfully as an AP on both 2.4 & 5GHz, which was my intended use case. I'd probably start with log output from the wireless driver (in dmesg) & perhaps there's a way to get the driver to produce debug-level output (this thread might be a good start). I'd use tools like tcpdump & Wireshark to trace out where packets might be getting dropped.
Apologies in advance if I have placed this question in the wrong place, but I have a AC1200 WN572HG3-A with corrupted firmware, and I wondered if anyone has a link to a copy of the full stock firmware for this device so I can re-flash the firmware to get this repeater up and running again.
Any help would be greatly appreciated.
Dave