TDA4VM: Rgmii4 porting phy cannot get IP

Cherry Zhou

Part Number: TDA4VM

Hi team,

TDA4EVM and SDK 8.4 RTOs are being used.

The rgmii 3, rgmii 5 debug phy in 9G are all successful. Rgmii4 tx has no data output other than 125m output. Rgmii4 Rx can measure some data.

Turn on lwip printing:

[MCU2_0] 40.898486 s: pbuf_add_header: old a35a55f8 new a35a55e4 (20)
[MCU2_0] 40.898542 s: ip4_output_if: br4
[MCU2_0] 40.898569 s: IP header:
[MCU2_0] 40.898592 s: +-------------------------------+
[MCU2_0] 40.898646 s: | 4 | 5 | 0x00 | 336 | (v, hl, tos, len)
[MCU2_0] 40.898680 s: +-------------------------------+
[MCU2_0] 40.898737 s: | 4 |000| 0 | (id, flags, offset)
[MCU2_0] 40.898773 s: +-------------------------------+
[MCU2_0] 40.898822 s: | 255 | 17 | 0xba99 | (ttl, proto, chksum)
[MCU2_0] 40.898857 s: +-------------------------------+
[MCU2_0] 40.899040 s: | 0 | 0 | 0 | 0 | (src)
[MCU2_0] 40.899083 s: +-------------------------------+
[MCU2_0] 40.899136 s: | 255 | 255 | 255 | 255 | (dest)
[MCU2_0] 40.899167 s: +-------------------------------+
[MCU2_0] 40.899198 s: ip4_output_if: call netif->output()
[MCU2_0] 40.899251 s: pbuf_add_header: old a35a55e4 new a35a55d6 (14)
[MCU2_0] 40.899298 s: ethernet_output: sending packet a35a5500
[MCU2_0] 40.899433 s: dhcp_discover: deleting()ing
[MCU2_0] 40.899492 s: pbuf_free(a35a5500)
[MCU2_0] 40.899543 s: pbuf_free: a35a5500 has ref 1, ending here.
[MCU2_0] 40.899575 s: dhcp_discover: SELECTING
[MCU2_0] 40.899615 s: dhcp_discover(): set request timeout 32000 msecs
[MCU2_0] 40.899683 s: sys_timeout: a362fc80 abs_time=39160 handler=dhcp_fine_tmr arg=a39da4bc
[MCU2_0] 40.899742 s: sct calling h=igmp_tmr t=2 arg=a39da4c8
[MCU2_0] 40.899779 s: tcpip: igmp_tmr()
[MCU2_0] 40.899829 s: sys_timeout: a362fc00 abs_time=38760 handler=igmp_tmr arg=a39da4c8
[MCU2_0] 40.998011 s: sct calling h=igmp_tmr t=1 arg=a39da4c8

The pinmux is the original rtos configuration, printed in accordance with the DM manual as follows:

devmem2 0x00011C134
/dev/mem opened.
Memory mapped at address 0xffffb999c000.
Read at address  0x0011C134 (0xffffb999c134): 0x00010004
root@j7-evm:~# devmem2 0x00011C138
/dev/mem opened.
Memory mapped at address 0xffff8d828000.
Read at address  0x0011C138 (0xffff8d828138): 0x00010004
root@j7-evm:~# devmem2 0x00011C13c
/dev/mem opened.
Memory mapped at address 0xffffa82ad000.
Read at address  0x0011C13C (0xffffa82ad13c): 0x00010004
root@j7-evm:~# devmem2 0x00011C140
/dev/mem opened.
Memory mapped at address 0xffffa2ba0000.
Read at address  0x0011C140 (0xffffa2ba0140): 0x00010004
root@j7-evm:~#

It is found that the stack did send, but rgmii 4 TX did not have any data. Why is only rgmii 4 TX having issue? Could you help check this case? Thanks.

Best Regards,

Cherry

over 3 years ago

0 Tanmay Patil over 3 years ago

TI__Mastermind 43530 points

Hi Cherry,

Can you see any obvious difference between macport 4 and rest of the macports? The things to look for would be-

The phy being used
The mode of the MAC (rgmii vs other modes)

Can you compare the MAC registers of the working port vs the non working port. The registers to look out for would be

CPSW_PN_CONTROL_REG_k (Section 12.2.2.6.5.55 in TRM)
CPSW_PN_MAC_CONTROL_REG_k (Section 12.2.2.6.5.92 in TRM)
CPSW_PN_MAC_STATUS_REG_k (Section 12.2.2.6.5.93 in TRM)

We can check the statistics of the cpsw IP as well. You can see here for more details on how to get statistics. So you want to see if the host port (port 0) is receiving any packets or not. It will then pass on these packets to port 4. We can track this movement using statistics. A stat dump compare before and after sending few packets will help here.

Is this continuation of TDA4VM: Can't ping when porting PHY to SDK 8.4? or a different question all together? I am assuming it as a different question for now. Let me know if that is not the case.

