Enabling ethernet0 in u-boot

[RGiom.1]

Hello,

I'm currently using the following setting for the ethernet0 in Linux 5.7.6:

&ethernet0 {
 
 status = "okay";
 
 interrupts-extended = <&intc GIC_SPI 61 IRQ_TYPE_LEVEL_HIGH>,
 
 <&intc GIC_SPI 62 IRQ_TYPE_LEVEL_HIGH>,
 
 <&exti 70 1>;
 
 interrupt-names = "macirq",
 
 "eth_wake_irq",
 
 "stm32_pwr_wakeup";
 
 
 pinctrl-0 = <&ethernet0_rmii_pins_a>;
 
 pinctrl-1 = <&ethernet0_rmii_pins_sleep_a>;
 
 pinctrl-names = "default", "sleep";
 
 phy-mode = "rmii";
 
 max-speed = <100>;
 
 phy-handle = <&phy0>;
 
 
 mdio0 {
 
 #address-cells = <1>;
 
 #size-cells = <0>;
 
 compatible = "snps,dwmac-mdio";
 
 reset-gpios = <&gpioh 6 GPIO_ACTIVE_LOW>;
 
 reset-delay-us = <1000>;
 
 
 phy0: ethernet-phy@1 {
 
 reg = <1>;
 
 };
 
 };
 
};

It works correctly, while by using the following setting in u-boot v2020.07-rc5 the ethernet doesn't work:

&ethernet0 {
 status = "okay";
 interrupts-extended = <&intc GIC_SPI 61 IRQ_TYPE_LEVEL_HIGH>,
 <&intc GIC_SPI 62 IRQ_TYPE_LEVEL_HIGH>,
 <&exti 70 1>;
 interrupt-names = "macirq",
 "eth_wake_irq",
 "stm32_pwr_wakeup";
 
 clock-names = "stmmaceth",
 "mac-clk-tx",
 "mac-clk-rx",
 "ethstp",
 "syscfg-clk";
 clocks = <&rcc ETHMAC>,
 <&rcc ETHTX>,
 <&rcc ETHRX>,
 <&rcc ETHSTP>,
 <&rcc SYSCFG>;
 
 
 pinctrl-0 = <&ethernet0_rmii_pins_a>;
 pinctrl-1 = <&ethernet0_rmii_pins_sleep_a>;
 pinctrl-names = "default", "sleep";
 phy-mode = "rmii";
 max-speed = <100>;
 phy-handle = <&phy0>;
 
 mdio0 {
 #address-cells = <1>;
 #size-cells = <0>;
 compatible = "snps,dwmac-mdio";
 reset-gpios = <&gpioh 6 GPIO_ACTIVE_LOW>;
 reset-delay-us = <1000>;
 
 phy0: ethernet-phy@1 {
 reg = <1>;
 };
 };
};

When i try to ping an host I get the error EQOS_DMA_MODE_SWR stuck! :'(

Thanks for your answers,

Rodolfo

[Christophe Guibout]

Hi @Armando Genovese​ ,

I noticed that you use more recent version of u-boot and kernel than the ones delivered in the latest MMDV (U-Boot v2020.01 and Kernel LTS v5.4.56).

The MMDV also includes patches on top of these revision which are not yet upstreamed, so I would recommand to be carreful when you take latest versions of u-boot or kernel version, because it may not includes the latest patches.

Nevertheless, I tried ethernet feature with v2020.07-rc5 on my DK2 board, and I don't have any error:

STM32MP> dhcp
ethernet@5800a000 Waiting for PHY auto negotiation to complete...... done
BOOTP broadcast 1
DHCP client bound to address 192.168.1.34 (30 ms)
STM32MP> ping 192.168.1.60
Using ethernet@5800a000 device
host 192.168.1.60 is alive

I noticed you configured the ethernet as rmii, which makes be think that you are not working on DK2 board (rgmii).

If you made a custom board, the schematic would be helpfull to understand the issue, so please contact your ST local office for deeper investigations.

BR,

Christophe

[CErik.1]

Hello Rodolfo,

I am getting the exact same "EQOS_DMA_MODE_SWR stuck". I have tried per Christophe's hints to run the ST flavor v2018.11-stm32mp-r2.1 and v2020.01-stm32mp-r2.1. I have also tried vanilla U-Boot 2020.10. Same error. I would assume this to be a clocking issue, but since your write that it works fine in Linux I am curious. Did you figure it out?

I am trying to talk to a PHY using MII. The PHY has a 25 MHz xtal.

