KSZ9031 PHY not showing up on MDIO Bus

Robotics & Edge Computing Jetson Systems Jetson AGX Orin
, , , , ,
1

I’m currently trying to get my KSZ9031 to show up on MDIO bus. In hardware, I have it set to address 1, and the same is set in the device tree. I’m using Jetson Orin AGX Industrial for my module. On our board, we are using both the KSZ9031 for RGMII and the Marvell Phy for MGBE, as seen in the dev kit. The Marvell Phy sits on MDIO address 0. I have attached dmesg output. The main file I have been editing for the device tree changes has been “tegra234-base-overlay.dtsi”.

Files included below:

tegra234-base-overlay.dtsi

pinmux

gpio default config

dmesg output

Things I have tried:

Verified all hardware populations, voltage rails present, 25mhz clock present for the KSZ9031.

Multiple device trees from other people on the forum, while trying to keep the MDIO bus address the same

Tried pull-up and no pull-up on the RX lines for RGMII

Followed the developer guide for setting up RGMII

Tried dramatically increasing reset and post delay timing inside of the device tree for the KSZ9031.

Tried changing the MDIO address in hardware and software to address of 2, but that didn’t work either

Tried removing our pull up off the reset pin on the KSZ9031 and add pull up on module

Tried removing our pull up off the reset pin on the KSZ9031 and no pull up on the module to allow the software to drive the reset pin.

I have dumped the device tree in linux to verify my changes were running in the active device tree.

I’m getting some MDIO transactions which are seen below:

Before Linux Boots:

MDIO_Before_Uboot
MDIO_Before_Uboot800×480 11.1 KB

After Linux Boots when driver is trying to read the MDIO address

MDIO_Linux_Boot
MDIO_Linux_Boot800×480 10.5 KB

dmesg1.txt (1.8 KB)

tegra234-base-overlay.txt (20.6 KB)

pinmux.txt (65.7 KB)

gpio.txt (3.5 KB)

2

*** Please note that this reply is generated by LLM automatically ***

Based on the provided context, I will attempt to provide a comprehensive answer to the question.

The issue at hand is that the KSZ9031 is not showing up on the MDIO bus, despite being properly configured in the device tree and having the correct hardware setup. The KSZ9031 is set to address 1, and the same is set in the device tree. The Marvell Phy, which sits on MDIO address 0, is working correctly.

To troubleshoot this issue, several steps have been taken:

  1. Verified all hardware populations, voltage rails, and 25mhz clock presence for the KSZ9031.
  2. Tried multiple device trees from other people on the forum, while keeping the MDIO bus address the same.
  3. Tried pullup and no pullup on the RX lines for RGMII.
  4. Followed the developer guide for setting up RGMII.
  5. Tried dramatically increasing reset and post delay timing inside of the device tree for the KSZ9031.
  6. Tried changing the MDIO address in hardware and software to address 2, but that didn’t work either.
  7. Tried removing the pull-up off the reset pin on the KSZ9031 and adding a pull-up on the module.
  8. Tried removing the pull-up off the reset pin on the KSZ9031 and no pull-up on the module to allow the software to drive the reset pin.

Despite these efforts, the KSZ9031 is still not showing up on the MDIO bus. The device tree has been dumped in Linux to verify that the changes were running in the active device tree.

Comparing the provided information to the context, it appears that the issue may be related to the clock and voltage management on the Jetson Orin AGX Industrial module. The clock frequency is proportional to voltage, and dynamic voltage scaling is closely related to frequency scaling. The Boot and Power Management (BPMP) firmware, which runs on the BPMP processor, handles most clock register manipulation on Jetson Orin.

It is possible that the KSZ9031 is not being properly initialized or configured due to a clock or voltage management issue. To further troubleshoot this issue, it may be helpful to investigate the clock and voltage management settings on the Jetson Orin AGX Industrial module and ensure that they are properly configured for the KSZ9031.

Additionally, the provided dmesg output and device tree files may provide further clues as to the cause of the issue. It may be helpful to compare the dmesg output to the device tree files to ensure that the KSZ9031 is being properly initialized and configured.

In summary, the issue appears to be related to the clock and voltage management on the Jetson Orin AGX Industrial module, and further investigation is needed to determine the root cause of the issue.

*** Please give the thumbs up if you get answers you like. Or provide feedback to help us improve the answer. ***

4

Can I get some help on this issue?

5

Tried changing the MDIO address in hardware and software to address of 2, but that didn’t work either

