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?  

[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 · Accepted solution]

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