Best Regards

[RGiom.1]

I also suspect it's the clock but didn't make any other considerations.

On my machine the PHY is a KSZ8081 with a 25MHz clock interfaced with RMII. Under Linux everything works fine so I exclude hardware problems.

Ciao,

Rodolfo

[MFuzz]

I ran into the same problem (RMII on a custom board with phy clock generation done by the MCU)

Turned out that the problem was the eth-ck was not defined in the device tree.

I think this is only needed when the MCU is generating the phy clock (the DK boards not only use RGMII they also have an external phy oscillator)

This patch fixed it for me (on ST u-boot  2020.01-stm32mp-r2).

Upstream u-boot 2020.10 already has this

diff --git a/arch/arm/dts/stm32mp151.dtsi b/arch/arm/dts/stm32mp151.dtsi
index f021191..fde40b6 100644
--- a/arch/arm/dts/stm32mp151.dtsi
+++ b/arch/arm/dts/stm32mp151.dtsi
@@ -1629,10 +1629,12 @@
 clock-names = "stmmaceth",
 "mac-clk-tx",
 "mac-clk-rx",
+ "eth-ck",
 "ethstp";
 clocks = <&rcc ETHMAC>,
 <&rcc ETHTX>,
 <&rcc ETHRX>,
+ <&rcc ETHCK_K>,
 <&rcc ETHSTP>;
 st,syscon = <&syscfg 0x4>;
 snps,mixed-burst;

Regards,

Martin

[viniciusfre]

Hello. This is my dts:

&ethernet0 {
	status = "okay";
	pinctrl-0 = <&ethernet0_rgmii_pins_a>;
	pinctrl-1 = <&ethernet0_rgmii_pins_sleep_a>;
	pinctrl-names = "default", "sleep";
	phy-mode = "rgmii";
	max-speed = <1000>;
	phy-handle = <&phy0>;
	phy-reset-gpios = <&gpiog 0 GPIO_ACTIVE_HIGH>;
 	st,eth_clk_sel = <1>;
 	clock-names = "stmmaceth",
 	"mac-clk-tx",
 	 	"mac-clk-rx",
 	"ethstp",
 	"syscfg-clk",
 	"eth-ck";
 	clocks = <&rcc ETHMAC>,
 	<&rcc ETHTX>,
 	<&rcc ETHRX>,
 	<&rcc ETHSTP>,
 	<&rcc SYSCFG>,
 	<&rcc ETHCK_K>;
 st,syscon = <&syscfg 0x4>;
 snps,mixed-burst;
 
	mdio0 {
		#address-cells = <1>;
		#size-cells = <0>;
		compatible = "snps,dwmac-mdio";
		phy0: ethernet-phy@6 {
			reg = <6>;
		};
	};
};

It has ethstp and ETHCK_K, but I am still getting this error.. EQOS_DMA_MODE_SWR stuck

[NAgli.1]

Hi @Christophe Guibout​ , @RGiom.1​ ,

I`m getting same error.

ST32MP>dhcp
EQOS_DMA_MODE_SWR stuckFAILED: -110ST32MP>

Custom board. Phy is DP83848I. External 25Mhz XTAL.

Here is dts for u-boot

&ethernet0{
	pinctrl-names = "default", "sleep";
	pinctrl-0 = <&eth1_pins_mx>;
	pinctrl-1 = <&eth1_sleep_pins_mx>;
	status = "okay";
 
	phy-mode = "mii";
	max-speed = <100>;
	phy-handle = <&phy0>;
	nvmem-cells = <&ethernet_mac_address>;
	nvmem-cell-names = "mac-address";
	
	mdio0 {
		#address-cells = <1>;
		#size-cells = <0>;
		compatible = "snps,dwmac-mdio";
		phy0: ethernet-phy@1 {
			compatible = "ethernet-phy-id2000.5ca2";
			reset-gpios = <&gpiog 0 GPIO_ACTIVE_LOW>;
			reg = <1>;
		};
	};
};

Best regards,

Nael

[ZUl A.1]

Did you find a solution for EQOS_DMA_MODE_SWR stuck?

[Olivier GALLIEN]

Hi @ZUl A.1​ ,

This issue was initially reported on very old DV1.0 no longer supported.

Enhancement likely provided since DV2.0 (Uboot v2020.01 ) .. also no longer supported.

If you are facing similar issue on recent release (DV4.1 recommended) thanks to create a new post with all references.

Thx

Olivier