Are you sure this is correct? This address is 2 or other value depends on hardware side pin.

6

I changed the strapping configuration for the phy address in hardware to 2 and then changed it to 2 in the device tree to match.

7

Wayne,

I was able to get an Ethernet connection, but I had to force the link in the device tree by using “fixed-link” and also disabling the phy-handle and the phandle inside the PHY node inside the MDIO node. By doing this, I was able to connect to the internet at 1GbE speeds. This solution doesn’t allow us to use auto-negotiation and interrupts, which our product must support. Is there anything we are doing wrong that would prevent the module and KSZ9031 from communicating over MDIO?

8

If you are sure pinmux setting is correct, then check if any timing requirement for MDIO to communicate with PHY.
(checking if PHY is ready when MDIO inits the communication).

Your current error only indicates that MDIO fails to communicate with PHY.

9

Wayne,

Does MDIO and MDC need to be added to the tegra234-soc-overlay file in the pin-ctrl groups? The ones in question are eqos_mii_rx_input_state_disable and eqos_mii_rx_input_state_enable.

10

Hi,

pinctrl value by default is already the correct one that you should not change it.

The only item about “pinmux” we are talking about is the file inside of MB1. We should not see you put any pinmux setting in a overlay dtbo.

11

Wayne,

We are still not able to get mdio communication working. I did try and disable our Marvell PHY in the device tree and in the ODMDATA just to make sure the KSZ9031 and the Marvell Phy were not conflicting with one another, and that didn’t help the issue either.

12

Hi Woods,

I was looking at you ethernet device tree and I noticed that there may be an ordering difference on you PHY compatible statement. You have the micrel phy listed last which according to syntax is the least specific. You may try putting that as the first (most specific) in the compatible statement to see if it makes any difference.

Google reference:
Naming Convention and Order

The values in the compatible string list are crucial for driver matching and should adhere to specific conventions:

  • Most Specific to Least Specific: The strings should be listed in order from the most specific to the most general compatible hardware. The Linux kernel attempts to find a matching driver using this hierarchical order.
13

Hey Jim,

I’ve tried all the different configurations for the compatibility string. Tried the following:

All options by themselves

configuration above in previous message

ethernet-phy-id0222.1620 first

micrel,ksz9031 first

Tried ordering them from least specific to most specific

Ordering from most specific to least specific

All of these resulted in the same issue, but I’m getting different MDIO scope captures so the drivers are trying to do something different for each one. The funny thing is as soon as I put the fixed link in place and remove the phy-handle I see ethernet@2310000 in the /sys/bus/mdio_bus/devices/ list along with the fixed-link node. Before with the phyhandle uncommented I only see our Marvell Phy. So it looks like the device is capable of communicating over MDIO, but as soon as you try and use a PHY driver it goes haywire. I did check to see if our delays were long enough according to spec and we are more than enough by almost a second since it is just a minimum time delay you must meet.

14

Hi Woods,

You may want to put a scope probe on the reset line. I noticed the Micrel PHY you are using on the RGMII side is also an active low signal. You may be having the same issue that I just found and posted in my thread.

Jim

15

Hey Jim,

Looks like on my end, the reset pin is behaving properly. For some reason, I keep on getting thrown this error output from the micrel.c driver. I think it is mainly because the PHY isn’t being found on the MDIO bus. I do see a toggling of reset when the OS loads and then again for some reason before MDIO transactions actually start. Then I get the failure to attach PHY and then the reset line is dragged low. The first reset might be the NVETHERNET driver issuing a reset and then the micrel.c driver is issuing a reset. The last reset, I’m assuming, is that the PHY failed to attach, so let’s shut off the PHY.

image
image691×151 3.94 KB

16

Hey Wayne,

I’m currently getting some bad stair stepping on my reset pin from the KSZ9031 to the Jetson GPIO pin (PG5). Is there a way to resolve this? Below is the two different things I tried today:

  1. PG5 is set as an output, but is not declared a high or a low at init. On the reset line I have a 10k pull up to 1.8V and a 10uF cap that was called out on the design guide for the KSZ9031. The stair stepping isn’t bad here, but is still relevant.

CH1: Reset

lec115
lec1151024×547 114 KB

  1. PG5 is set as an output and high at init. On the reset line I have a 10k pull up to 1.8V and a 100nF cap. The stair stepping got much worse in this scenario.

CH1: Reset

lec118
lec1181024×547 100 KB