Hi,
I’m working with a Jetson AGX Orin module on a custom carrier board using a Marvell 88E1512 RGMII PHY, running JetPack 6.2
Ethernet fails to initialize because the PHY ResetN line is never driven high by the EQOS driver.
During boot I consistently get:
[ 10.823512] nvethernet 2310000.ethernet: failed to connect PHY
[ 10.823516] net eth0: ether_open: Cannot attach to PHY (error: -19)
[ 789.100515] nvethernet 2310000.ethernet: ether_ioctl: Interface not up
I followed the NVIDIA documentation for RGMII adaptation and included the necessary changes here:
tegra234-mb1-bct-pinmux-p3701-0000-a04.dtsi
tegra234-mb1-bct-gpio-p3701-0000-a04.dtsi
Ihave modified the DTB correctly, below is my EQOS node (simplified to relevant parts):
ethernet@2310000 {
compatible = "nvidia,nveqos";
status = "okay";
phy-mode = "rgmii-id";
// Reset GPIO: TEGRA234_MAIN_GPIO(G,5)
nvidia,phy-reset-gpio = <0xf1 0x35 0>; // also tried with "1"
mdio {
phy: phy@0 {
reg = <0>;
nvidia,phy-rst-pdelay-msec = <224>;
nvidia,phy-rst-duration-usec = <10000>;
marvell,copper-mode;
marvell,reg-init = <0x03 0x12 0x7fff 0x880>;
};
};
};
The reset pin is mapped to soc_gpio18_pg5, which is gpio-388.
When I inspect the GPIO state after boot:
gpio-388 (PG.05 | phy_reset ) out lo
The critical issue:
- If I set this GPIO default-high in the BCT (
tegra234-mb1-bct-gpio-p3701-0000-a04.dtsi), it starts high, confirming the hardware is fine.
- But as soon as Linux boots, the EQOS driver drives it low and never releases it, so the PHY stays in reset permanently.
Changing the flags in nvidia,phy-reset-gpio (0 or 1) has no effect.
The driver never toggles Reset, and it never goes high at any point during initialization.
*** Please note that this reply is generated by LLM automatically ***
Based on the provided information, it appears that you are experiencing an issue with the PHY ResetN line not being driven high by the EQOS driver during boot on your Jetson AGX Orin module. This is causing the Ethernet to fail to initialize.
To troubleshoot this issue, let’s break down the steps you’ve taken so far:
- You’ve modified the DTB (Device Tree Binary) to include the necessary changes for RGMII adaptation. This includes setting the reset pin to GPIO 216, which is the correct pin for the PHY ResetN line.
- You’ve inspected the GPIO state after boot and found that the PHY ResetN line is not being driven high by the EQOS driver.
- You’ve tried setting the GPIO default high in the BCT (Boot Configuration Table) and confirmed that the hardware is working correctly. However, the EQOS driver is not toggling the Reset line, and it never goes high at any point during initialization.
Comparing your setup to the NVIDIA documentation for RGMII adaptation, it appears that you’ve followed the correct steps. However, there might be a few potential issues to consider:
- Ensure that the PIN mux settings are correct in the RGMII interface. Double-check that the reset pin is correctly mapped to GPIO 216 in the DTB.
- Verify that the PHY driver is available and correctly configured. Make sure that the PHY driver is loaded and initialized before the EQOS driver.
- Check the EQOS driver configuration. Ensure that the driver is configured to toggle the Reset line and drive it high during initialization.
To further troubleshoot this issue, you can try the following:
- Use a logic analyzer or oscilloscope to monitor the PHY ResetN line during boot. This will help you determine if the line is being driven high at any point during initialization.
- Check the kernel logs for any error messages related to the EQOS driver or PHY initialization.
- Try modifying the EQOS driver configuration to see if it makes any difference. You can try setting the flags to 0 or 1, or try using a different driver configuration.
In summary, it appears that the issue is related to the EQOS driver not toggling the Reset line and driving it high during initialization. Further troubleshooting 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. ***
I confirmed the ResetN pin was toggling correctly with an oscilloscope, isolating the issue to configuration.
- DTS Fix (Interrupt): The interrupt was not working because the
phy-handle line was commented out due to a compilation error. The documentation error used $ instead of the required &.
- Fix:
phy-handle = <&phy>;
- Pinmux Fix (Pulls): The documentation suggested
TEGRA_PIN_PULL_UP for EQOS receive pins (eqos_rd0_pe6 through eqos_rxc_pf3). However my working configuration has pull-none: nvidia,pull = <TEGRA_PIN_PULL_NONE>;
I recommend reviewing the documentation for both the phy-handle syntax and the EQOS pin pull setting.
Is it possible that this is related to the hardware design on your custom board?
Marvell 88E1512 has been used for many other users in this forum but didn’t get others talking about they hit pinmux issue in RX.