AM6442: On the custom board design with AM6442 SoC, CPSW works, but ICSS does not work.

Ahmet: I believe you must be using TI AM64X Linux SDK v9.2 - true? (e2e support really needs to know the SDK version, not the Linux kernel version; TI modifies and excludes some things from the Linux kernel version)

Nevertheless, you have an interesting question.

regards

Jim (ex TI-er '82-'97)

Hi Jim Mrowca

Sorry for delayed response.

Jim Mrowca said:

I believe you must be using

Yes, I am using processor SDK version 09.02.01.09.

Ahmet:

 I am a former TI employee. 

Surprised someone has not addressed this.  I would suggest (+) Daolin Qiu's Profile - Daolin Qiu - TI E2E support forums in Dallas might be a starting point of contact.

regards

Jim (ex-TI '82-'97)

Hi Jim

I hope Daolin Qiu helps me.

Thanks

Ahmet Baser said:

I see that the PHY connection is established, but I cannot ping it

Can you share the PHY register dumps: 0x0 to 0xF for both Ports in ICSSG case.

Is ICSSG and PHY configured in RGMII mode?

> 100 Mbit full duplex configurations.

How did you enforce this?

Is your schematics matches TMDS64EVM when it comes to RGMII pins?

You might also want to look at ICSSG HW stats to debug this further...

This is Register addresses of phy at address 0x3 (icssg1_phy1)

PHY: 3 | REG: 0 --> 0x1140
PHY: 3 | REG: 1 --> 0x796d
PHY: 3 | REG: 2 --> 0x2000
PHY: 3 | REG: 3 --> 0xa0f3
PHY: 3 | REG: 4 --> 0x0101
PHY: 3 | REG: 5 --> 0xc1e1
PHY: 3 | REG: 6 --> 0x006f
PHY: 3 | REG: 7 --> 0x2001
PHY: 3 | REG: 8 --> 0x4806
PHY: 3 | REG: 9 --> 0x0800
PHY: 3 | REG: 10 --> 0x0800
PHY: 3 | REG: 11 --> 0x0000
PHY: 3 | REG: 12 --> 0x0000
PHY: 3 | REG: 13 --> 0x401f
PHY: 3 | REG: 14 --> 0x00d2
PHY: 3 | REG: 15 --> 0xf000
PHY: 3 | REG: 16 --> 0x5048
PHY: 3 | REG: 17 --> 0x7c02
PHY: 3 | REG: 18 --> 0x0000
PHY: 3 | REG: 19 --> 0x9ce0
PHY: 3 | REG: 20 --> 0x2bc7
PHY: 3 | REG: 21 --> 0x0000
PHY: 3 | REG: 22 --> 0x0000
PHY: 3 | REG: 23 --> 0x0040
PHY: 3 | REG: 24 --> 0x6150
PHY: 3 | REG: 25 --> 0x4444
PHY: 3 | REG: 26 --> 0x0002
PHY: 3 | REG: 27 --> 0x0000
PHY: 3 | REG: 28 --> 0x0000
PHY: 3 | REG: 29 --> 0x0000
PHY: 3 | REG: 30 --> 0x0012
PHY: 3 | REG: 31 --> 0x0000

PratheeshGangadhar said:

Is ICSSG and PHY configured in RGMII mode?

Yes,You can see it in the form of "phy-mode = "rgmii-id"" in the dts file I shared above.

PratheeshGangadhar said:

How did you enforce this?

with "ethtool -s eth0 speed 100 duplex full" command

PratheeshGangadhar said:

Is your schematics matches TMDS64EVM when it comes to RGMII pins?

yes. I can ping in cpsw mode with same pinout 

I hope you will get back to me soon with good news. PratheeshGangadhar

Thanks

PratheeshGangadhar said:

Can you share the PHY register dumps: 0x0 to 0xF for both Ports in ICSSG case.

Sorry, there was a typo, can you share 0x0 to 0x1F (for both ports)

Hi PratheeshGangadhar

I updated my answer above to include 0x0 to 0x1F. Also I only use one port for icssg (eth0).

> REG: 19  (0x13) --> 0x9ce0

This indicates Auto Negotiation Error, Overflow / underflow has been detected in one of ADC's FIFOs. May be a misconfiguration of PHY settings. Assigning this thread to PHY expert to check

Hi Ahmet,

In the case with link up but failure to ping in RGMII, the issue is likely with RGMII timing requirements.

I recommend iterating with RGMII internal delay settings in the PHY and attempting ping for each. This can be configured through registers or device tree:

0x32[1:0] = '00' -> '01' -> '10' -> '11'

Does ping fail for each of these settings?

Thank you,

