Jetson Nano Ethernet Link with 100MBit Transformer

We have build a custom carrier board for the Jetson Nano and see some strange behavior regarding Ethernet link. We connected a 10/100BaseT LAN-Transformer instead of of Gigabit to reduce power consumption. This works generally well. But detecting the Ethernet Link to go down, when removing the Ethernet cable does not work reliable. So the Jetson “thinks” it is still connected to Ethernet if we check it with ip or ethtool commands.

In some random cases on some devices the link change is seen, in others we do not see the link go down. We have noticed this behavior when connecting to 100 MBit switches as well as on 1 GBit switches.

We already tried to use the mainline r8169 driver instead of the bundled Realtek driver. For both drivers we see the same behavior. We also did an Ethernet compliance test which succeeded.

The LAN-Transformer is connected to pins 184/186 and 190/192. Link and activity LED’s are connected to 188 and 194.

Do you have any ideas what may cause this issue or give any hints on solving it?

In some random cases on some devices the link change is seen

Does such “device” mean ethernet hub ? Will you see same behavior if you use the same device with nv devkit?

Sorry, by device I mean our custom board. So for some boards of ours we see it working in seemingly random situations. With the devkit and the identical firmware it works always as expected. We did not see any issues with the devkit.

So in term of Ethernet the only difference is that MDI2 (196/198) and MDI3 (202/204) are not connected since we have only the 100 MBit Transformer.

So using same software on different carrier board, you will see different behavior (some of your carrier boards have such issue), right?

Yes, but this occurs in seemingly random situations. We have at least one board where it worked before and now it does not. On another board we noticed the issue and now it does work. So the issue is not reproducible. Most of the times (it seems) it does not work as expected.

This does not sound like a pure software issue to me. Could you make sure every board is using the same software?

Yes, I also think this may not be caused by the Software. We used exactly the same Software for testing this. On the devkit we did not see any issues. On our custom boards we see it randomly occurring like described.

Could you share the dmesg when you reproduce the error?

I am sorry but I cannot, since there is no error. If the issue occurres the device does not show any reaction to unplugging the Ethernet cable. What I would expect is this:

[   80.863556] r8169 0000:01:00.0 eth0: link up
[   82.061300] r8169 0000:01:00.0 eth0: link down

(recorded on the devkit when pluggin and unplugging)

With our custom board I only see the first message when plugging the cable.

And unplug the cable does not have eth0: link down?

Yes, exactly. This is the problem we observe.

So when I double check this in case we have the issue on our custom board I see the link still there although no cable is connected anymore:

$ ethtool eth0 | grep detected
        Link detected: yes
$ ip link show dev eth0
3: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP mode DEFAULT group default qlen 1000
   link/ether 00:##:##:##:##:## brd ff:ff:ff:ff:ff:ff

According to the driver code, what I can tell is this issue should be hardware issue.

The “link up/down” is triggered by below function.

return RTL_R8(PHYstatus) & LinkStatus;

Thus, if phy gives wrong status, it will still return connected. Please see if you are able to contact Realtek and see if they have similar cases before.

Okay. Thanks.
We will try this.

The issue is that we have no direct contact to Realtek and there is no datasheet publicly available, which contains sufficient information.
Can you provide us with a contact to Realtek?
Can you provide us a datasheet with detailed information regarding the used PHY?

1 Like