RGMI 1Gb Ethernet for DP83867

Robotics & Edge Computing Jetson Systems Jetson AGX Orin
,
1

Hi there,

Again, I’m running Jetpack 6.2.2 on a JAO 64GB with a custom carrier board. I’m trying to setup ethernet, but running into a few hurdles. We intend to have UPHY for 10GB in future, alongside a 1GB with RGMI also. But for now, were just focusing on getting the RGMI up and running. This is what I’ve done so far (inline with the documentation and some previous forums):

Kindly confirm if there are any standout issues you see in the configuration, or perhaps point to the possible reason for the issues I’m seeing:

boot logs.txt (2.0 KB)

Thanks!

2

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

Based on the provided information, I’ll try to identify potential issues with the configuration and provide guidance on troubleshooting the Ethernet setup on the Jetson AGX Orin (JAO) with a custom carrier board.

PINMUX Configuration:
You’ve mentioned that you’ve configured the PINMUX exactly as described in the Jetson AGX Orin Platform Adaptation and Bring-Up guide. However, it’s essential to double-check the PINMUX configuration to ensure that it matches the custom carrier board’s pinout. A mismatch in PINMUX configuration can lead to issues with the Ethernet interface.

Device Tree Configuration:
You’ve provided the tegra234p37370000p3701.dtsi file, which appears to be correctly configured for RGMI Ethernet. However, I recommend verifying that the device tree file is correctly compiled and loaded during boot. You can check the boot logs for any device tree-related errors.

Boot Logs:
The provided boot logs (boot_logs.txt) don’t seem to indicate any specific errors related to the Ethernet interface. However, I recommend checking the logs for any messages related to the Ethernet driver or PHY initialization.

Device Tree on the Jetson:
The provided device tree file (USB.txt) seems to be unrelated to the Ethernet configuration. I recommend checking the device tree file that’s actually loaded on the Jetson, which should be tegra234p37370000p3701.dtb.

Possible Issues:

  1. PHY Initialization: Ensure that the PHY (Physical Layer) is correctly initialized and configured. You can check the boot logs for any messages related to PHY initialization.
  2. Ethernet Driver: Verify that the Ethernet driver is correctly loaded and configured. You can check the boot logs for any messages related to the Ethernet driver.
  3. PINMUX Configuration: Double-check the PINMUX configuration to ensure that it matches the custom carrier board’s pinout.
  4. Device Tree Configuration: Verify that the device tree file is correctly compiled and loaded during boot.

Recommendations:

  1. Verify PINMUX Configuration: Double-check the PINMUX configuration to ensure that it matches the custom carrier board’s pinout.
  2. Check Device Tree Configuration: Verify that the device tree file is correctly compiled and loaded during boot.
  3. Check Boot Logs: Check the boot logs for any messages related to the Ethernet driver or PHY initialization.
  4. Try a Different Ethernet Interface: If possible, try using a different Ethernet interface (e.g., USB-to-Ethernet adapter) to isolate the issue.

If none of these recommendations help resolve the issue, please provide more information about the custom carrier board’s design and the specific Ethernet interface you’re trying to use.

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

4

node 2310000 totally does not show in the log. It means your device tree change probably not take effect.

5

Good point, thanks. Whats strange is that the tegra234-p3737-0000-p3701.dtsi seems to be overriden by the tegra234-base-overlay.dtsi file. Kindly advise if its wise to edit the overlay file.

Here is the device tree on the target jetson:

USB.txt (2.7 KB)

This was after I’d rebuilt the dtb files and reflashed, so clearly the overlay is overriding, as the ethernet is disabled in the overlay.

6

I’ve just reflashed it having changed the overlay file, and this is the boot log i have now:

ETHERNET LOGS V2.txt (2.3 KB)

7

[ 15.015739] mdio_bus 2310000.ethernet: MDIO device at address 0 is missing.
[ 15.015750] nvethernet 2310000.ethernet: failed to connect PHY

Is the MDIO address really “0” as your hardware design? This value is decided by the hardware strap pin.

8

I haven’t tied the strapping pins to anything in my schematic, but because I followed the Jetson Adaptation guide, the strapping pins are pulled up within the module. However, when does the PINMUX get applied, or is it always assumed to be applied? Because if the chip is reset before the pins go high, the MDIO address is 0 when the DP83867 samples RD0, RD2 and RD4. If they are high, then my MDIO address is 15 (since all 4 strapping pins would be tied to the 1.8V of the Jetson).

9

Honestly, I am uncertain if this DP83867 PHY is able to work here.

This PHY has been tried by some other users before but seems none of them is able to make it work in the end.

Maybe using the Marvell 88E1512 PHY which has been validated by us would be a safer solution.

This user has a tool to locate where is the exact MDIO address running on their board.
Maybe you could refer to this post first