AM625: The Ethernet cable is no more detected, the reset of the PHY chip is also not detected.

Part Number: AM625
Other Parts Discussed in Thread: SK-AM62B

Tool/software:

Hello,

We encounter an issue with our board based on the AM256 EVM board.

Some times the ethernet interface is shown as down by linux-rt (TISDK 09.02) when the ethernet cable is still connected to a switch.

The LED of the Ethernet connector on the switch and the LED on the AM625 board are switch off.

When the cable is unplugged and plugged again, there no detection under Linux and the LED are still switch off.

Using GPIO a reset is done on the PHY chipset, but it doesn't fix the issue.

The only way to get the Ethernet link available again is to reboot the AM625 board, because the command 'systemctl restart systemd-networkd' has no effect.

There is no trace log in linux showing a problem, the last trace log in the /var/log/messages and journalctl show that the link is UP.

But the command 'ip a' shows that the link is DOWN.

Is there any known issue regarding the ethernet controller on AM625, that can lead to such behavior.

What tests can be done to identify root cause of the issue ?

Could you provide me a method to reset the ethernet controller on the AM625 side ?

Thanks for you help.

Alexis.

  • Hello Alexis, 

    Some times the ethernet interface is shown as down by linux-rt (TISDK 09.02) when the ethernet cable is still connected to a switch.

    To my knowledge, there was no known issue on SDK 09.02 Linux RT that results in this behavior on an SK-AM62B EVM. Does this issue occur right away when your custom designed board is booted up or does the link go down after some time?

    How many ethernet interfaces do you have on your board? If you have more than one enabled, does this issue occur on just one interface? 

    Can you share a console log when this issue occurs? (Including the boot up logs)

    When the cable is unplugged and plugged again, there no detection under Linux and the LED are still switch off.

    Using GPIO a reset is done on the PHY chipset, but it doesn't fix the issue.

    The only way to get the Ethernet link available again is to reboot the AM625 board, because the command 'systemctl restart systemd-networkd' has no effect.

    Have you tried running "ip link set dev <ethernet iface name> up" to see if the link goes up? (Where "ethernet iface name" is your ethernet interface name)

    -Daolin

  • Hi Daolin,

    The issue has been seen on our custom designed board during functional test, but is not occurs at 100%. We don't have a specific test to reproduce this issue.

    The issue is has been seen after the Linux and our Application is running for a while.

    We have 3 ethernet interface the 2 ports on the AM625 and a wired SMSC95xx USB to ethernet adpater.

    Only 1 port on the AM625 was connect when the issue occurs, I don't test to wire this other one during the analyze of the issue.

    I tried the command "ip link set dev <ethernet iface name> up" but it have no effect.

    I also try a loop with the command "systemctl restart systemd-netword" every 30 secondes during the full night, but the issue doesn't occur.

    I have no the trace log, because I reseted the board. I will give it when the next time the issue will be seen.

    Is there any way to reset the ethernet controller from Linux, and make the linux driver restart the PHY configuration?

    Thanks for your help.

    Alexis.

  • Hi Alexis,

    I tried the command "ip link set dev <ethernet iface name> up" but it have no effect.

    Just double checking, you replaced the <ethernet iface name> with the name of the Ethernet interface experiencing the issue? For example, "ip link set dev eth0 up".

    Is there any way to reset the ethernet controller from Linux, and make the linux driver restart the PHY configuration?

    Let me check with a colleague on this. To my knowledge, the setup of the PHY configuration is closely tied with the Linux kernel boot up process (reading the PHY properties from the DTS, setting up the PHY driver according to the driver's probe function, etc).

    If you see the issue again, you could try

    1. checking the link status of the interface with "ethtool <eth iface name>"

    2. if the link status shows that it's down, try reading the Ethernet PHY registers to determine if the PHY is potentially left in a bad state

    3. if there is a PHY register to restart auto-negotiation process, try to enable that

    Additionally, have you tried "systemctl status systemd-networkd" to check the status of the network service when the issue occurred?

    -Daolin