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.