ESP32 MDIO not working correctly when RMII clock is generated on GPIO17

[iwasz]

Dear community

A custom board that I have to program (not my design, can't modify it) consists of an ESP32-WROOM-32 and a LAN8720A Ethernet phy. Unfortunately the PHY has no crystal, but GPIO17 is used to provide 50MHz RMII clock from ESP32 MAC to the PHY. Recently a PR enabled this, but then my board always reported:

[00:00:02.447,000] <err> phy_mii: No PHY found at address 1
[00:00:02.458,000] <err> eth_esp32: PHY device not ready

This was because reading a MDIO register would now always return 0xffff... in phy_mii_initialize. I figured out, that for some reason my MDIO calls don't work until the RMII clock is enabled, which doesn't happen until eth is initialized (the order is mdio, then phy, then eth). Everything works fine when I initialize rmii clock in the mdio_esp32_initialize which boils down to adding the stuff from the PR I linked to the mdio_esp32_initialize.

I have no experience with MDIO and RMII so maybe I'm missing something obvious (like Kconfig option)?

[rftafas]

This PHY is RMII. The mode you mention is for MII.

From TRM, on RMII chapter:

The same reference clock must be provided externally both to the MAC and the external Ethernet PHY. It provides independent 2-bit-wide Tx and Rx data paths.

[iwasz]

Thanks

My understanding is that MDIO is a "management interface" of MII (or RMII which is a reduced signal count MII) as stated here. It's for sending / receiving control stuff, while the "true" MII path is for Ethernet frames. Correct?

So how shall I understand your statement that "The mode you mention is for MII.". Does it mean that I shouldn't generate the clock signal from ESP -> PHY chip? If I modify the Zephyr driver a little it starts to work, it's a matter to enable the clock earlier.

[rftafas]

That is correct, but all things on this PHY need a valid clock. Well, I checked and we eventually made it possible for the 'RMII' to output clock (actually, it is still still not from MAC RMII Ip block, but from internal PLL and is routed to both MAC and the PIN), so you are providing a good reference to the phy. Although, from what I understood from your last comment, you made a fix and it started to work. I advise submitting a PR about it.

[ductuanhoang]

Hi @rftafas
I ran with version 3.6.0 and version 3.6.99 but I still got the same issues when trying config GPIO16 of esp32 to RMII clock with ESP32-WROOM-32 and a LAN8720A Ethernet phy. I verified that my board works with the ESP32-IDF platform.

uart:~$ Hello World! esp32_ethernet_kit
[00:00:02.121,000] <err> phy_mii: No PHY found at address 1
[00:00:02.132,000] <err> eth_esp32: PHY device not ready
*** Booting Zephyr OS build v3.6.0-7-gcb43f99aba08 ***
uart:~$ 

my changed overlay board like this

&mdio {
	pinctrl-0 = <&mdio_default>;
	pinctrl-names = "default";
	status = "okay";
	
	phy: ethernet-phy@1 {
		compatible = "ethernet-phy";
		status = "okay";
		reg = <1>;
	};
};

&eth {
	status = "okay";
	phy-handle = <&phy>;
	ref-clk-output-gpios = <&gpio0 16 0>;
};

and project config:

CONFIG_SPIRAM_MODE_QUAD=n
CONFIG_ESP_SPIRAM=n

CONFIG_NETWORKING=y
CONFIG_NET_L2_ETHERNET=y
CONFIG_MDIO=y

CONFIG_NET_LOG=y
CONFIG_NET_SHELL=y

[ductuanhoang]

Hi, I have the same issues and am trying to find the solution, could you show me how to init RMII clock in the function "mdio_esp32_initialize"
Thank

[sylvioalves]

@iwasz Can you share your project .dts file? I guess you are missing setting the proper GPIO17 pin using ref-clk-output-gpios reference.

[sylvioalves]

You can try adding the following configs in your .dts file:

&eth {
	phy-handle = <&phy>;
	phy-connection-type = "rmii";
	ref-clk-output-gpios = <&gpio0 17 GPIO_ACTIVE_HIGH>;
};

[iwasz]

Hey guys my DTS is like this:

&mdio {
	pinctrl-0 = <&mdio_default>;
	pinctrl-names = "default";
	status = "okay";

	phy: phy@1 {
		compatible = "ethernet-phy";
		status = "okay";
		reg = <1>;
	};
};

&eth {
	phy-handle = <&phy>;
	status = "okay";
	ref-clk-output-gpios = <&gpio0 17 0>;
	phy-connection-type = "rmii";
};

But the issue is that MDIO wasn't properly initialized, and the clock signal wasn't generated at the point when driver was querying registers 2 and 3 (PHY Identifier 1 and PHY Identifier 2 registers). All I did was adding:

	emac_hal_init(&dev_data->hal, NULL, NULL, NULL);
	emac_hal_iomux_init_rmii();
	emac_hal_iomux_rmii_clk_output(/* ref_clk_gpio */17);
	emac_ll_clock_enable_rmii_output(dev_data->hal.ext_regs);
	rtc_clk_apll_enable(true, 0, 0, 6, 2);

to the mdio_esp32_initialize function in zephyr/drivers/mdio/mdio_esp32.c (version 3.6.99) - just before return. In other words i moved clock initialization earlier in the init process. I should have opened a PR for that :(

[sylvioalves]

https://github.com/zephyrproject-rtos/zephyr/blob/main/drivers/clock_control/clock_control_esp32.c#L405

Would you please change return -ELAREADY to return 0 instead? I think there was a regression on latest clock updates.

[sylvioalves]

@iwasz Let me know if this fix the issue in your side. I'll submit a PR to fix this.

[ductuanhoang]

Hi @iwasz could you give me the revision of zephyr in file "west.yml" when updating "hal_espressif"? Also my revision is

    - name: hal_espressif
      revision: 67fa60bdffca7ba8ed199aecfaa26f485f24878b
      path: modules/hal/espressif
      west-commands: west/west-commands.yml

I also removed the clock control init "RMII" in file "eth_esp32.c":

	/* Configure phy for Media-Independent Interface (MII) or
	 * Reduced Media-Independent Interface (RMII) mode
	 */
	const char *phy_connection_type = DT_INST_PROP_OR(0,
						phy_connection_type,
						"rmii");

	if (strcmp(phy_connection_type, "rmii") == 0) {
// 		emac_hal_iomux_init_rmii();
// #if DT_INST_NODE_HAS_PROP(0, ref_clk_output_gpios)
// 		BUILD_ASSERT(DT_INST_GPIO_PIN(0, ref_clk_output_gpios) == 16 ||
// 			DT_INST_GPIO_PIN(0, ref_clk_output_gpios) == 17,
// 			"Only GPIO16/17 are allowed as a GPIO REF_CLK source!");
// 		int ref_clk_gpio = DT_INST_GPIO_PIN(0, ref_clk_output_gpios);

// 		emac_hal_iomux_rmii_clk_output(ref_clk_gpio);
// 		emac_ll_clock_enable_rmii_output(dev_data->hal.ext_regs);
// 		rtc_clk_apll_enable(true, 0, 0, 6, 2);
// #else
// 		emac_hal_iomux_rmii_clk_input();
// 		emac_ll_clock_enable_rmii_input(dev_data->hal.ext_regs);
// #endif
	} else if (strcmp(phy_connection_type, "mii") == 0) {
		emac_hal_iomux_init_mii();
		emac_ll_clock_enable_mii(dev_data->hal.ext_regs);
	} else {
		res = -EINVAL;
		goto err;
	}

	/* Reset mac registers and wait until ready */
	emac_ll_reset(dev_data->hal.dma_regs);
	bool reset_success = false;

And add init inside function "mdio_esp32_initialize"

	const struct device *clock_dev =
		DEVICE_DT_GET(DT_CLOCKS_CTLR(DT_NODELABEL(mdio)));
	clock_control_subsys_t clock_subsys =
		(clock_control_subsys_t)DT_CLOCKS_CELL(DT_NODELABEL(mdio), offset);

	res = clock_control_on(clock_dev, clock_subsys);
	if (res != 0) {
		goto err;
	}

	/* Only the mac registers are required for MDIO */
	dev_data->hal.mac_regs = &EMAC_MAC;

	/* Init MDIO clock */
	emac_hal_set_csr_clock_range(&dev_data->hal, esp_clk_apb_freq());

	// **add new init clock here**
	emac_hal_init(&dev_data->hal, NULL, NULL, NULL);
	emac_hal_iomux_init_rmii();
	emac_hal_iomux_rmii_clk_output(/* ref_clk_gpio */16);
	emac_ll_clock_enable_rmii_output(dev_data->hal.ext_regs);
	rtc_clk_apll_enable(true, 0, 0, 6, 2);

	return 0;

err:
	return res;
}

But it still can't run.
@sylvioalves I have changed follow your suggestions but still doesn't run

[sylvioalves]

Initial fixing PT: #74442

[cbrake]

I'm likewise trying to get this working on an Olimex ESP32-POE that has a LAN8710 Phy and uses GPIO17 for phy clock. Still getting:

<err> phy_mii: No PHY found at address 0

[cbrake]

(currently building @sylvioalves PR branch from #74442)

I instrumented the various drivers to understand the order of init better:

[00:00:00.159,000] <dbg> mdio_esp32: mdio_esp32_initialize: CLIFF: mdio_esp32_initialize
[00:00:00.159,000] <dbg> phy_mii: phy_mii_initialize: CLIFF: LOG_DBG
[00:00:00.763,000] <err> phy_mii: No PHY found at address 0
[00:00:00.763,000] <dbg> eth_esp32: eth_esp32_initialize: CLIFF: esp32 DBG
[00:00:00.775,000] <err> eth_esp32: PHY device not ready

The ref-clk-output-gpios is used in the eth driver, so the clock is not initialized until after the phy driver loads. This is pretty well understood by everyone else in this thread -- just documenting to be clear.

Changing CONFIG_PHY_INIT_PRIORITY to 81 (after eth) causes the following compile error:

Generating files from /run/media/cbrake/zonit/esp/workspace/zonit/build/zephyr/zephyr.elf for board: esp32_poe
ERROR: Device initialization priority validation failed, the sequence of initialization calls does not match the devicetree dependencies.
ERROR: /eth <eth_esp32_initialize> is initialized before its dependency /mdio/ethernet-phy@0 <phy_mii_initialize> (POST_KERNEL+4 < POST_KERNEL+5)
ninja: build stopped: subcommand failed.

I've tried moving the clock init code to the mdio driver as @iwasz did, but currently hanging on startup.

[cbrake]

Someone made the following comment on discord:

The stm32 mac/phy init order is a bit of a kludge. The stm hal mac init function also initialises the phy, so they had to swap the order to not overwrite the phy init.

I have tested the STM32 -- it works with phy clock generated on the MCU, but have not had time to see how they set things up.

[cbrake]

@sylvioalves would it work to move the ref-clk-output-gpios DT entry to the MDIO driver? Or is the silicon partitioned in such a way this does not make sense?

[iwasz]

@sylvioalves Hey can you check out my PR #75024 ? It's kind of a request for comments, as this is my first PR here and I'm not convinced myself if duplicating your function is the best option (probably not). But anyway I wanted your opinion. TLDR : I did what @cbrake proposed, and tested it on my setup (against samples/net/mqtt_publisher sample). Without it the network doesn't work for me because I'm using a PHY that requires a REF_CLK during HW reset and MDIO communication. However the order of initialization is:

• MDIO_INIT_PRIORITY 60
• PHY_INIT_PRIORITY 70
• ETH_INIT_PRIORITY 80

Right now REF_CLK on GPIO17 is enabled in the last of these 3, and so phy_mii.c is not able to read PHY ID (register 2 and 3). Thus PHY communication fails, and we get errors like "phy_mii: PHY (1) ID FFFFFFFF" or "phy_mii: No PHY found at address 1". I tried to set ETH_INIT_PRIORITY to 50 but in the DTS eth node depends on phy node, thus building fails saying priorities are wrong.

[cbrake]

#75024 works for me -- see my comment here.

[dememax]

Hi everyone,

Following up on the ongoing challenges with the WT32-ETH01 and LAN8720A initialization, I’m trying to determine the most architecturally appropriate "Zephyr way" to handle the physical design flaw on these boards.

The Core Issue: As noted in this thread, generic clone boards like the WT32-ETH01 tie the LAN8720A's nRST (Reset) and the 50MHz oscillator's EN (Enable) to the same pin (GPIO 16). This violates standard PHY power-on sequencing. Because the crystal takes time to stabilize after the PHY comes out of reset, the generic Zephyr phy_mii.c driver interrogates the MDIO bus before the PHY's digital logic is ready, resulting in 0xFFFF dead bus reads or auto-negotiation deadlocks.

In researching how different projects within the ecosystem mitigate this, I’ve found four distinct approaches. I would love to hear from the maintainers or community on which of these is considered best practice, or if a better 5th option exists (for example, to implement board-specific PHY reset/clock sequencing support via Devicetree properties handled in the ESP32 Ethernet driver).

1. The Declarative Fix: Device Tree regulator-fixed

Bypassing C code entirely by exploiting the Zephyr power management subsystem. GPIO 16 is defined as a fake power regulator, forcing a strict hardware delay before the network stack boots.

• Mechanism: Using regulator-fixed with a massive startup-delay-us = <150000>; and regulator-boot-on;.
• Pros: Purely declarative, keeps core C files clean.
• Cons: Blocks the entire kernel during the startup delay.

2. The Application-Level Fix: SYS_INIT Watchdog

Handling the hardware idiosyncrasy entirely in the application layer by manually sequencing the GPIO and blocking before the network stack initializes.

• Mechanism: Writing a custom SYS_INIT function running at APPLICATION priority (e.g., priority 90) that asserts GPIO 16, calls k_msleep(150), and releases it before net_config takes over.
• Pros: Developer-friendly, highly deterministic, does not require forking Zephyr core drivers.
• Cons: Shifts hardware workarounds into user application code rather than abstracting it at the board level.

3. The Vendor Abstraction Fix (e.g., Meshtastic)

Projects that use Zephyr but fall back to the ESP-IDF core for networking on ESP32 devices sidestep the generic RTOS driver in favor of the vendor's proprietary driver.

• Mechanism: Using Espressif's native esp_eth_phy_new_lan87xx(). The ESP-IDF driver inherently includes a massive, hardcoded blocking delay specifically designed to mask the WT32-ETH01 clock flaw.
• Reference: Meshtastic firmware implementation PR #9891 and related ESP32 Ethernet refinements.
• Pros: "Just works" out of the box.
• Cons: Relies on vendor lock-in and abandons Zephyr's native phy_mii.c and L2 network stack purity.

4. The Hardware Engineering Fix (e.g., Eclipse 4diac FORTE)

Treating the board design as fundamentally broken for RTOS use and modifying the PCB, acknowledging that software delays compromise real-time determinism.

• Mechanism: Physically decoupling the reset and clock. Desoldering resistor R43 and soldering a jumper wire to directly route the 50MHz EN trace to a separate GPIO.
• Reference: Eclipse 4diac FORTE ESP32 Zephyr WT32-ETH01 documentation.
• Pros: Allows Zephyr's phy_mii Device Tree bindings to work exactly as specified by IEEE 802.3.
• Cons: Unscalable for production or end-users.

---

My Question to the Community:
For developers building on the WT32-ETH01, is Option 1 (regulator-fixed) the officially preferred Zephyr workaround? Or is there a movement to introduce PHY-specific quirks/delays directly into the espressif,esp32-eth or phy_mii drivers to handle these ubiquitous clone boards out of the box?

Thanks for your insights!

[dememax]

Thank you @sylvioalves — I see ref-clk-output-gpios was already pointed out in this thread, and I apologize for not referencing it in my summary above. That said, I'm still slightly lost on what the canonical path forward looks like in practice, so let me sharpen my question.

Two things I left out of my earlier analysis that seem relevant:

5 PR #75024 (by @iwasz, the original author of this thread)

Proposes moving RMII clock initialization into the MDIO driver itself, which would fix the root cause for everyone rather than pushing the workaround into application code or Device Tree. @cbrake confirmed it working on Olimex ESP32-POE. Is this the right place to land this fix for mainline?

6. Separate reset-gpios + clock-gpios pins

My Option 4 (hardware cut) is only the enabling step — the real benefit is that once GPIO 16 is decoupled, Zephyr's standard DT bindings work exactly as designed, with no application workarounds at all. This is probably worth separating from the "PCB modification" framing.

---

So my concrete questions are:

1. Is ref-clk-output-gpios the intended Zephyr-native workaround for WT32-ETH01 today, while we wait for a driver-level fix?
2. Is PR drivers: mdio_esp32: let the REF_CLK be initialized before the PHY. #75024 the right place to land the clock-sequencing fix in espressif,esp32-eth / the MDIO driver, or should it go somewhere else?
3. Is there any movement toward encoding WT32-ETH01-specific quirks in its board DTS so application developers don't have to rediscover this independently?

Thanks again!