I see there is a Yocto recipe providing mdio-tools using the Github project you linked: OpenEmbedded Layer Index - mdio-tools
We’ll see if we have time to do some experiments on our side. Though I don’t believe we’re quite familiar with this tool, and manipulating the KSZ9131 registers like this. We’ll let you know if something comes up, please also keep us up to date on any findings from your side.
Best Regards,
Jeremias
Thanks Jeremias. @RoccoBr and I discussed it earlier and we think it may actually be easier to use the Microchip mdio-tool.c which compiles into a command line application. Then we don’t need to add a kernel driver. Rocco will give it a try tomorrow.
hi @jeremias.tx I took the mdio-tool from this Microchip repo and compile it with the sdk generated from yocto.
The tool seems to work, I can read the PHY registers:
torizon@CB20300132:~$ sudo ./mdio-tool r ethernet0 0x01 7
0x796d
torizon@CB20300132:~$ sudo ./mdio-tool r ethernet0 0x00 7
0x1140
torizon@CB20300132:~$ sudo ./mdio-tool r ethernet0 0x02 7
0x0022
torizon@CB20300132:~$ sudo ./mdio-tool r ethernet0 0x03 7
0x1642
torizon@CB20300132:~$ sudo ./mdio-tool r ethernet0 0x04 7
0x05e1
I will try now to configure the link-up detection for WOL, following this sequence
That’s promising news. Please keep us updated on your findings and tests with this tool.
Best Regards,
Jeremias
hi @jeremias.tx
I’m trying to configure the WOL register as above, but I have noticed that when I put the system to sleep the mdio settings are lost.
#set WOL
torizon@CB20300132:~$ sudo ./mdio-tool w ethernet0 0x0D 7 0x2
torizon@CB20300132:~$ sudo ./mdio-tool w ethernet0 0x0e 7 0x10
torizon@CB20300132:~$ sudo ./mdio-tool w ethernet0 0x0D 7 0x4002
torizon@CB20300132:~$ sudo ./mdio-tool w ethernet0 0x0e 7 0x8001
# WOL is enabled
torizon@CB20300132:~$ sudo ./mdio-tool w ethernet0 0x0D 7 0x2
torizon@CB20300132:~$ sudo ./mdio-tool w ethernet0 0x0e 7 0x10
torizon@CB20300132:~$ sudo ./mdio-tool w ethernet0 0x0D 7 0x4002
torizon@CB20300132:~$ sudo ./mdio-tool r ethernet0 0x0e 7
0x8001
#go to sleep for 2 minutes
torizon@CB20300132:~$ sudo rtcwake -m mem -d rtc1 -s120
rtcwake: assuming RTC uses UTC ...
rtcwake: wakeup from "mem" using rtc1 at Thu Jan 1 00:46:19 1970
#when wakes up check if WOL is still enabled
torizon@CB20300132:~$ sudo ./mdio-tool w ethernet0 0x0D 7 0x2
torizon@CB20300132:~$ sudo ./mdio-tool w ethernet0 0x0e 7 0x10
torizon@CB20300132:~$ sudo ./mdio-tool w ethernet0 0x0D 7 0x4002
torizon@CB20300132:~$ sudo ./mdio-tool r ethernet0 0x0e 7
0x0000
this seems to me like the PHY is power cycled.
can you confirm that? is there a way to keep PHY powered up?
Regards,
Rocco
this seems to me like the PHY is power cycled.
can you confirm that? is there a way to keep PHY powered up?
I did some digging here and I believe your intuition is correct. The FEC driver from NXP turns off power to the Ethernet PHY when in suspend/sleep: fec_main.c « freescale « ethernet « net « drivers - linux-toradex.git - Linux kernel for Apalis, Colibri and Verdin modules
That part seems out of our control, outside of modifying the driver. However, I did find something promising. In our BSP 6.X this behavior was causing a kernel crash for us, so we circumvented the behavior with the following change in the device tree: linux-toradex.git - Linux kernel for Apalis, Colibri and Verdin modules
In theory this keeps the power regulator for the PHY on, despite the attempt from the FEC driver to turn it off during suspend. If this works like I think it does then perhaps this would help your situation here.
Best Regards,
Jeremias
hi @jeremias.tx
the regulator change in the device tree allows the PHY to be powered al the time, I can see the registers values are retained after sleep, thanks for the help
I still can’t make the device to wake up on link up, I’ll keep investigating
Regards,
Rocco
the regulator change in the device tree allows the PHY to be powered al the time, I can see the registers values are retained after sleep, thanks for the help
Perfect! Glad to hear it was just a simple device tree change.
I still can’t make the device to wake up on link up, I’ll keep investigating
Keep us updated. Not sure how much expertise we can provide regarding the features of this PHY chip.
Best Regards,
Jeremias
hi @jeremias.tx ,
as you mentioned the PHY generates an interrupt on pin GPIO1_IO10. who is managing the interrupt? the fec driver? where I can find the source code of the interrupt handler?
looking at the source code of the fec driver , I can see that the wol register is explicitly masked for MAGIC_PACKETS, I wonder if the same happens on the interrupt handler, responding only to magic_packet events and ignoring all the others
Regards,
Rocco
as you mentioned the PHY generates an interrupt on pin GPIO1_IO10. who is managing the interrupt? the fec driver? where I can find the source code of the interrupt handler?
I assumed the interrupts was purely for the sake of the PHY driver: micrel.c « phy « net « drivers - linux-toradex.git - Linux kernel for Apalis, Colibri and Verdin modules
Though on closer inspection I can see that in the device tree the pinctrl group for fec1 uses GPIO1_IO10 as well: imx8mm-verdin.dtsi « freescale « dts « boot « arm64 « arch - linux-toradex.git - Linux kernel for Apalis, Colibri and Verdin modules
I would assume then that fec1 has knowledge/visibility of this pin as well. How it makes use of this shared pin software-wise, is not clear to me. Perhaps so it’s just fec and phy have the same interrupt source in order to have synchronized interrupts.
As for the actual interrupt handler I think it’s just here in the generic phy.c source code: phy.c « phy « net « drivers - linux-toradex.git - Linux kernel for Apalis, Colibri and Verdin modules
I can see that the wol register is explicitly masked for MAGIC_PACKETS, I wonder if the same happens on the interrupt handler, responding only to magic_packet events and ignoring all the others
This could be a possibility. NXP typically prevents/blocks behavior that is not supported by them.
Best Regards,
Jeremias
Hello,
I am trying to make wake-on-lan work on my imx8mp. I know that the SoM has two ethernet controllers. I am using the eqos controller with the on-module PHY.
At the beginning @bw908 said that successfully woke up from sleep mode. Could you please specify in details how did you do that?
I edited the device tree by adding fsl,magic-packet; to the eqos node and enabled the magic packet mode in the os with ethtool -s eth0 wol g. However I am still not getting the device to wake up.
I also checked the power configuration of PHY used by the eqos controller and it already has the regulator-always-on; property to not cut off power during sleep mode. I add that while in sleep mode the status leds of the ethernet port on the device keep blinking.
Is it really an issue of the registers of the KSZ9131RNX ethernet transceiver not been set out to manage magic packet detection? How did @bw908 make wake up form sleep mode then?
Has anyone else made some progress on the wake-on-lan of the on-module PHY of imx8mp?
Best regards,
Loris
You’re doing exactly what worked for us at the time. The only difference I observe is that in our case the device name (for Torizon) is ethernet0 instead of eth0.
However, we haven’t really put this into any active use in our project yet so it’s entirely possible something has broken or changed in the OS since this was tested - indeed this appears to be the case as I just re-tested and my experience is the same as yours:
systemctl suspendfsl,magic-packet in our devicetree.I do not think we’ve touched it since the initial proof-of-concept which would have been on Torizon 5.7.
Hi @loris.teq,
If this is a vital requirement for you, I would recommend opening a new thread about this. This thread mostly discusses our quite old 5.X OS software which is no longer maintained anymore. When opening this new thread please make sure to detail what OS and version you are trying to test this on.
As a side-note wake-on-lan is not something we regularly test, or even see many of our customers make use of. So it is quite possible something may have changed, or broke with this functionality in later versions of the OS.
Best Regards,
Jeremias
Hi @loris.teq, we have not followed up recently either as working on other things. We did get magic packet to work on 5.x have not tried on 6+. Are you using a tool to send the magic packet with the correct MAC address? I can’t remember what we used but I can dig it out if you want.
Hi @bw908 !
As @jeremias.tx said, it is indeed better to create a new topic (where you can reference this one for context, if you want).
But, for future reference, here is an internal documentation I created a while ago when testing Wake-On-Lan on Verdin iMX8MP and Reference Minimal Image from BSP 6:
Wake-On-Lan_+quick+test+on+Verdin+iMX8M+Plus-BSP6.pdf (228.8 KB)
I hope it is helpful.
If it is not, we will be waiting on your new topic 
Best regards,
Just noting that your document does outline what I tried (without success) several times on our module on Torizon 6. But as we currently have no need for this I’m not actively trying to get it working again, I mostly just ran a quick test for that other user that was having issues.
I’ll definitely be interested to follow their new thread though.
In my previous answer wanted to tag @loris.teq, instead. I’m sorry @bw908! 
Hi,
thank you all for answering.
I followed the steps in the documents but it is still not working.
I also tried to directly manage PHY registers but the result is still the same.
I was investigating WoL possibility for future projects. If we will decide to go for it I will open a new discussion as suggested.
Best regards,
Loris
Hi @henrique.tx, if you do more work on this could you also look at wake up without the magic packet. This is what we need for our application with embedded devices. We want cable connection to be the trigger. It is possible with the hardware but does not seem to be available in the current configuration.
Thanks
Ed
Hi @loris.teq and @edwaugh !
I will try it again on newer TorizonOS/BSP for sure.
But I will need to do it after Embedded World 2025 (next week).
I hope it is ok for you.
Thanks for the comprehension
Best regards,