Imx8mp wake-on-lan

Technical Support
, ,
1

What is the status/capability of wake-on-lan in the imx8mp verdin modules for the onboard PHY?

I have seen a few references here with regards to the Apalis platform but those seem to be out of date. I did already experiment with adding fsl,magic-packet to the eqos devicetree node but the material I found suggests it must also be enabled os-side via ethtool, which no longer seems to be part of the torizon distribution.

Specifically, I have the following questions:

  • What states can WoL wake a verdin from, if any? (sleep, poweroff?)
  • Is there documentation on what’s needed to enable this support for the imx8?

Thanks!

2

Greetings @bw908,

Before we try and answer your questions, in case it matters what versions of TorizonCore are you working with here?

Best Regards,
Jeremias

3

Currently using 5.7.0.

4

I checked around for this internally and it doesn’t seem we have much in the way of documentation for wake-on-lan functionality. I found this on the NXP forums: Solved: i.MX8M Mini wake on lan - NXP Community

It’s for the i.MX8M Mini which is similar to the i.MX8M Plus. That said I couldn’t find anything more detailed or specific here. That said you are correct that ethtool is not in our OS images by default, it seems the image would need to be re-built to include this.

What states can WoL wake a verdin from, if any? (sleep, poweroff?)

Is there a specific use-case you’re looking at using here?

Best Regards,
Jeremias

5

Thanks for the reply - I’m just curious what capabilities are available for the purposes of developing a PoE powered device and what options we have for putting the device in a low-power mode when idle.

We already have PoE control and can power cycle a device remotely via this to “wake” it from being off, but I was curious whether there were more responsive or other options available for cases where the device is powered via alternate means - whether it could be powered up or woken from a sleep state remotely for reduced wakeup times.

6

OK, I was able to get it to wake from sleep - I added both the devicetree modification, and using ethtool is required (otherwise the interface is put to sleep in suspend mode).

Now I am curious whether WoL is possible from a power-off state - obviously this must be supported by the SoM and carrier board in order to keep the ethernet interface sufficiently powered while “off”. Do you have any information on this from the SoM perspective?

7

Do you have any information on this from the SoM perspective?

I asked about this internally and, typically WoL is only meant to work from sleep states. Therefore the initial assumption here is that this wouldn’t quite work as a power button of sorts. Or at least it would need quite a bit more setup that we’re not sure about.

Is this functionality something you’d want for your system?

Best Regards,
Jeremias

8

It is something we would likely make good use of if it was available, yes - in some configurations we can control this by just power cycling the PoE power to bring up the device from “off”, but if the device is powered via alternate means and has been placed in soft-off then WoL would let us achieve the same functionality.

It can certainly be used to wake from an S5 sleep state on e.g. desktop computers, but obviously the embedded applications are somewhat different in terms of power consumption since in many cases the devices may be using a battery and I can understand it might be undesirable to keep the interface powered.

9

Again as far as we know using WoL as a way to turn on the board from a power-off state is not possible. At least not without some kind of other modifications on a custom carrier board. Though we’ve never had experience with anyone who’s tried using WoL for a similar purpose.

Best Regards,
Jeremias

10

Right, at this point I am just trying to understand the capability of the SoM and whether it is theoretically possible with (as noted) support on the carrier board.

If that is unknown, that’s fine since I agree it’s an esoteric use case.

11

Hi @bw908,
Can you share any more details of how you added ethtool and got the wake-on-lan working? We would like to replicate on our imx8mm. Did you have to modify the device-tree as well?
@RoccoBr
Thanks
Ed

12

Yes, I believe it requires both the devicetree modification as well as an ethtool call once the OS has booted to enable it.

We ended up just embedding ethtool via torizoncore-builder as a custom FS overlay in /usr/bin, and a systemd startup script to invoke the requisite parameters.

13

I have added ethtool via yocto and checked that the devicetree has the fsl,magic-packet enabled, but actually we would like to use Wake-on-phy. If I set ethtool -s eth0 wol p I get an error, the only options supported seem to be “g” (for the magic packet) and “d” (wake-on dchp requests)
@jeremias.tx do you know how do modify the devicetree in order to support Wake-on-phy? I can’t find anything on the nxp forum


Settings for ethernet0:
        Supported ports: [ TP MII ]
        Supported link modes:   10baseT/Half 10baseT/Full
                                100baseT/Half 100baseT/Full
                                1000baseT/Full
        Supported pause frame use: Symmetric
        Supports auto-negotiation: Yes
        Supported FEC modes: Not reported
        Advertised link modes:  10baseT/Half 10baseT/Full
                                100baseT/Half 100baseT/Full
                                1000baseT/Full
        Advertised pause frame use: Symmetric
        Advertised auto-negotiation: Yes
        Advertised FEC modes: Not reported
        Link partner advertised link modes:  10baseT/Half 10baseT/Full
                                             100baseT/Half 100baseT/Full
        Link partner advertised pause frame use: Symmetric
        Link partner advertised auto-negotiation: Yes
        Link partner advertised FEC modes: Not reported
        Speed: 100Mb/s
        Duplex: Full
        Port: MII
        PHYAD: 7
        Transceiver: internal
        Auto-negotiation: on
        Supports Wake-on: g
        Wake-on: d
        Link detected: yes
