DP83822HF: DP83822HF PHY Mode Configuration via Firmware

Hello Bhavya,

There shouldn't be any limitation to switching into CU mode via registers. Is LED1 working properly on good boot states? One of the biggest tell-tale signs for CU vs FX is presence of a FLP when in CU mode. Is this present when you switch to CU via register via measuring with differential probe across TX line?

Also, it has been good practice to initiate a software restart (Reg 0x1F[14]) after any operational change. Has this also been implemented?

Hi Gerome,

please find answer for your questions.

1. Is LED1 working properly on good boot states? 

> yes. For normal state it is working fine.

2 One of the biggest tell-tale signs for CU vs FX is presence of a FLP when in CU mode. Is this present when you switch to CU via register via measuring with differential probe across TX line?

> I haven't check the signal on Tx line. But to identify the fiber mode I was using ethtool command and from there I identified that it is going into fiber mode.

3 It has been good practice to initiate a software restart (Reg 0x1F[14]) after any operational change. Has this also been implemented?

> No. I was doing it before the change. I will try this part and will let you know if it works.

Hello Bhavya,

Thanks for the information. I will be looking forward to the scopeshot on MDI as well as functional check if software restart helps your situation.

Sincerely,

Gerome

Hi,

I am able to change the bootstrap configuration through kernel. and after which it is working fine in copper mode. However I have found that even before doing the changes as well as after doing the changes I am facing one issue with respect to speed duplexing.

Based on my analysis, I would like to share the following observations:

1. The PHY status register (0x10) does not reflect the expected updates.
2. The recent kernel modifications appear to have no impact on the issue, as similar behavior was observed even without these changes.
3. There is a noticeable mismatch between the information provided by ethtool and the values read from the PHY status register.
4. The behavior remains consistent regardless of whether the system is in a failure mode or operating under normal conditions.

For clarity:

• Failure Mode refers to the scenario where the device initially boots into Fiber mode, and the kernel attempts to switch it to Copper mode via register updates.
• Normal Mode refers to the scenario where the device boots directly into Copper mode through bootstrap configuration, without requiring any kernel-level register changes

Regards,

Bhavya

Kindly review the attached data and share your feedback or suggestions.TiSpeedDuplexingData.xlsx

Hi everyone,

To add on I would like to clarify that the issue I am currently facing is not related to any kernel changes. I have verified the behavior without applying any kernel modifications, and the results remain consistent.

Additionally, I have tested the setup using two standard managed switches—Hirschmann RSPS25 and Siemens Scalance XC206-2. The results observed with these switches are identical to those obtained with the PC for the 10 Mbps and 100 Mbps speeds, indicating that the issue persists across different hardware configurations.

At present, the configurations for 10 Mbps Half/Full Duplex and 100 Mbps Half/Full Duplex are not functioning as expected. And the switches I mentioned doesn’t support 1Gbps speed so currently I need to identify a standard switch that supports 1 Gbps, and I will share the results of that test shortly.

In the meantime, I suggest we focus our efforts on resolving the issues related to the 10 Mbps and 100 Mbps configurations.

Please feel free to reach out if you have any questions or if there are other concerns you'd like me to look into. 

Regards,

Bhavya 

Hi Nick,

please find the response of your below query

1. CPSW Ethernet vs PRU EthernetCurrently we are using PRU firmware. I am not understanding the point of cpsw vs PRU as I have never tried it with CPSW so I have no idea with respect to that. Could you please clarify this point.
2. SDK version & kernel version (if not using a TI SDK)TI SDK 8.02  
3. what are the kernel modificationsHave shared you over mail

If you have any other doubt or query do let me know.

Regards,

Bhavya

Hi Nick and Gerome,

I was trying to debug on this issue that why the internal registers values of PHY are not updating properly and I found that in my DTS file ti,no-half-duplex; was enabled and I disabled this part and added some other related stuff as well into it. I have shared you the old and new DTS file over mail. But still the issue of duplex is there. 

If you have any other suggestion or inputs in which I should check so that we would be able to find the issue easily than do let me know.

Regards,

Bhavya

Hi,

while investigating on issue related to speed configuration in the emac_adjust_link() function within the prueth_core.c file. During testing with a 1Gbps link, I observed that the function is initially entering the default condition where speed is not detected. However, it subsequently transitions to a 100Mbps full-duplex mode unexpectedly.

To address this, I modified the default condition to set the speed to 10Mbps half-duplex. Despite this change, the system still switches to 100Mbps full-duplex. Below is the relevant code snippet:

following is the code snippet

else if (emac->link) {
		new_state = true;
		emac->link = 0;
		/* defaults for no link */
                printk("default to 10 half \n");
		/* f/w only support 10 or 100 */
		emac->speed = SPEED_10;

		/* half duplex may not be supported by f/w */
		emac->duplex = DUPLEX_HALF;
	}

And the corresponding log output:

[  287.137600] emac_update_phystatus 
[  287.137626] default to 10 half 
[  287.137646] prueth pruss1-eth: emac_update_phystatus 
[  287.137684] prueth pruss1-eth eth0: Link is Down
[  287.142189] remoteproc remoteproc1: stopped remote processor 54434000.pru
[  287.142438] net eth0: stopped

If you have any insights into other areas of the code or firmware that might be influencing the speed configuration, I would greatly appreciate your guidance. I will continue investigating from my end and attempt to identify the root cause.

Thank you for your support.

Regards,

Bhavya

Hello Bhavya,

I will set aside some time on Friday to take a look at the information that you have shared.

Regards,

Nick

Hi Nick,

could you please share your insights.

Regards,

Bhavya

Hello Bhavya,

Apologies for the delayed responses from this end, I had a death in the family a few days ago. I will be taking additional time off on Friday and Monday.

AM437x PRU Ethernet on Linux SDK 8.2 only support 100M FD.

If you want gigabit link speed, you would need to use the CPSW interface instead. The PRU-ICSS on AM437x is limited to 100M link speeds (though the PRU_ICSSG on devices like AM64x can go up to gigabit speeds).

PRU Ethernet support was dropped in AM437x SDKs 9.1 & 9.3, but we are re-adding support for PRU Ethernet in the upcoming AM437x SDK 11.1 (Linux kernel 6.12). I have been told that they are adding support for 10M FD and HD, and 100M HD. I am asking for confirmation that these other speeds have been tested.

Regards,

Nick

Hello Bhavya,

Summary - please run link speed tests with a Linux link partner, not Windows 

As per our offline discussion, you were seeing links established at unexpected frequencies and duplexes when the AM437x was set to autonegotiate, and when the link partner was set to a specific frequency:

However, you were using a GUI interface on a Windows computer to set the link speed, and there was no way for you to actually see the settings take effect on the Windows side.

I suspect that Windows was "lying" to you. Please use a link partner running Linux (for example, a computer running Ubuntu, or another AMxx Linux board). That way you can actually verify your link settings, and see your statistics from the partner side with ethtool:
* verify that you are at the speed and duplex that you expect
* link status should be yes
* should see both TX and RX packets

Why do I think these tests are not valid? 

The PHYs negotiate a link speed between the 2 PHYs. So if the MAC could only interact with the PHY at a fixed link setting (e.g., 10M HD), then the OS needs to tell the PHY what the allowable link speeds are. If the link cannot be set up at one of the allowable link speeds, then I would expect to see that the link fails to be established. Pings should be impossible.

Let's look at the 1Gbps full duplex usecase. Let's pretend that something got messed up between the Windows MAC and the PHY, and the PHY was allowed to establish a 100Mbps full duplex link even though the MAC was in a fixed 1Gbps link. What would happen?

The MAC which is set to fixed link mode will generate a TX_CLK and TX data at 1G rates. And the PHY would set the RX_CLK and RX data to be at 100M rates. Then the MAC and the PHY would fail to talk to each other. A ping should be impossible.

As far as I can tell, AM437x seems to be behaving as expected here with the autonegotiate settings. If the link partner is the one enforcing a lower or higher link speed, then it is probably the link partner who is misbehaving when a different link speed is established.

Regards,

Nick

Hi Nick,

Thank you for your prompt response.

I had also suspected that my Windows system might not be performing as expected, which led me to conduct further testing using a standard managed switch. The results clearly show consistent behavior across different setups—whether using a PC-attached LAN card, a Linux system with an external adapter and auto-negotiation disabled, or a managed switch.

Following the recent changes made to the DTS file, I’ve noticed a shift in behavior as previously described. I would appreciate it if you could kindly review the DTS modifications and confirm whether they are correct.

Additionally, I’ve shared my observations over email regarding IEEE standard compliance. I would be grateful if you could verify those findings, as the results obtained on the Linux system align with them.

One specific point to highlight:

• When executing the command ethtool -s eth0 speed 1000 duplex full autoneg on, the device does not fall back to 100 Mbps Full Duplex.
• However, when using ethtool -s eth0 autoneg on, the device does fall back to 100 Mbps Full Duplex as expected.

Other than this, everything appears to be functioning correctly.

Please find the attached data for your convivence I have also shared the same excel in the mail.

Looking forward to your confirmation and feedback.

Regards,

Bhavya

Hello Bhavya,

Is this command the command that you are running on the Linux system, or on the AM437x board? Please provide the commands that are used on both sides of the link.

Regards,

Nick

Hi Nick,

I have provided this command over the Linux system. I am having linux PC through which I gave following commands

 ethtool -s eth0 speed xx duplex xx autoneg off

ethtool -s eth0 speed xx duplex xx autoneg on

same I have mentioned in the top column of the results. (such as Scenario 1 Autoneg Off command :  ethtool -s eth0 speed xx duplex xx autoneg on). If you have any other doubt than do let me know.

Regards,

Bhavya 

Hi Nick,

in the device side I will be keeping it in auto negotiation mode only there won't be any change from the device end. So from device end I am not giving any command. I am only giving command from the linux system which has been mentioned earlier.

Regards,

Bhavya