Can someone please help. We are trying to implement a KSZ8041FTL Ethernet PHY using an STM32MP157C. We are not able to connect to the device via MDIO. The device does not respond.

[PZak.1]

We are trying to implement a KSZ8041FTL in an embedded design. We are using an STM32MP157 device in a SOC provided by Octavo systems (OSD32MP157C-512M-BAA). We have used design resources provided by Microchip and followed examples provided. We have followed resources provided by STMicro to configure the pin connections and device tree for the PHY. We are not able to connect to the device via MDIO. The device does not respond. The resulting output on the Linux kernel log indicates that MDIO device at address 3 is missing. We have the device strapped to address 1. We see MDC and MDIO activity when the device is being probed but it always reports device missing at address 3. There is no response from the PHY. We have verified the presence of the 50Mhz ref to the PHY and monitored the reset line, configuration pins, and address pins. Nothing appears wrong. What are we missing?  

[OlivierK]

Hello PZak.1 (Community Member),

You seem to have an issue in your DT while declaring the phy subnode, can you share it please? along with your DT pinmuxing .

I guess you've already checked this article? https://wiki.st.com/stm32mpu/wiki/Ethernet_device_tree_configuration.

Check also that you are currently working with the latest rev of the KSZ8041 driver.

Rgds,

Olivier

[PZak.1]

Hello Olivier,

I have followed the article you have mentioned. In fact we started by just pasting in the template from that article for our application. RMII with 50Mhz clock provided by external oscillator. Can you suggest how we can determine if we have the latest KSZ8041 driver? We are using Linux kernel version 5.4.31 provided by ST. Below is the pinmuxing and device tree. Thank you for your prompt response.

Best regards,

Paul

 eth1_pins_mx: eth1_mx-0 {

   pins1 {

      pinmux = <STM32_PINMUX('A', 1, AF11)>, /* ETH1_REF_CLK */

         <STM32_PINMUX('C', 1, AF11)>, /* ETH1_MDC */

         <STM32_PINMUX('G', 13, AF11)>, /* ETH1_TXD0 */

         <STM32_PINMUX('G', 14, AF11)>; /* ETH1_TXD1 */

      bias-disable;

      drive-push-pull;

      slew-rate = <1>;

   };

   pins2 {

      pinmux = <STM32_PINMUX('A', 2, AF11)>; /* ETH1_MDIO */

      bias-disable;

      drive-push-pull;

      slew-rate = <0>;

   };

   pins3 {

      pinmux = <STM32_PINMUX('A', 7, AF11)>, /* ETH1_CRS_DV */

         <STM32_PINMUX('C', 4, AF11)>, /* ETH1_RXD0 */

         <STM32_PINMUX('C', 5, AF11)>; /* ETH1_RXD1 */

      bias-disable;

   };

   pins4 {

      pinmux = <STM32_PINMUX('B', 11, AF11)>; /* ETH1_TX_EN */

   };

 };

 eth1_sleep_pins_mx: eth1_sleep_mx-0 {

   pins {

      pinmux = <STM32_PINMUX('A', 1, ANALOG)>, /* ETH1_REF_CLK */

         <STM32_PINMUX('A', 2, ANALOG)>, /* ETH1_MDIO */

         <STM32_PINMUX('A', 7, ANALOG)>, /* ETH1_CRS_DV */

         <STM32_PINMUX('B', 11, ANALOG)>, /* ETH1_TX_EN */

         <STM32_PINMUX('C', 1, ANALOG)>, /* ETH1_MDC */

         <STM32_PINMUX('C', 4, ANALOG)>, /* ETH1_RXD0 */

         <STM32_PINMUX('C', 5, ANALOG)>, /* ETH1_RXD1 */

         <STM32_PINMUX('G', 13, ANALOG)>, /* ETH1_TXD0 */

         <STM32_PINMUX('G', 14, ANALOG)>; /* ETH1_TXD1 */

   };

 };

      ethernet0: ethernet@5800a000 {

            compatible = "st,stm32mp1-dwmac", "snps,dwmac-4.20a";

            reg = <0x5800a000 0x2000>;

            reg-names = "stmmaceth";

            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";

            clocks = <&rcc ETHMAC>,

            <&rcc ETHTX>,

            <&rcc ETHRX>,

            <&rcc ETHSTP>;

            st,syscon = <&syscfg 0x4>;

            snps,mixed-burst;

            snps,pbl = <2>;

            snps,en-tx-lpi-clockgating;

            snps,axi-config = <&stmmac_axi_config_0>;

            snps,tso;

            power-domains = <&pd_core>;

            status = "disabled";

      };      

&ethernet0 {

      status = "okay";

   pinctrl-names = "default", "sleep";

   pinctrl-0 = <&eth1_pins_mx>;

   pinctrl-1 = <&eth1_sleep_pins_mx>;

      phy-mode = "rmii";

      max-speed = <100>;

      phy-handle = <&phy0>;

      mdio0 {

              #address-cells = <1>;

              #size-cells = <0>;

              compatible = "snps,dwmac-mdio";

      phy0: ethernet-phy@1 {

            compatible = "ethernet-phy-id0022.1510", "ethernet-phy-ieee802.3-c22";

                      reg = <1>;

               };

       };

};

[OlivierK]

Hi PZak.1 (Community Member)

Ok so you choose to feed the 50MHz PHY clock source using an external oscillator (not from the RCC).

in your DT thought, I don't see clock-names = eth-ck, which is mandatory in all configurations.

If it doesn't fix, In your design PA1 is used as the REF_CLK (clock from the PHY back to the GMAC) . Can you observe 50MHz on this line?

Also, compatible = "ethernet-phy-id0022.1510", "ethernet-phy-ieee802.3-c22";

