Looking for support of TP-Link EAP225 v4


I have tested the flashing procedure as described in this commit.
It worked as expected.

The PHY worked after a power cycle.
What's disappointing is that the PHY refused to work after a reboot.
What I have noted was the following line before connecting to the phy via MDIO.

[    6.767593] ag71xx: max retries for SGMII fixup exceeded

[    7.493274] mdio_bus mdio.0: MDIO device at address 4 is missing.
[    7.532477] ag71xx 19000000.eth: connected to PHY at mdio.0:06 [uid=001cc916, driver=RTL8211F Gigabit Ethernet]

The SGMII fixup retry takes nearly 6.5s instead of 1s. As I learned from the corresponding code, this fixup tries to reset the PHY, which does not work.

What I have tried so far

  • Removing reset-gpios from PHY@6.
  • Removing qca956x-serdes-fixup;
  • Combination of both
  • I tried with a 1 GBit Connection

In the datasheet of the PHY (RTL8211FS) there is a software reset possibility shown in Register 0.15 .
But I don't know if the soft reset would work in this state.

I looked a little more into the PHY's reset hardware.
When comparing the PCB between EAP225 v3 and v4, there is clearly visible, that GPIO 11 is missing in v4.

Pinout of the SoC

Picture of the SoC in EAP225 v4. GPIO11 is the pad in the centerline of the 3 at the white silkscreen marking C370.
There is no outgoing trace visible.

Picture of the SoC in EAP225 v3 from FCC (Page 7). GPIO 11 has an outgoing trace.


What I think would be possible:

Using the Supervisor Circuit to reset the PHY as well on a reboot.

The PHY's Reset Pullup is connected to the RESET output of the Supervisor Circuit PT7A7514W. The reset will be pulled down for 200ms in case, the voltage drops below an threshold, or the Watchdog input is triggered. This Input can be triggered by the SoC using GPIO 3 & 4 which are probably connected to a tri-state buffer in front of the Watchdog input. The GPIO 3 & 4 are described in target/linux/ath79/dts/qca956x.dtsi.

GPIO3 - R293 - tri-state buffer - PT7A7514W
GPIO4 - R292 - (tri-state buffer) - R288 - VCC (pullup)

My knowledge on the device tree is somewhat limited, so I don't know if this reset behavior is already happening or possible.

1 Like

Interesting! I haven't seen such a supervisor chip on my EAP245v1v/3 devices, maybe I should give those another look. What pin on the PT7A7514 does GPIO3 connect to? Is the WDI pin of that supervisor also connected to something, or is it left floating?

Edit: assuming GPIO3 is connected to /MR on the supervisor, you should be able to use reset-gpios = <&gpio 3 GPIO_ACTIVE_LOW> on the phy.

This is neat; when I set gpio4 low, the EAP245 v1 reboots! As I traced out, gpio4 connects to /OE of an SN74LVC1G125 tri-state buffer (U28). gpio3 connects to the A input of the buffer, while the Y output connects to the /WDI signal of the PT7A7514 (U29). So I guess that's part of the design that hasn't changed yet.

The SN74LVC1G125 seems to match for U28. I couldn't find the chip marking before at the Internet.
When pulling the /OE low, the GPIO3 gets passed through the buffer to WDI Input. If GPIO3 does not output a rect wave signal, the PT7A7514 will reset after 1,6s.

For me it sounds like the Watchdog circuit in the SoC is not enabled, but described in the device tree.

I will try pulling GPIO4 low to check if the PHY will work after a reboot. But have to wait till beginning of next week for the test.
Is there a possibility to reset the SoC using the GPIO4 (+ disabled Watchdog) instead of the regular software reboot?

GPIO3 and GPIO4 are not currently described in the devicetree for the EAP devices. The SoC does have a WDT built in already, so OpenWrt currently uses that one.

GPIO3 could be used for a linux,wdt-gpio node, while providing a gpio-hog for GPIO4 to always enable the buffer. The design is a bit annoying, since the gpio_wdt driver would actually change the assigned line to a (high impedance) input to disable the WDT. With the buffer this is split over two separate lines, which the driver can't use without any modifications.

The gpio_wdt driver also does not provide a restart handler, so it cannot be used to reboot the system.

When GPIO3&4 are not used for the watchdog, GPIO4 could be used for rebooting the system.

I have tested GPIO4 to trigger PT7A7514 for getting the PHY to work again. In my tests, this worked reliably(*).

echo "4" > /sys/class/gpio/export
echo "out" > /sys/class/gpio/gpio4/direction
echo "0" > /sys/class/gpio/gpio4/value
 - waiting for 1.6s.

My thoughts:

  • Could the GPIO4 be pulled low while rebooting?
  • When the (SoC-) internal watchdog reboots the controller, the PHY will not work and needs an additional reboot. I guess this is not an expected behavior.

* Tested it 10 times.

You could use gpio-restart with a timeout of 1600 ms (or a bit more, might require a kernel module or extra CONFIG_ option). If you set the priority high enough, this would be used as the default reboot method.

Although I agree that it is not nice that the phy doesn't work after a warm boot, it's a bit of a hack though. :confused:

Do you have any idea of how stock FW can reboot properly? I saw TP-Link has uploaded a GPL archive for this device, perhaps that can give us some clues.

EAP225-Outdoor v3 support is now merged with 7e4de89e631a. This device won't be very different. Aside from the board name it's pretty much identical.