14

do you know how do modify the devicetree in order to support Wake-on-phy? I can’t find anything on the nxp forum

If I recall I don’t actually think you need any device tree changes since fsl,magic-packet enabled is already present. At least if you’re just doing a basic wake up with a magic packet. For other methods a device tree change might be required but we’ve only really experimented with the magic packet wake-up. To be clear this was on 6.X, I’m not sure if something was needed back on 5.X, perhaps @bw908 could clarify.

If I set ethtool -s eth0 wol p I get an error, the only options supported seem to be “g” (for the magic packet) and “d” (wake-on dchp requests)

This would be expected. I believe these are the only options the net driver from NXP supports properly.

Best Regards,
Jeremias

15

Hi @jeremias.tx,
So is there an IMX8 onboard ethernet transceiver that is used for the default channel? Not the Microchip KSZ9131 that is also fitted to the SOM? That part looks like it supports all the different modes and I would think a Microchip driver would have them.
Thanks
Ed

16

I had a look at the Verdin datasheet and it only shows the Microchip part on the diagram. Do you know what driver is installed to support it? Can we configure it from the device-tree maybe?

17

Well looking into this more and there’s a bit of an interesting story/history.

First of all there’s 2 parts here to consider. Looking at the node for Ethernet in the device tree here:

&fec1 {
	fsl,magic-packet;
	phy-handle = <&ethphy0>;
	phy-mode = "rgmii-id";
	phy-supply = <&reg_ethphy>;
	pinctrl-names = "default", "sleep";
	pinctrl-0 = <&pinctrl_fec1>;
	pinctrl-1 = <&pinctrl_fec1_sleep>;

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

		ethphy0: ethernet-phy@7 {
			compatible = "ethernet-phy-ieee802.3-c22";
			interrupt-parent = <&gpio1>;
			interrupts = <10 IRQ_TYPE_LEVEL_LOW>;
			micrel,led-mode = <0>;
			reg = <7>;
		};
	};
};

So looking here there are 2 nodes the main fec1 node that represents the fast ethernet controller (FEC) on the SoC. Then the ethphy0 node which represents the ethernet PHY on the SOM (KSZ9131) that is connected to the FEC.

Looking at the datasheet for the KSZ9131 it does say it can perform some Wake-on-lan actions. But despite this I don’t see the logic for this anywhere in the Linux driver for this PHY: micrel.c « phy « net « drivers - linux-toradex.git - Linux kernel for Apalis, Colibri and Verdin modules

In comparison look at the NXP driver for the FEC: fec_main.c « freescale « ethernet « net « drivers - linux-toradex.git - Linux kernel for Apalis, Colibri and Verdin modules

You can see logic for wakeup-on-lan. Now there is an article from Microchip on how to use wakeup-on-lan via the PHY: Microchip Lightning Support

But it involves manually setting registers and such. My suspicion is that while the PHY itself is technically capable of wakeup-on-lan. It would appear such functionality never made it’s way to the Linux driver itself.

Best Regards,
Jeremias

18

Hi @jeremias.tx,
Thanks for the excellent answer. I also saw in the micrel driver that the WOL registers were defined but none of the settings for them, which is strange, but as you say maybe never got added. I am surprised because this must be a very common part when used with Linux and you would think Microchip would go to the effort of making sure there was a full driver. Maybe I will try my contact there and see what they say.
Are you able to tell me if the PHY "power management event (PME) interrupt output pin " is connected on the SOM and if it is even able to wake the device from sleep if we could configure it to do so? Maybe this is more of a question for @matthias.tx.
Thanks
Ed

19

Are you able to tell me if the PHY "power management event (PME) interrupt output pin " is connected on the SOM and if it is even able to wake the device from sleep if we could configure it to do so?

This is just my rough interpretation so don’t quote me on this. On the SOM pin 38 of the KSZ9131 (INT_N/PME_N2/ALLPHYAD) is connected to ETH_INT on the SoC (GPIO1_IO10). So yes this interrupt pin from the PHY is connected to the SoC. Now what I’m not sure of is whether this would actually wake the device up from a sleep state assuming everything is properly asserted. I don’t believe anyone has tried this before on our system so I can’t be certain. This is all ignoring that the PHY driver doesn’t seem to provide the WOL functionality to begin with as we said.

Best Regards,
Jeremias

20

Hi @jeremias.tx,
I got a response from Microchip and they directed me to this tool that allows you to read/write registers on the PHY directly:
EVB-KSZ9897/KSZ/app_utils/mdio-tool/mdio-tool.c at master · Microchip-Ethernet/EVB-KSZ9897 (github.com)
However it also looks like there is a github project that has been recently updated with a more advanced version of it:
wkz/mdio-tools: Low-level debug tools for MDIO devices. (github.com)
We will try to get that working but if you have any time to try it would help us out a lot!
Thanks
Ed