Regards,
Tanmay

0 Cherry Zhou over 3 years ago in reply to Tanmay Patil

TI__Mastermind 22235 points

Hi Tanmay,

Thank you for the support.

Tanmay Patil said:
The phy being used

Port 5 has the same PHY as port 4, only the phy addr is different.

Tanmay Patil said:
The mode of the MAC (rgmii vs other modes)

They're all RGMII modes.

Tanmay Patil said:
Is this continuation of TDA4VM: Can't ping when porting PHY to SDK 8.4? or a different question all together? I am assuming it as a different question for now. Let me know if that is not the case.

Yes, these 2 are from the same customer, so it can be seen as a continuation.

Thanks and regards,

Cherry

0 Tanmay Patil over 3 years ago in reply to Cherry Zhou

TI__Mastermind 43530 points

Hi Cherry,

Tanmay Patil said:
Can you compare the MAC registers of the working port vs the non working port. The registers to look out for would be

CPSW_PN_CONTROL_REG_k (Section 12.2.2.6.5.55 in TRM)

CPSW_PN_MAC_CONTROL_REG_k (Section 12.2.2.6.5.92 in TRM)

CPSW_PN_MAC_STATUS_REG_k (Section 12.2.2.6.5.93 in TRM)

We can check the statistics of the cpsw IP as well. You can see here for more details on how to get statistics. So you want to see if the host port (port 0) is receiving any packets or not. It will then pass on these packets to port 4. We can track this movement using statistics. A stat dump compare before and after sending few packets will help here.

Can you also respond on this.

Regards,
Tanmay

0 Cherry Zhou over 3 years ago in reply to Tanmay Patil

TI__Mastermind 22235 points

Hi Tanmay,

Tanmay Patil said:
Can you compare the MAC registers of the working port vs the non working port. The registers to look out for would be

CPSW_PN_CONTROL_REG_k (Section 12.2.2.6.5.55 in TRM)

CPSW_PN_MAC_CONTROL_REG_k (Section 12.2.2.6.5.92 in TRM)

CPSW_PN_MAC_STATUS_REG_k (Section 12.2.2.6.5.93 in TRM)

These 3 registers are the same in normal port 3 and exception port4, when udhcpc is executed:

port 3

root@j7-evm:~# devmem2 0x0C024004
/dev/mem opened.
Memory mapped at address 0xffffa4e90000.
Read at address 0x0C024004 (0xffffa4e90004): 0x00000000
root@j7-evm:~# devmem2 0x0C024330
/dev/mem opened.
Memory mapped at address 0xffffa9f30000.
Read at address 0x0C024330 (0xffffa9f30330): 0x000200A1
root@j7-evm:~# udhcpc: sending discover
devmem2 0x0C024334
/dev/mem opened.
Memory mapped at address 0xffffbb8c0000.
Read at address 0x0C024334 (0xffffbb8c0334): 0xF0000018
root@j7-evm:~# udhcpc: sending discover

port 4

root@j7-evm:~# devmem2 0x0C025004
/dev/mem opened.
Memory mapped at address 0xffff9969c000.
Read at address 0x0C025004 (0xffff9969c004): 0x00000000
root@j7-evm:~#
root@j7-evm:~# udhcpc: sending discover
udhcpc: sending discover
udhcpc: sending discover
devmem2 0x0C025330
/dev/mem opened.
Memory mapped at address 0xffffbcff9000.
Read at address 0x0C025330 (0xffffbcff9330): 0x000200A1
root@j7-evm:~# devmem2 0x0C025334
/dev/mem opened.
Memory mapped at address 0xffff811dd000.
Read at address 0x0C025334 (0xffff811dd334): 0xF0000018
root@j7-evm:~#

Thanks and regards,

Cherry

0 Tanmay Patil over 3 years ago in reply to Cherry Zhou

TI__Mastermind 43530 points

Hi Cherry,

Can you try MAC loopback test. See this for more information on MAC loopback.

This will make sure that the MAC is configured correctly.

Regards,
Tanmay

0 Cherry Zhou over 3 years ago in reply to Tanmay Patil

TI__Mastermind 22235 points

Hi Tanmay,

The results of the above test are as follows:

They have tuned PHY in Linux in an ECO to do a scripting lab from Linux.

A. T1 only connected to the adapter box so that the Mac is linked, the adapter box does not have the RJ45 network cable connected but instead the PC end.

But they cannot see increment in both Tx and Rx (you see increment in both Tx_Good_frames and Rx_good_frames for the port under test, the MAC is working properly).

B. After connecting to the network cable, increment can be seen in both Tx_Good_frames and Rx_good_frames.

So is test A wrong?

Thanks and regards,

Cherry

0 Tanmay Patil over 2 years ago in reply to Cherry Zhou

TI__Mastermind 43530 points

Hi Cherry,

Sorry for the delay.

Is this Issue still observed?

Regards,
Tanmay

Processors

Processors forum

TDA4VM: Rgmii4 porting phy cannot get IP