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.
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.
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.
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.
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)?
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.