The watchdog on GPIO3/GPIO4 can always be added at a later point. The same hardware is at least also present on the EAP245v1, so perhaps this is also something all (single port) devices in this series have in common.

I did some tests using gpio-restart. They worked as expected for a regular reboot. This is a hack which covers not all cases.
This is the patch for rebooting.

diff --git a/target/linux/ath79/config-5.10 b/target/linux/ath79/config-5.10
index 75e282b..f8b9dc7 100644
--- a/target/linux/ath79/config-5.10
+++ b/target/linux/ath79/config-5.10
@@ -161,6 +159,8 @@ CONFIG_PHYLIB=y
 # CONFIG_PHY_AR7200_USB is not set
 # CONFIG_PHY_ATH79_USB is not set
diff --git a/target/linux/ath79/dts/qca9563_tplink_eap225-v4.dts b/target/linux/ath79/dts/qca9563_tplink_eap225-v4.dts
index 73de898..7e677a9 100644
--- a/target/linux/ath79/dts/qca9563_tplink_eap225-v4.dts
+++ b/target/linux/ath79/dts/qca9563_tplink_eap225-v4.dts
@@ -27,6 +27,15 @@
 			gpios = <&gpio 9 GPIO_ACTIVE_HIGH>;
+	gpio-restart {
+		compatible = "gpio-restart";
+		gpios = <&gpio 4 GPIO_ACTIVE_LOW>;
+		priority = <254>;
+		active-delay = <100>;
+		inactive-delay = <100>;
+		wait-delay = <1800>;
+	};
 &eth0 {
diff --git a/target/linux/ath79/dts/qca9563_tplink_eap2x5-1port.dtsi b/target/linux/ath79/dts/qca9563_tplink_eap2x5-1port.dtsi
index 127741f..bbdfb01 100644
--- a/target/linux/ath79/dts/qca9563_tplink_eap2x5-1port.dtsi
+++ b/target/linux/ath79/dts/qca9563_tplink_eap2x5-1port.dtsi
@@ -108,7 +108,7 @@
 	phy6: ethernet-phy@6 {
 		reg = <6>;
-		reset-gpios = <&gpio 11 GPIO_ACTIVE_LOW>;

I had a look at TPLink's gpl code:

TPLink is using linux kernel 3.38.

  • linux/kernels/linux-3.3.8/drivers/net/ethernet/atheros/ag71xx/ag71xx_phy.c
    • In function ag71xx_phy_connect(struct ag71xx *ag) there is an explicit mdio bus reset which is not visible in the openwrt source.
  • linux/kernels/linux-3.3.8/drivers/net/phy/rtl8211.c
    • In rtl8211_config_init(struct phy_device *pdev) there is an explicit software reset (Bit 15) on init.
    • The phy is described in the openwrt source in drivers/net/phy/realtek.c
    • In rtl8211f_config_init(struct phy_device *phydev) (openwrt source) there is no reset and instead the delay configuration.

Various interesting files:


Thanks for investigating! In 5.15 this soft reset is also performed by the mainline driver (used by OpenWrt). 5.10 doesn't have this reset yet.

Now, this all occurs when initialising the phy on boot, not when shutting it down on shutdown or restart. If the ethernet port already works on both boot and reboot, I don't expect this soft reset to help make it work in u-boot after a reboot. Unless they've updated the bootloader, these devices don't have emergency TFTP loading support anyway, and you basically need to be next to the device to have serial access.

If you would like to add full reboot support using GPIO4, that's also fine for me. Just make sure you describe GPIO3, GPIO4, and the associated hardware in the commit message.

I still have problem with the latest Snapshot image (Aug 10) in terms of EAP 225 v3 Outdoor (same as EAP225 v4).

  • Successfully flashed with 'cliclientd stopcs` workaroung from stock GUI
  • First boot is ok...I am able to connect via SSH, but when I set the root passwd and soft reboot from command line after that I am unable to reach the device
  • Only cold restart (remove the POE power chord) helps!
    Do you already have a fix to resolve this issue? Does anyone have a compiled working image for EAP 222 v3 outdoor (should be the same as EAP225 v4)?
1 Like

Does this device use dsa to 100%?
Swconfig is included in the build but it doesn’t seem to use it in the network config and it still works?

Hi Guys! Any update on this? Can we expect some fix in next releases?

Hello, is EAP 225 v4 supported in 22.03? If not, does anyone know why and when it will be added? Thanks!

Due to the need of a lot of backporting, EAP225v4 and EAP225 Outdoor v3 will be supported with the 23.xx release. You can currently use the snapshots.
See the EAP225 Outdoor v3 - thread for a more detailed explanation.

Do any of you experience something similar to a memory leak for the 5GHz or something?
It has happened two times now after I installed OpenWrt on the 225v4. It runs at full speed at 5GHz about a week and then boom it gets very unstable speed if any speed at all with full connection. And after a power cycle it works again with full speed?
I have tried disabled the ACK setting that where supposed to make iOS work better so I thought I had found the problem last week but it’s back.

But I don’t know if it is something with the Ath10-ct driver because it wasn’t included when I build the firmware?

You might try this

although TP-link EAP225 V4 has 128Mb ....

To be hounest I for this time got tired of Linux and wifi drivers and bought a wifi6 AP instead I simply run it on original firmware.