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

[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

[PZak.1]

Hello Olivier,

When I check the PMCSETR register in uboot I get:

md 0x50020004 1

50020004: 00800000

When I check from Linux I get:

root@stm32mp1:~# devmem2 0x50020004

/dev/mem opened.

Memory mapped at address 0xb6f1f000.

Value at address 0x50020004 (0xb6f1f004): 0x0

This is not what you expect.

Best regards,

Paul

[OlivierK]

Hello Paul,

Sorry, the PMCSETR register is part of the SYSCONFIG peripheral which clocks needs to be enabled under Linux.

Please do the following to enable the Sysconfig clock in order to read the register:

root@stm32mp1:~# devmem2 0x50000A10 W 0x00000800

root@stm32mp1:~# devmem2 0x50020004 W

00800000 is indeed the good value (the value that you've found in U-boot) it matches the product Reference Manual RMII with oscillator. If you found this value also in Linux, that means the s/w config between the GMAC and PHY is correct for RMII with Crystal configuration.

What about the PHY itself, any activity whasoever (TX/RX lines). What about the PHY driver default configuration regarding the clock source 25MHZ/50MHz? Any PHY bootstrapping config that I've mentioned earlier? Did you check reset/VDD potential issues ?

Best Regards

Olivier

[PZak.1]

Hello Olivier,

I ran the commands you suggested with the following results:

root@stm32mp1:~# devmem2 0x50000A10 W 0x00000800

/dev/mem opened.

Memory mapped at address 0xb6ff0000.

Value at address 0x50000A10 (0xb6ff0a10): 0x10000

Written 0x800; readback 0x800

root@stm32mp1:~# devmem2 0x50020004 W

/dev/mem opened.

Memory mapped at address 0xb6ff4000.

Value at address 0x50020004 (0xb6ff4004): 0x800000

It looks correct according to your expectations. Same as U-Boot. I have been unable to test the TX/RX lines but I will do so first thing in the morning. We have verified reset and VDD. Also we have FXEN=0 to disable fiber mode. I will pour over the design checklist again from Micrel to make sure we do not have bootstrapping or any other issues.

When you mention PHY driver default configuration regarding the clock source 25MHZ/50MHz, do we need to make any adjustments to the device tree to accommodate this?

The design checklist from Micrel demonstrates that we should be OK with the PHY and MAC sharing a clock source.

Best regards,

Paul

[OlivierK]

Hi Paul,

When you mention PHY driver default configuration regarding the clock source 25MHZ/50MHz, do we need to make any adjustments to the device tree to accommodate this?

No adjustments necessary in the DT. I wondered if the PHY driver expects the source clock default to be 50MHz or 25MHz on some RMII PHYs. Is there any erratasheet on this phy?

You can also try to see in U-boot if there is any link activity while connecting to a server.

STM32MP1 > dhcp

Olivier

[OlivierK]

Hi Paul,

After overlooking drivers/net/phy/micrel.c it might be important to specify which PHY 8041 model is used in the DT:

You may include back: compatible = "ethernet-phy-id0022.1510", "ethernet-phy-ieee802.3-c22";

with 0022.1510 corresponding to your Ethernet PHY: this can be found in datasheet of the Ethernet PHY, and find PHY Identifier 1 and PHY Identifier 2 registers.

[PZak.1]

Hello Olivier,

I will include these entries back into the device tree. We just found a hardware wiring problem where we neglected to tie the RJ45 magnetics transformer center taps to VDDA. I have a board being reworked right now and will let you know if this solves our connection problem.

Best regards and thank you for continuing to support us,

Paul

[PZak.1]

Hello Olivier,

I would like to say how grateful we are for your support. ST provides great support for their products. It keeps all of us from digging ourselves into deep holes. You helped us solve our problem.

Thanks again and have a great day,

Paul

[OlivierK]

Hello Paul,

Thank you for your kind message.

The root cause of the issue was the RJ45 magnetics transformer? or maybe something else? This is also to help others on the community.

I'm glad that you are sorted out eventually.

Best Regards,

Olivier

[PZak.1]

Hello Olivier,

Yes, the root cause of the connectivity issue was the missing power connection to the RJ45 magnetics transformer. We have tested and confirmed the PHY is fully functional.

Best regards,

Paul