DP83867IR: Inquiry on the cause of Ethernet PHY transceiver error

Hi JH,

Can you please share the schematic? I would like to check if the PHYs share any signaling to the AM62.

My current assumption is that disabling one interface may disable some shared signals to the other PHY, causing link down.

If each PHY's signaling to the MAC is independent, the issue may be on the software-level.

Thank you,

Evan

Hi Evan,

Thank you for your reply.

I sent a friendship request because the customer asked me to keep the schematics private.

BR,

JH

Hi Evan

Please find their test log when run ethtool.

ally_nbiu_m:[~]#
ally_nbiu_m:[~]# ethtool -i eth0
driver: am65-cpsw-nuss
version: 6.1.46-dirty
firmware-version:
expansion-rom-version:
bus-info: 8000000.ethernet
supports-statistics: yes
supports-test: no
supports-eeprom-access: no
supports-register-dump: yes
supports-priv-flags: yes

ally_nbiu_m:[~]#
ally_nbiu_m:[~]#
ally_nbiu_m:[~]# ethtool -i eth1
driver: am65-cpsw-nuss
version: 6.1.46-dirty
firmware-version:
expansion-rom-version:
bus-info: 8000000.ethernet
supports-statistics: yes
supports-test: no
supports-eeprom-access: no
supports-register-dump: yes
supports-priv-flags: yes
ally_nbiu_m:[~]#
ally_nbiu_m:[~]#
ally_nbiu_m:[~]#

And they use the different phy address as below.

&mdio {
    phy0: ethernet-phy@0 {
        reg = <0>;
    };

    phy1: ethernet-phy@1 {
        reg = <1>;
    };
};

If you need any other result of commands. Please let us know. 

Thanks.

Best Regards, 

Jack

Hello,

Evan is OoO today and will be back tomorrow. 

Sincerely,

Gerome

Hi Jack, JH,

The Ethtool log and PHY address configuration looks good to me.

For the schematic, please email me at e-mayhew@ti.com .

Does the customer have a failure rate recorded for this issue?

Thank you,

Evan

Hi Evan,

Thank you for your help.

The customer said that they tested it by implementing distinct individually (one is mdc/mdio, the other is gpio), but there was no change in the issue.

BR,

JH

Hi EVAN
Thanks for your kind answer.
The customer has also checked the separate driver loading for the two phy chips, and they are loading them separately, and they are not finding anything unusual.
Can you please review the PCB gerber data they have created? It was exported as PDF file.

nbiu_io_v02gerber.zip

Thanks.

Best Regards, 

Jack

Hi Evan.

Please find their addition test results. 

It occurs on 5 out of 6 boards, and the symptoms are as follows.

[1] 2 boards, when eth1 is down, eth0 is down (when eth0 is down, eth1 is not down)
[2] 3 boards, When eth0 is down, eth1 is also down (when eth1 is down, eth0 is not down)
[3] 2 units (4 chips) from [1] above, with good ones together, will have the same result.
The problem is only in the “ifconfig down” command part, otherwise the phy chip behavior is fine.
They are thinking that the phy chip already mounted on the board cannot be the problem,
so they see no reason to try a new chip at all.

Thanks.

Regards, 

Jack

Hi Jack,

Thanks for sharing further details on the failure rate and tests.

I do not think this is a schematic or layout issue, the MAC connections to each PHY are independent.

This seems to be a firmware issue with how MPU is recognizing and assigning each eth interface.

Does the problem only occur when running "ifconfig eth<x> down" , or also when disconnecting the cable on one of the eth<x> interfaces?

Could the full DTS for the processor be shared? I'd like to review how the MAC ports are assigned.

Thanks,
Evan

Hi Evan

Thanks for your kind support.

We have additional updates from the customer.

Here is the dts file what I shared with you last weekend.This DTS is based on the DTS of the LINUX kernel used by the TI SDK.

ally_mcpu.dts.txt

This is the behaviour description of the phenomenon when eth0 is down and eth1 is the problem board.

When they do ‘ifconfig eth0 down’ in the shell, it seems to set the kernel's network phy driver to power-done mode in the last info part of each process.

This means that the linux kernel phy driver will set bit-11 of the BMCR, which will cause the problem mentioned below.

Also, this phenomenon occurs even if you put PHY-0 in RESET state using GPIO pin.

When the register of PHY-1 is read in this state, an abnormal value is read.

Since the PHY STATUS REGISTER returns an abnormal value, ETH1 is net down and also fails to operate normally.

It is difficult for me to know whether the actual PHY READ/WRITE operation is the problem or the status inside the PHY is the problem. However, it seems that the status inside the PHY has changed rather than the READ/WRITE operation because it is the same even when the MDIO-BUS of PHY-1 is separated into GPIO.

To eliminate this phenomenon, set BIT-11 to 0, or in case of RESET using GPIO, release RESET and reinitialise NETWORK, and it will work normally.

In other words, it seems to occur in POWER-DOWN MODE using REGISTER or RESET state by RESET SIGINAL of PHY.

So far, the status is as shown above.

In addition, I was not able to share the logs with them, but according to them, they confirmed that they loaded the bus-info or driver separately from eth0 and eth1 in the device tree, and they did not add any code to the PHY driver to control eth0 and eth1 separately, as shown below.

static int phy_suspend(struct phy_device *phydev)
{
if (strcmp(phydev->attached_dev->name, "eth1") == 0) {
// eth1 PHY is not power down
return 0;
}

// Other PHYs are power down
phy_modify(phydev, MII_BMCR, BMCR_POWERDOWN, BMCR_POWERDOWN);
return 0;
}

If I need to modify the code to allow the PHY driver to be controlled for individual interfaces, I would appreciate a guide,
If there is a test method to control it separately from user-space like ethertool or sysfs, please guide.

Thanks.

Best Regards, 

Jack 

Hi Jack,

Please refer to this FAQ for common Linux utilities for register access:

https://e2e.ti.com/support/interface-group/interface/f/interface-forum/1164499/faq-how-to-read-and-write-ethernet-phy-registers-using-a-linux-terminal?tisearch=e2e-sitesearch&keymatch=phytool#

If phytool can be used, I would like to confirm that manual register writes to a specific PHY ID only apply to the one PHY. This will help confirm if the PHY ID strapping is distinct, and the ifconfig issue is not an issue with MDIO bus.

Thank you,

Evan