Evan

Hi Evan Mayhew

Thanks for your reply.

rx-internal-delay-ps and tx-internal-delay-ps values ​​are 2 ns for icss as seen in the dts file above.

Evan Mayhew said:

0x32[1:0] = '00' -> '01' -> '10' -> '11'

I don't understand how to make this setting in device tree. Can you explain in more detail?

Thanks.

Hi Ahmet,

Setting delay to 0ns should set device in align mode.

// 0ps = align mode
// delay options: {1, 1.5, 2, 3, 3.5}ns
ti,rx-internal-delay-ps = <2000>; 
ti,tx-internal-delay-ps = <2000>;

I'm not certain if this device tree setting is taking effect in the PHY, so I recommend writing the values in registers 0x32 and 0x86 manually as the first step during communication tests.

Thank you,

Evan

Hi Evan Mayhew

In the dp83869_config_init() function in the dp83869.c file, I wrote the 0th and 1st bits of the 0x32 address as 0-0, 0-1, 1-0, 1-1 as you said and tried it. However, I couldn't see any difference, so it didn't solve my problem.

Do you have any idea?

Thanks.

Hi Ahmet,

Thanks for confirming these tests.

We can run through two loopback tests to isolate the issue to the MDI or MAC signal chain:

1) Reverse loopback (0x16[5] = '1'). Send packets from the link partner - verify packets looped back without error on MDI side.

2) MAC-side loopback (0x16[2] = '1'). Send packets from the MAC - verify packets looped back without error to MAC.

If the root cause is RGMII timing violation, I expect (1) to pass and (2) to fail. In this case, we can further adjust the RGMII timing delays in shift mode with register 0x86.

Could you also please share the "ethtool" log for the port after ping? This will help confirm if MAC is receiving packets and any errors seen.

Thank you,
Evan

Hi Evan Mayhew

These are "ethtool -S eth0" logs after tests

Reverse loopback
-------------------
rx_good_frames = 0
rx_broadcast_frames = 0
rx_multicast_frames = 0
rx_crc_error_frames = 0
rx_mii_error_frames = 0
rx_odd_nibble_frames = 0
rx_frame_max_size = 14000
rx_max_size_error_frames = 0
rx_frame_min_size = 448
rx_min_size_error_frames = 0
rx_overrun_frames = 0
rx_class0_hits = 0
rx_class1_hits = 0
rx_class2_hits = 0
rx_class3_hits = 0
rx_class4_hits = 0
rx_class5_hits = 0
rx_class6_hits = 0
rx_class7_hits = 0
rx_class8_hits = 0
rx_class9_hits = 0
rx_class10_hits = 0
rx_class11_hits = 0
rx_class12_hits = 0
rx_class13_hits = 0
rx_class14_hits = 0
rx_class15_hits = 0
rx_smd_frags = 0
rx_bucket1_size = 448
rx_bucket2_size = 896
rx_bucket3_size = 1792
rx_bucket4_size = 3584
rx_64B_frames = 0
rx_bucket1_frames = 0
rx_bucket2_frames = 0
rx_bucket3_frames = 0
rx_bucket4_frames = 0
rx_bucket5_frames = 0
rx_total_bytes = 0
rx_tx_total_bytes = 0
tx_good_frames = 0
tx_broadcast_frames = 0
tx_multicast_frames = 0
tx_odd_nibble_frames = 0
tx_underflow_errors = 0
tx_frame_max_size = 14000
tx_max_size_error_frames = 0
tx_frame_min_size = 448
tx_min_size_error_frames = 0
tx_bucket1_size = 448
tx_bucket2_size = 896
tx_bucket3_size = 1792
tx_bucket4_size = 3584
tx_64B_frames = 0
tx_bucket1_frames = 0
tx_bucket2_frames = 0
tx_bucket3_frames = 0
tx_bucket4_frames = 0
tx_bucket5_frames = 0
tx_total_bytes = 0

