You mentioned that in an earlier post that after a reset you got reset to a previous version.
I did do a reset a few hours ago to see if that would happen too. But although my WAX206 did come with an earlier firmware out of the box it got reset to 1.0.4.0.
I don't think that happens at a normal reset. I soldered up the ttl header on my wax206 today and played a bit with luci interface on the original firmware. When tried to flash the 1.0.4.0 Firmware from luci, the bootloader said, that the image was corupt and reflashed to the previous firmware.
Has anybody been succesfull in booting the box via tftp? I wasn't succesfull.
Using bootm, yeah, there's no image worth writing to flash, yet.
To @frollic @sumo I would be very happy to put a bounty on a flashable image for the WAX206 if there is a posibility. Obviously keeping it open source all the way and available through the OpenWrt project pages.
I have a WAX206 together with an EX6120 and I would like to flash both and start using them with the wifi mesh functionality OpenWrt offers. Extenders suck and most mesh solutions for home application are way too over priced... so I am very prepared to pay a bounty to the one who manages to succesfully port it. In the end I'll likely be cheaper off that way compared to buying the mesh routers by Netgear themselves as example...
I tagged people in here, but honestly, I would like to extend my offer to whoever manages to get the latest OpenWrt version to correctly work on the WAX206.
My bounty offer: 100 USD - payable by wise or paypal, to a person or to the OpenWrt project itself.
I got around to solder and get serial access to the WAX206. After using @sumo git branch to build an initramfs and playing around with the device tree I'm as wise (or dump) as before.
Preface: Unfortunately I don't have much (if any) embedded dev knowledge, I'm more of a (un)trained monkey with some programming and debugging skills.
I was setting the phy-mode and speed keys to the same value as in the Netgear provided device tree. OpenWrt is happy and reports all successs in the logs but no traffic over either lan or wan (`tcpdump -i eth0 -vvv) except DHCP client broadcast for wan (from WAX206 itself). The lan1-4 port do register if the network cable is disconnected or connected (ethtool). ethtool reports the wan port always got a link not matter what.
Looking into the source provided by Netgear for v1.0.4.0 there's a patch that adds handling of the RTL8221B IRQ in the mt753x (file target/linux/mediatek/patches-4.4/1007-822x-irq.patch in WAX_V1.0.40_SOURCE) as an external phy. I assume that's the reason why in their DTS there's ext-phy and ext-phy-reset-gpio in the mac@0 node.
cat /proc/interrupts on Netgears firmware lists the interrupts for RTL8221B:
69: 1 0 mt-eint 53 Level gsw@0
93: 0 0 mt-eint 77 Edge rtl822x_irq
In the current OpenWrt initramfs there's no IRQ 77.
A few questions:
phy-mode is set to sgmii, is that the right mode even for 2.5GbE (since I read that SGMII only supports speed up to 1+a-bit Gbit)?And to finish it off: I found a partly similar setup in MTK830 + RTL8221B-VB-CG 2.5G question
.The 2.5G port connected mk7531 seems not to work either.
I finally got the WAN port working by looking at other boards with the RTL8221B chip and try-and-error.
The correct settings for the RTL8221B could be found in the following commit, in their ethernet-phy@7 section: add board support for samknows whitebox x
Adding the following to ethernet-phy@7 in the WAX206 DTS brings up the 2.5GBit interface correctly:
compatible = "ethernet-phy-id001c.c849";
reg = <7>;
interrupts = <52 IRQ_TYPE_LEVEL_HIGH>;
reset-gpios = <&pio 101 GPIO_ACTIVE_LOW>;
reset-assert-us = <100000>;
reset-deassert-us = <100000>;
The reset-gpios of course already exist but GPIO_ACTIVE_LOW seems to be correct, not GPIO_ACTIVE_HIGH.
The limitation is that it's either working up to 1GBit speeds (including 10MBit and 100MBit) or 2.5GBit only. Depending of how you set the phy-mode for port 5 of the switch.
The difference between the two branches is just the lines 200 / 201 in target/linux/mediatek/dts/mt7622-netgear-wax206.dts
ethtool does correctly indicate the speed for the wan interface for all possible speeds. But tcpdump -ni wan shows only traffic in the above mentioned configurations.
For the 2.5GBit tests the WAX206 was connected to a QNAP QSW-M1204-4C and for the up-to-1GBit testing a MikroTik CSS610-8G-2S+ was used.
Excellent work!
Would that mean we would, in theory, require two images, depending on the speed of the WAN port ?
1000 | 2500
I think it maybe is a bit early to come to that conclusion; assuming that phy-mode = "2500base-x" working at 2.5G only is a software limitation. I don't know if 2500base-x is supposed to do auto-negotiation or not.
But if it can't be solved in time that may be an option.
Did you try autonegotiation with the original firmware? I'm not familar with programming kernel modules, but it looks like the patches, netgear uses in their sources, have some features, the drivers in openwrt 22.03 don't. I can't find any references to "hnat" in the openwrt implemantation of drivers/net/ethernet/mediatek. Maybe a closer look to those drivers would help?
Btw. I succesfully booted the recovery initramfs build from your tree. Please tell me, if there's anything to do to assist you.
Hi @Sailor, speed auto-negotiation does work with Netgears firmware, yes.
Unfortunately I'm not much of a programmer either. But the differences will be huge anyway since Netgears firmware uses swconfig for handling of the switch and now dsa is used. I'm sure there are developers here who know enough about it.
Looking for 2500base-x and sgmii in the 22.03 code it seems to confirm that 2500base-x doesn't do speed auto-negotiation and sgmii does do it but handles only speeds up to 1G. I haven't found too much information which is not behind a paywall (ieee.org). phy-mode = hsgmii would see the obvious choice for port@5 since the RTL8221B can handle that and it's designed for speeds up to 2.5G. But then I'm not sure if the MediaTek MT7531 can handle it, after all that's the port we're configuration phy-mode for.
But with phy-mode = hsgmii there's no network traffic in any mode.
dmesg the second line below should indicate which PHY mode is set and here it is set to phy/ instead of `phy/hsgmii'
[ 3.716915] mt7530 mdio-bus:00 wan (uninitialized): PHY [mdio-bus:07] driver [RTL8221B-VB-CG 2.5Gbps PHY] (irq=POLL)
[ 12.702102] mt7530 mdio-bus:00 wan: configuring for phy/ link mode
I'm not sure which developer to ask, maybe @daniel or @sumo ?
i had that working on another device but i'm back on openwrt dsa.
cake sqm will not work with that.
Definitely not an expert on this, but my impression is that the phy and mac can auto-negotiate the interface. So if the phy supports 10,100,1000,2500 and the mac supports sgmii and 2500base-x, then the phy selects 2500base-x if the peer wants 2.5G and sgmii otherwise.
See for example the docs at https://github.com/torvalds/linux/blob/master/include/linux/phylink.h#L184
I spent some time learning how the partition stuff works. I am sure this can be improved because I am a noob at openwrt. but I got a flashable .img with this
https://drive.google.com/file/d/1R6shPHR5VyWBvegiximoSn8A8hpabtmG/view?usp=share_link
index 431e514fb2..0902865570 100644
--- a/target/linux/mediatek/dts/mt7622-netgear-wax206.dts
+++ b/target/linux/mediatek/dts/mt7622-netgear-wax206.dts
@@ -457,44 +457,11 @@
};
};
- partition@300000 {
- label = "devinfo";
- reg = <0x300000 0x020000>;
+ partition@2c0000 {
+ label = "firmware";
+ reg = <0x2c0000 0x2600000>;
};
- partition@320000 {
- label = "senv";
- reg = <0x320000 0x020000>;
- };
-
- partition@360000 {
- label = "bootseq";
- reg = <0x360000 0x020000>;
- };
-
- partition@500000 {
- label = "firmware1";
- compatible = "denx,fit";
- openwrt,cmdline-match = "mtdparts=master";
- reg = <0x500000 0x1E00000>;
- };
-
- partition@2300000 {
- label = "firmware2";
- compatible = "denx,fit";
- openwrt,cmdline-match = "mtdparts=slave";
- reg = <0x2300000 0x1E00000>;
- };
-
- partition@4100000 {
- label = "data";
- reg = <0x4100000 0x1900000>;
- };
-
- partition@5100000 {
- label = "mfg";
- reg = <0x5a00000 0x1400000>;
- };
};
};
};
index e0d664aa73..9d311f9db2 100644
--- a/target/linux/mediatek/image/mt7622.mk
+++ b/target/linux/mediatek/image/mt7622.mk
@@ -238,14 +238,19 @@ define Device/netgear_wax206
BLOCKSIZE := 128k
PAGESIZE := 2048
UBOOTENV_IN_UBI := 1
+ NETGEAR_ENC_MODEL := WAX206
+ NETGEAR_ENC_REGION := US
KERNEL_IN_UBI := 1
- KERNEL := kernel-bin | gzip
+ KERNEL_SIZE := 6144k
+ IMAGE_SIZE := 32768k
+ KERNEL := kernel-bin | lzma | fit lzma $$(KDIR)/image-$$(firstword $$(DEVICE_DTS)).dtb
# recovery can also be used with stock firmware web-ui, hence the padding...
KERNEL_INITRAMFS := kernel-bin | lzma | \
fit lzma $$(KDIR)/image-$$(firstword $$(DEVICE_DTS)).dtb with-initrd | pad-to 128k
KERNEL_INITRAMFS_SUFFIX := -recovery.itb
- IMAGES := sysupgrade.itb
IMAGE/sysupgrade.itb := append-kernel | fit gzip $$(KDIR)/image-$$(firstword $$(DEVICE_DTS)).dtb external-static-with-rootfs | append-metadata
+ IMAGES += factory.img
+ IMAGE/factory.img := append-kernel | append-rootfs | append-ubi | check-size | netgear-encrypted-factory
endef
TARGET_DEVICES += netgear_wax206
Good work, flashable how?
Serial, webui, tftp?
web ui 10char
Random name, as long as it's 10 chars?
I'm traveling, won't have wax206 access for another couple of days.
Will boot my old initramfs 1st, and make a backup of the current flash
Bough a MF286D, I need to flash.
just trying to hit the 10 character minimum for a post lol
I'm sure I broke conventions I just wanted to get it going
I flashed it both with the stock firmware web ui "firmware update" function and with nmrpflash
fwiw, nmrpflash lets you flash an unencrypted image which is nice for debugging
Sound great!
Am I right in assuming that the image gets flashed to the partition with the label 'firmware' ('Kernel' in the stock device tree)? Have you tried to flash stock back?
After verifying my flash backups I'll give it a got tomorrow or maybe Friday.
Forgot to ask, is this image for 1gbit WAN port, or will it go up to 2.5.
yeah firmware partition gets flashed. flashing back to stock with nmrpflash works but I don't think flashing it via the luci webui will work because the fw files are encrypted. I think you would have to decrypt them and flash that.
also I didn't pull in any of the 1gb/2.5gb changes yet. I may screw around with that next since it looks like the interfaces arent being detected right in my image. I need to get VLAN working