AM625: Error that eth1 is down when eth0 is down

Jack

Part Number: AM625

Tool/software:

Hi AM62x Champ !

As you can see from the original thread, the customer has been unable to resolve the issue for a long time and is considering replacing the Eth PHY IC with a third-party product.

So I'm hoping that the issue will be resolved on boards with the original PHY, but I don't see any progress.

If you do “ifconfig eth0 down” in the shell, the network phy of the kernel will be set to power-done mode in the last information part of each process.
This means that the linux kernel phy driver will set bit-11 of the BMCR, which will cause the issue mentioned below.

Also, this phenomenon occurs even if PHY-0 is put into 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, but 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 as GPIO.

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

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

ally_mcpu.zip

Please review their attached their dts file,

If this issue is caused by setting BMCR bit11 on ‘ifconfig eth0 down’ command, please let us know how we can improve it.

Thanks.

Regards,

Jack

9 months ago

0 Daolin Qiu 9 months ago

TI__Genius 16425 points

Hello Jack,

First, I have a couple of questions.

1. Just to clarify, upon a scan of the previous correspondence and the details in this thread you are reporting that running "ifconfig eth0 down" will bring down both eth0 and eth1 interfaces?

2. It is unclear to me what the testing setup is like, are both eth0 and eth1 connected to a known working link partner device? Is the connection through eth0 and eth1 a direct link or through a network switch? Are the devices connected to eth0 and eth1 different devices?

3. Additionally, does the issue (both eth0 and eth1 are down when ifconfig eth0 down is run) occur when the cable connected to eth0 is disconnected?

4. Instead of running "ifconfig eth0 down" can you instead run "ip link set dev eth0 down". ifconfig is not as up to date as the ip (from iproute2) utility tool. Do you see the same issue with this command?

5. What is the Linux SDK version the customer is using?

-Daolin

0 Jack 8 months ago in reply to Daolin Qiu

Mastermind 9145 points

Hi Daolin Qui

Thanks for your kind reply. Please find their feedback toward your questions.

1. Just to clarify, upon a scan of the previous correspondence and the details in this thread you are reporting that running "ifconfig eth0 down" will bring down both eth0 and eth1 interfaces?

-> It depends on the board. Some boards will have eth0 down and eth1 will be affected, some boards will have eth1 down and eth0 will be affected.
Of course, there are also normal, unaffected boards where neither is affected.

-> It is independent of the state of the Ethernet cable connection. Affected boards are affected even when no cable is connected, they are affected when they have a 100Mbps connection, they are affected when they have a 1Gbps connection, and they behave the same whether they are connected to a Hub or directly.
This means that we suspect that the problem is not with the cable connection, but with something H/W.

3. Additionally, does the issue (both eth0 and eth1 are down when ifconfig eth0 down is run) occur when the cable connected to eth0 is disconnected?

-> Please refer to the answers above for answers to this question.

5. What is the Linux SDK version the customer is using?

-> I used SDK-09.00.00.03, and I used the git file that you told me at that time and processed it as follows.
$ ./oe-layertool-setup.sh -f configs/processor-sdk/processor-sdk-09.00.00-config.txt

Thanks a lot.

Best Regards,

Jack

0 Daolin Qiu 8 months ago in reply to Jack

TI__Genius 16425 points

Hi Jack,

Thanks for sharing the answers to my questions.

Jack said:
4. Instead of running "ifconfig eth0 down" can you instead run "ip link set dev eth0 down". ifconfig is not as up to date as the ip (from iproute2) utility tool. Do you see the same issue with this command?

Were you able to ask about trying the above?

Based on the last communication on the other thread (https://e2e.ti.com/support/interface-group/interface/f/interface-forum/1409322/dp83867ir-inquiry-on-the-cause-of-ethernet-phy-transceiver-error/5429370#5429370) Evan from the TI Ethernet PHY team was suggesting to use phytool to confirm register writes only apply to one phy. Was that able to be done?

-Daolin

0 Jack 8 months ago in reply to Daolin Qiu

Mastermind 9145 points

Hi Daolin Qiu

Yes, Customer did run "ip link set dev eth0 down" in addition to "ifconfig eth0 down". However the result is same.

This customer believe the issue comes from H/W side rather than SW.

Thanks.

Best Regards,

Jack

Captured from korean message sent from email

"해 보았습니다. 동일한 현상이 발생합니다.

문제 제기일때부터 반복적으로 예기하는 것은 이 문제는 S/W 적인 문제가 아니라 전원 및 PCB 를 포함한 어떠한 H/W 적인 문제로 생각합니다."

0 Daolin Qiu 8 months ago in reply to Daolin Qiu

TI__Genius 16425 points

Hi Jack,

Thanks for your response.

Jack said:
This customer believe the issue comes from H/W side rather than SW.

Daolin Qiu said:
Based on the last communication on the other thread (https://e2e.ti.com/support/interface-group/interface/f/interface-forum/1409322/dp83867ir-inquiry-on-the-cause-of-ethernet-phy-transceiver-error/5429370#5429370) Evan from the TI Ethernet PHY team was suggesting to use phytool to confirm register writes only apply to one phy. Was that able to be done?

The suggestions given from the PHY team could help with coming to a conclusion if the problem is from the H/W side and potentially where that problem lies. Has the customer tried this out yet? If they have any questions with this, I can help direct to the TI Ethernet PHY team for support on this.

-Daolin

0 Jack 8 months ago in reply to Daolin Qiu

Mastermind 9145 points

Hi Daolin

Thanks for your kind support.

During the test conducted by the customer, they created a mdio-tool to read / write the phy register with mdio-bus to check the status.

The current connection status is that 2 PHYs are connected to 1 MDIO-BUS, so I think you are considering the problem of MDIO-BUS, but when I wrote -> read each PHY, it worked normally.
(Except for the PHY SLEEP MODE bit, etc., there was no case of incorrect I/O on general register RW).

And they also did the following tests.

They used the two GPIOs that were implemented for the LEDs to separate the MDIOs as shown in the figure above.
(They disconnected the MDIO-BUS connected to the existing PHY-1 and connected the 2 GPIOs).

Naturally, they let the LINUX kernel handle the MDIO protocol using the GPIOs.
Even with the MDIO-BUS disconnected like this, the mentioned phenomenon still occurred.
Thus, they proved that the register rw error on the mdio-bus was not the cause.

Thanks.

Regards,

Jack

0 Daolin Qiu 8 months ago in reply to Jack

TI__Genius 16425 points

Hello Jack,

Can you share a schematic snippet of where the CPSW signals are connected? The idea is to check the connections on both PHYs to see if there are any potentially shared signals that might be causing this issue.

-Daolin