Netgear WAX220 support (almost complete)

Hi,

I'm trying to bring the Netgear WAX220 to openWRT. There is a small issue though: The link status of the single ethernet port is not properly shown in openWRT. That is also the case for the stock firmware though, when I unplug the cable on the stock firmware I see

SSK_processApupLinkChange():109:36.947:apmode uplinkPort=-1 port=6[eth1] down.

though, so it seems like something in userspace is fetching the status somehow?

The part of the DTS looks like this:

&eth {
        status = "okay";

        gmac0: mac@1 {
                compatible = "mediatek,eth-mac";
                reg = <1>;
                phy-mode = "2500base-x";

                fixed-link {
                        speed = <2500>;
                        full-duplex;
                        pause;
                };
        };

        mdio: mdio-bus {
                #address-cells = <1>;
                #size-cells = <0>;
        };
};

If I remove the fixed-link there I see

mtk_soc_eth 15100000.ethernet eth0: mtk_open: could not attach PHY: -19

during boot. Even if I copy this part from the manufacturers GPL file it doesnt properly show the link status:

&mdio {
        #address-cells = <1>;
        #size-cells = <0>;

        switch@0 {
                compatible = "mediatek,mt7531";
                reg = <31>;
                reset-gpios = <&pio 5 0>;

                ports {
                        #address-cells = <1>;
                        #size-cells = <0>;

                        port@0 {
                                reg = <0>;
                                label = "lan0";
                        };

                        port@1 {
                                reg = <1>;
                                label = "lan1";
                        };

                        port@2 {
                                reg = <2>;
                                label = "lan2";
                        };

                        port@3 {
                                reg = <3>;
                                label = "lan3";
                        };

                        port@6 {
                                reg = <6>;
                                label = "cpu";
                                ethernet = <&gmac0>;
                                phy-mode = "2500base-x";
                                fixed-link {
                                        speed = <2500>;
                                        full-duplex;
                                        pause;
                                };
                        };
                };

        };

        phy@5 {
                reset-gpios = <&pio 0x6 0x1>;
                phy-mode = "2500base-x";
                reset-deassert-us = <0x4e20>;
                reg = <0x5>;
                compatible = "ethernet-phy-id67c9.de0a";
        };


        phy@6 {
                phy-mode = "2500base-x";
                reg = <0x6>;
                compatible = "ethernet-phy-id67c9.de0a";
        };
};

Oddly enough, openWRT says 2.5 Gbit/s even though I connected the device to a 1 Gbit/s port, so either the information in openWRT is not correct or there is something else performing the "conversion" between 2.5 Gbit/s and whatever I connect to the Ethernet port.

Does anybody have a clue how I could get the status shown properly? When I throw the ssk binary that emits the message in the vendor openWRT I see something like this:

Gpio = dai_sysGetGpio("ETH_INTERRUPT");
  dai_sysGetEthLinkChange(Gpio, &v2);
  if ( !v2 )
  {
    dai_readEthInterrupt();
    sub_31B0(6LL);
  }

so there is an interrupt and apparently it is processed in userspace. Gpio is 457 in this case and that is then simply read out from /sys/class/gpio457/value and if I kill the ssk process I can indeed watch the change there when (un)plugging the cable. I can also get the current state by running this command

mii_mgr_cl45 -g -p 6 -d 0x1f -r 0xa434

they even provide help for that command

mii_mgr -g -i [ifname] -p [phy number] -r [register number]
  Get: mii_mgr -g -p 3 -r 4

mii_mgr -s -p [phy number] -r [register number] -v [0xvalue]
  Set: mii_mgr -s -p 4 -r 1 -v 0xff11
#NOTE: Without -i , eth0 is default ifname!
----------------------------------------------------------------------------------------
Get: mii_mgr_cl45 -g -p [port number] -d [dev number] -r [register number]
Example: mii_mgr_cl45 -g -p 3 -d 0x5 -r 0x4

Set: mii_mgr_cl45 -s -p [port number] -d [dev number] -r [register number] -v [value]
Example: mii_mgr_cl45 -s -p 4 -d 0x6 -r 0x1 -v 0xff11

so I assume that I need to somehow add those parameters to my FDT?

As a side question: Is gmac0 for mac@1 correct or should I name it gmac1 in this case?

1 Like

Hi,

I'm no developer, so I can't help you directly, but this sounds like an interesting device for OpenWrt, so I'm trying to help anyways, if only by pushing this thread up again.

The questions you have seem to be non-critial for general usage, so why don't you just create a pull request at github? Maybe the maintainers can help you more directly there? Speaking about pull requests: There is currently a pending PR for the Netgear WAX218, see here: https://github.com/openwrt/openwrt/pull/11959 This has also 2.5GBASE-T ethernet, so maybe you can compare your implementation with it? Is the WAX220 also based on ipq807x?

Also: Do you have test builds?

It is kind-of critical as the LAN status isn't properly shown, the current way to make it work is just a broken workaround. This unit is based on a Mediatek CPU, so no ipq807x. What's similar is the way they do it in MTK830 + RTL8221B-VB-CG 2.5G question, but that's not really working either on this device.

It will be figured out eventually why this doesn't work properly and what needs to be done to the phy so it's properly forwarding data.

I just spent some more time trying to figure out what's wrong and finally know what's happening: Neither the registers for auto-negotiation are set nor the register to specify the SERDES speed. So basically the driver is broken/incomplete/whatever. Setting that stuff causes everything to just magically work.

@daniel I believe you are working a lot with the RTL822x drivers, I had a look at your work from https://git.openwrt.org/?p=openwrt/openwrt.git;a=blob;f=target/linux/realtek/files-5.4/drivers/net/phy/rtl83xx-phy.c;h=3e187228a9a37ae3979bc998234a86403a5bf94c;hb=HEAD and needed to set the registers in the Phy like that (just that my phy is attached directly without a switch). Any idea why that is not happening automatically?