MAC-side loopback
-----------------
rx_good_frames = 0
rx_broadcast_frames = 0
rx_multicast_frames = 0
rx_crc_error_frames = 0
rx_mii_error_frames = 0
rx_odd_nibble_frames = 0
rx_frame_max_size = 28000
rx_max_size_error_frames = 0
rx_frame_min_size = 896
rx_min_size_error_frames = 0
rx_overrun_frames = 0
rx_class0_hits = 0
rx_class1_hits = 0
rx_class2_hits = 0
rx_class3_hits = 0
rx_class4_hits = 0
rx_class5_hits = 0
rx_class6_hits = 0
rx_class7_hits = 0
rx_class8_hits = 0
rx_class9_hits = 0
rx_class10_hits = 0
rx_class11_hits = 0
rx_class12_hits = 0
rx_class13_hits = 0
rx_class14_hits = 0
rx_class15_hits = 0
rx_smd_frags = 0
rx_bucket1_size = 896
rx_bucket2_size = 1792
rx_bucket3_size = 3584
rx_bucket4_size = 7168
rx_64B_frames = 0
rx_bucket1_frames = 0
rx_bucket2_frames = 0
rx_bucket3_frames = 0
rx_bucket4_frames = 0
rx_bucket5_frames = 0
rx_total_bytes = 0
rx_tx_total_bytes = 0
tx_good_frames = 0
tx_broadcast_frames = 0
tx_multicast_frames = 0
tx_odd_nibble_frames = 0
tx_underflow_errors = 0
tx_frame_max_size = 28000
tx_max_size_error_frames = 0
tx_frame_min_size = 896
tx_min_size_error_frames = 0
tx_bucket1_size = 896
tx_bucket2_size = 1792
tx_bucket3_size = 3584
tx_bucket4_size = 7168
tx_64B_frames = 0
tx_bucket1_frames = 0
tx_bucket2_frames = 0
tx_bucket3_frames = 0
tx_bucket4_frames = 0
tx_bucket5_frames = 0
tx_total_bytes = 0

Also, in MAC-side loopback mode, eth0 was in ethernet down state.

Thanks.

Hi Ahmet,

Please share the PHY register dump after ping:

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

Ahmet Baser said:

In the dp83869_config_init() function in the dp83869.c file, I wrote the 0th and 1st bits of the 0x32 address as 0-0, 0-1, 1-0, 1-1 as you said and tried it. However, I couldn't see any difference, so it didn't solve my problem.

Were these separate test cases, or 0x32 was written as 0-0 -> 0-1 -> ... in one complete sequence in config_init()?

Thank you,

Evan

Hi Evan Mayhew

This is the PHY reg dump.

PHY: 3 | REG: 0 --> 0x1140
PHY: 3 | REG: 1 --> 0x796d
PHY: 3 | REG: 2 --> 0x2000
PHY: 3 | REG: 3 --> 0xa0f3
PHY: 3 | REG: 4 --> 0x0101
PHY: 3 | REG: 5 --> 0xc1e1
PHY: 3 | REG: 6 --> 0x006f
PHY: 3 | REG: 7 --> 0x2001
PHY: 3 | REG: 8 --> 0x4806
PHY: 3 | REG: 9 --> 0x0800
PHY: 3 | REG: 10 --> 0x0800
PHY: 3 | REG: 11 --> 0x0000
PHY: 3 | REG: 12 --> 0x0000
PHY: 3 | REG: 13 --> 0x401f
PHY: 3 | REG: 14 --> 0x00d0
PHY: 3 | REG: 15 --> 0xf000
PHY: 3 | REG: 16 --> 0x5048
PHY: 3 | REG: 17 --> 0x7c02
PHY: 3 | REG: 18 --> 0x0000
PHY: 3 | REG: 19 --> 0x1c40
PHY: 3 | REG: 20 --> 0x2bc7
PHY: 3 | REG: 21 --> 0x0000
PHY: 3 | REG: 22 --> 0x0000
PHY: 3 | REG: 23 --> 0x0040
PHY: 3 | REG: 24 --> 0x6150
PHY: 3 | REG: 25 --> 0x4444
PHY: 3 | REG: 26 --> 0x0002
PHY: 3 | REG: 27 --> 0x0000
PHY: 3 | REG: 28 --> 0x0000
PHY: 3 | REG: 29 --> 0x0000
PHY: 3 | REG: 30 --> 0x0012
PHY: 3 | REG: 31 --> 0x0000

Evan Mayhew said:

Were these separate test cases, or 0x32 was written as 0-0 -> 0-1 -> ... in one complete sequence in config_init()?

Actually, I created a new image for each test scenario (0-0, 0-1, 1-1, 1-0) and flashed it to the custom board.

Thanks.

Hi Ahmet,

Thanks for confirming.

The PHY register & DTS configuration are equivalent between cpsw and icssg test cases? If so, the root cause is likely not with PHY.
Following up with MPU team to get more feedback.

Best regards,
Evan

Hi Evan Mayhew

Evan Mayhew said:

The PHY register & DTS configuration are equivalent between cpsw and icssg test cases?

yes, we can say the same.

Thanks.

Hi Ahmet,

In this case, I believe PHY config is acceptable for communication in icssg.

Thank you,
Evan

Hi Evan Mayhew

So what should I do in this situation? I checked the hardware. So I don't think it is a hardware related reason.