Is it the driver recomendation? otherwise I would remove it.

By the way did you enabled the phy driver in the kernel menuconfig?

 │ Symbol: MICREL_PHY [=m]                         │  

 │ Type : tristate                            │  

 │ Defined at drivers/net/phy/Kconfig:204                 │  

 │  Prompt: Micrel PHYs                          │  

 │  Depends on: NETDEVICES [=y] && PHYLIB [=y]              │  

 │  Location:                               │  

 │   -> Device Drivers                          │  

 │    -> Network device support (NETDEVICES [=y])            │  

 │ (2)   -> PHY Device support and infrastructure (PHYLIB [=y]) 

I also found this info in:

https://kernel.googlesource.com/pub/scm/linux/kernel/git/next/linux-next/+/refs/heads/akpm-base/Documentation/devicetree/bindings/net/micrel.txt

Some PHYs, such as the KSZ8041FTL variant, support fiber mode, enabled by the FXEN boot strapping pin. It can't be determined from the PHY registers whether the PHY is in fiber mode, so this boolean device tree property can be used to describe it. In fiber mode, auto-negotiation is disabled and the PHY can only work in 100base-fx (full and half duplex) modes.

Check the bootstrap pins that you are not in this mode.

Rgds,

Olivier

[PZak.1]

Hello Olivier,

I can observe 50Mhz on PA1. I was not sure about the clock-names = eth-ck. I will add this and test immediately. Also I do not think I need compatible = "ethernet-phy-id0022.1510", "ethernet-phy-ieee802.3-c22"; I did this in an effort to force recognition of the PHY.

Thank you for your response.

Best regards,

Paul

[PZak.1]

Hello Olivier,

I have verified the kernel menuconfig settings. They are as you have suggested. Still no MDIO response from the PHY.

From the kernel log:

[ 3.177030] libphy: stmmac: probed

[ 3.180426] mdio_bus stmmac-0: MDIO device at address 3 is missing.

......

[17.426691] stm32-dwmac 5800a000.ethernet eth0: no phy at addr -1

[17.431344] stm32-dwmac 5800a000.ethernet eth0: stmmac_open: Cannot attach to PHY (error: -19)

Can you help me understand why I need to have clock-names = eth-ck set in device tree. We have a 50MHz external oscillator that feeds both the PHY and ETH1_RMII_REF_CLK (PA1) input. Does this not correspond to 3.3.1 RMII with Crystal on PHY (Reference clock (standard RMII clock name) is provided by a Phy Crystal) from - https://wiki.st.com/stm32mpu/wiki/Ethernet_device_tree_configuration. With the exception that we have the external oscillator that feeds the PHY and STM32MP1 reference clock input.

Can you provide a device tree example that would work with our external oscillator configuration?

Thank you for your help with this issue.

Best regards,

Paul

[OlivierK]

Hello Paul,

The 3.3.1RMII with Crystal on PHY (Reference clock (standard RMII clock name) is provided by a Phy Crystal) from - https://wiki.st.com/stm32mpu/wiki/Ethernet_device_tree_configuration.  should match your case.

In fact "clock-names=eth-ck" will be added by default in all configurations for next dwmac-stm32.c revision, but it doesn't affect your case anyway using Linux kernel version 5.4.31.

I verified you pinmux and DT, and it looks correct.

To come back on your error, the main issue is that

[17.426691] stm32-dwmac 5800a000.ethernet eth0: no phy at addr -1

-> You can try to remove "reg=<1>" in the DT PHY subnode , that will force the scan of all the possible 16 phy addresses. 1 should eventually respond.

-> check also that the PHY VDD supply is applied.

-> check that PHY reset is not tied asserted.

For the PMCSETR register configuration check (RMII with crystal)

>devregs 0x50020004 should equal 0x100000

Let me know.

Best Regards,

Olivier

[PZak.1]

Hello Olivier,

I have checked that reset is not asserted and that voltages are present. They are as suggested. I removed "reg=<1>" in the device tree. Still the PHY does not respond. Why the kernel log always responds with device at address 3 is missing is a mystery.

I am not sure how to check the devregs value you mention but I am working on that right now. I will update you with results.

Best regards,

Paul

[PZak.1]

Hello Olivier,

Well I made a stupid mistake with a makefile in my kernel directory which caused the PHY to not be recognized. I was not using the correct .config file. After correcting this, the correct driver loads and reports the PHY at address 1.

Kernel log:

stm32-dwmac 5800a000.ethernet eth0: PHY [stmmac-0:01] driver [Micrel KSZ8041]

dwmac4: Master AXI performs any burst length

stm32-dwmac 5800a000.ethernet eth0: No Safety Features support found

stm32-dwmac 5800a000.ethernet eth0: IEEE 1588-2008 Advanced Timestamp supported

stm32-dwmac 5800a000.ethernet eth0: registered PTP clock

stm32-dwmac 5800a000.ethernet eth0: configuring for phy/rmii link mode

I am using the device tree files directly from 3.3.1 RMII with Crystal on PHY (Reference clock (standard RMII clock name) is provided by a Phy Crystal) from - https://wiki.st.com/stm32mpu/wiki/Ethernet_device_tree_configuration. I have another problem though. Now I am unable to get a connection. If I connect an active Ethernet connection the link status does not change. The link does not go up and there is no LED activity.

Do you have any ideas about this?

Thank you for your assistance and best regards,

Paul

[OlivierK]

Hello Paul,

That's good news, we can go a step further. The Micrel driver is used.

Can you check the value of the PMCSETR register configuration (RMII with crystal)

root@stm32mp1:~# devmem2 0x50020004 

should read 0x100000

Regards

Olivier