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