Since the IPQ8071A platform is now getting supported with the Xiaomi AX3600, how hard would it be to add support for the Zyxel NWA210AX; is anyone working on it?
Specs:
1x 1 Gigabit Ethernet
1x 2.5 Gigabit Ethernet
Wifi AX support on 2.4 GHz and 5 GHz
Max. 2400 Mbit/s on 5 GHz
Max. 575 Mbit/s on 2.5 GHz
And since I couldn't find much about the CPU, does anyone know how the IPQ8071A compares to the IPQ8074A like in the FritzBox 4060 at more demanding tasks like Wireguard / OpenVPN encryption? (That's also the reason I'm not considering the NWA50AX with MT7621AT)
It may range from "relatively straightforward" ('just' another ipq807x system) to "impossible" (secure boot fuse enabled and fully locked down bootloader), no one knows, until it lands on the desk of someone willing to work on it, case removed, serial console attached.
The specifications suggest that it may be supportable, the ZyXEL NBG7815 already is, but no one has looked into the NWA210AX, yet.
It's the same SOC family, you can compare the specifications 1:1. The obvious difference would be the clock frequency, 4*1.0 GHz (factory overclocked to 1.38 GHz on the Xiaomi AX3600) for ipq8071a vs 4*2.2 GHz on ipq8072a and up - and you will feel that difference easily.
I've started adding support for Zyxel NWA210AX.
While the OEM firmware is not too bad, what annoyed me was that Zyxel locks down 802.11r behind their "Nebula" cloud. And apparently, they've already started adding firmware encryption to some models (luckily not yet for this model).
Anyways …
Ethernet: 1x 2.5G RJ45 port (QCA8081), 1x 1G RJ45 port (AR8033)
WiFi1: QCN5024 2.4GHz (ax/b/g/n)
WiFi2: QCN5054 5GHz (ac/ax/n)
Power: DC 12V/PoE
Button: Reset
Flash instructions:
In OEM web interface navigate to gear icon → System → SSH and enable SSH.
Log in via SSH (user/password is the same as for the web interface).
Run debug dual-boot show.
Verify that it outputs: Current Image num: 1.
If this is not the case (i.e. if the output is Current Image num: 0):
a) Either flash a fresh version of factory firmware or
b) run debug dual-image set boot-image image0 and then run reboot.
Log in via SSH again, verify that debug dual-boot show outputs Current Image num: 1.
Reopen factory web interface, navigate to wrench icon → File Manager → Firmware Package and upgrade with openwrt-qualcommax-ipq807x-zyxel_nwa210ax-squashfs-factory.bin.
If everything seems to work, connect to OpenWrt via SSH and make booting to OpenWrt persistent by running zyxel-nwa210ax-bootconfig set image0 and proceed by typing yes.
(This does not happen automatically yet! If this is not executed, at the next reboot the device will be back on whatever factory image is installed on image1. You have to do this on OpenWrt, the OEM firmware debug dual-iamge set-command will not let you set image0 as bootable, as it thinks the firmware upgrade failed.)
Debricking:
Connect via serial (115200 baud), make sure to set adapter to 3.3V. (If the device is bottom up and you are looking at the ethernet ports, pins are located on the left side of the "ethernet port bay", right next to LAN1. With the device still being bottom up, if you look straight at the serial pins, from left to right they are GND-RX-TX-VCC.)
Interrupt boot by pressing any key. (If you want to see all available commands type athe.)
Set tftp server ip with atns <IP>.
Set tftp client ip with atna <IP>.
Set filename with atnf <filename>.
Then run atnz and OEM firmware will be flashed.
Caveats:
Maybe parts of my code aren't that pretty (I have never done this before lol) and – at least for now – I won't be spending more time developing this any further. So if anyone else is interested in this and has more spare time than me, feel free to take this to completion/make a pull request to the official repo once everything is done, etc.
For now, I have only tried flashing this from factory to image0 (i.e. if OEM firmware is currently booted from image1). I have not tried what happens if you flash it with OEM firmware booted from image0.
Persistent boot to OpenWrt must be done manually (see above). In the future, this could be implemented in a similar way to what is done now for the other NWA-devices in /lib/preinit/95_apply_bootconfig from zyxel-bootconfig package. Although there, I don't like that it writes it to NOR flash at every boot without checking if that's even necessary. I think it would be better to implement a check first, to see whether image0 is already active and only write to flash if it's not. But I digress.
I have not tested the reset button.
I have not tested whether UPLINK-port successfully negotiates at 2,5GBit/s.
The MAC addresses for the wired interfaces are not being automatically mapped yet. They are successfully extracted from mrd partition, so they are present in /etc/board.json, but there seems to be some bug (similar to this?) so they don't get "sent over" to uci. You need to set them manually in /etc/config/network using the info from /etc/board.json.
LEDs are not working yet. I believe some LEDs (probably at least the locator LED?) are controlled directly by GPIO, but (at least) the main LED seems to be controlled via I2C with an LP5562. If anyone wants to make the LEDs work, there might be some info in the stock DTS file or the kernel module (/usr/lib/modules/4.4.60/extra/platform_support.ko) which the OEM firmware uses to map the LEDs to /proc/support. Further info regarding LEDs might also be found in OEM firmware binaries /usr/bin/zyled-client and /usr/bin/zyled-ctrl.
Misc:
The ath11k board file is taken from OEM firmware. My NWA210AX used board id 292 (see OEM dmesg output below), with Version WLAN.HK.2.6-02451-QCAHKSWPL_SILICONZ-1.588115.1 v2 (according to cat /lib/firmware/IPQ8074/fw_version.txt on OEM firmware). I updated the embedded regdb (v34) with the one from here (WLAN.HK.2.9.0.1-01890-QCAHKSWPL_SILICONZ-1 with regdb v39). OpenWrt sees it as board id 255, so I updated the board file to match this (although, I just realized, I could have corrected this in the DTS, oh well).
I also built an image for qosimo/openwrt-ipq, but there I couldn't get VLANs to work properly (DHCP requests were always sent untagged for some reason, even though the interface was mapped to a uplink.xx device). I didn't debug this any further, as for me the performance with vanilla OpenWrt is just fine.