What I need to do after a reboot is this:

mdio mdio-bus mmd 6:7 raw 16 0x1de1
mdio mdio-bus mmd 6:0x1f raw 0xa412 0x0200
mdio mdio-bus mmd 6:30 raw 0x697a 0x2
# Redo Auto-Neg
mdio mdio-bus mmd 6:7 raw 16 0x3200

It enables 10/100Mbit/s Auto-Neg, 1 Gbit/s Auto-Neg, sets the SERDES to 2500base-x and then redoes auto-negotiation.

1 Like

Sadly I don't have any device with RTL822x PHY, but I've been working on other devices with MaxLinear GPY211 PHY which is similar in this regard.
The thing here is: of course, we can do like the vendor firmware and just set the PHY in rate-adapting mode to always operate in 2500Base-X mode.
However, this is a waste of (not so little!) amount of energy. If the twisted-pair side of the PHY is operating with 1000MBit/s or less, we should just use SGMII and thereby significantly reduce the consumption of both, the PHY and the SoC. For the combination of MT7981+GPY211 I've been working with I measured the difference, and it's almost 25% increase of total intake of the system, just because we needlessly keep SerDes in 2500Base-X.
The Linux kernel hence seeks to use the lowest sufficient SerDes clock to support the datarate of the twisted pair side. This doesn't yet work well with Linux 5.15, but getting better with Linux 6.1, and patches are on the way to also adjust inband-autonegotiation depending on the capabilties of MAC and PHY for each interface mode.

I just did additional tests and could not confirm the increased power consumption. However, I tried yet again to use the slower speeds by setting the MAC to sgmii in specifying phy-mode = "sgmii"; but then I don't get traffic flowing, no matter which of the SerDes settings I choose (so it seem's like it's not running on 2500base-x and not on sgmii, or something else is wrong). Is there any way I can confirm if the MAC is still set to sgmii?

I also tried to pull in the patch from https://github.com/openwrt/openwrt/blob/7ba23c045fe8cb85a7a8e1f57bc4d198735a85fb/target/linux/generic/pending-5.15/722-net-phy-realtek-support-switching-between-SGMII-and-.patch but that didn't make a difference. I am still puzzled why the autonegotiation registers are not set properly though. For now it would even be sufficient for me to make this unit work with 1Gbit/s (and I would submit a PR with that) without writing to registers manually.

Hey Flole,

are you still working on OpenWRT for this device? It still sounds like an interesting and capable access point, I'd love to see OpenWRT-support for it.

I've recently worked (remotely) on this device, it should now work fine, incl. all supported speeds on the WAN port (2500M/1000M/100M/10M).

Is that published somewhere?

Yes, it's already part of the developing branch in OpenWrt, and daily snapshot images contain the relevant changes.

So if I rebase onto latest master it should just work?

Do I need to specify any fixed-link settings like in the opening post or how should I attempt to configure the DTS?

Yes.

Do not configure fixed-link, but just do phy-mode = "2500base-x"; with phy-handle point to the PHY in MDIO bus but without fixed link.

Thanks! That works. Although I am getting "flow control off" and "Unknown" instead of "full duplex", so it looks like this:

mtk_soc_eth 15100000.ethernet eth0: Link is Up - 1Gbps/Unknown - flow control off

and

# ethtool eth0
Settings for eth0:
        Supported ports: [ TP    MII ]
        Supported link modes:   10baseT/Half 10baseT/Full
                                100baseT/Half 100baseT/Full
                                1000baseT/Full
        Supported pause frame use: Symmetric Receive-only
        Supports auto-negotiation: Yes
        Supported FEC modes: Not reported
        Advertised link modes:  Not reported
        Advertised pause frame use: Symmetric Receive-only
        Advertised auto-negotiation: Yes
        Advertised FEC modes: Not reported
        Link partner advertised link modes:  10baseT/Half 10baseT/Full
                                             100baseT/Half 100baseT/Full
                                             1000baseT/Full
        Link partner advertised pause frame use: Symmetric Receive-only
        Link partner advertised auto-negotiation: Yes
        Link partner advertised FEC modes: Not reported
        Speed: 1000Mb/s
        Duplex: Unknown! (255)
        Auto-negotiation: on
        master-slave cfg: preferred slave
        master-slave status: slave
        Port: Twisted Pair
        PHYAD: 6
        Transceiver: external
        MDI-X: Unknown
        Current message level: 0x000000ff (255)
                               drv probe link timer ifdown ifup rx_err tx_err
        Link detected: yes

Is that expected?

At this point yes, after my (remote) experience with RTL822x this is expected. Unfortunately the current kernel driver (drivers/net/phy/realtek.c) is very buggy when using with RealTek's 2.5G PHYs. One would need to introduce a dedicated .read_status and .config_aneg function rather than using the generic functions which are made for other (older) RealTek PHYs...

Alright, thanks!

And with that I can say, that this unit is now working. It wasn't as bad as I initially thought, so now I just need to get a PR open and get it merged.

Any update on this device @Flole? The pull-request over at github didn't see an update for a month so I'm asking here.

1 Like

FWIW, after the great work from @Flole an updated PR with a few changes brought it to the finish line: WAX220 support is now in master.

I've also opened a PR to back-port the device support to 23.05, but from what I understand device backport is not something which is guaranteed to be accepted. We'll see :crossed_fingers:

1 Like

It is in the list of 23.05rc2.

2 Likes

And maybe I've missed it but what is the procedure to have OpenWrt installed on a WAX220?

It should be described in the commit that added support for it, aswell as in the PR.

1 Like