TDA4VM: j721e-cpsw-virt-mac Report an error

[    3.588297] virtio_rpmsg_bus virtio7: creating channel rpmsg_chrdev addr 0x15
[    3.593976] virtio_rpmsg_bus virtio7: creating channel ti.ipc4.ping-pong addr 0xe
[    3.638736] virtio_rpmsg_bus virtio6: creating channel ti.ipc4.ping-pong addr 0xe
[    3.641718] virtio_rpmsg_bus virtio0: creating channel ti.ipc4.ping-pong addr 0xe
[    3.642115] virtio_rpmsg_bus virtio1: creating channel ti.ipc4.ping-pong addr 0xe
[    3.674104] virtio_rpmsg_bus virtio4: creating channel ti.ethfw.notifyservice addr 0x1e
[    3.674515] virtio_rpmsg_bus virtio4: creating channel rpmsg-kdrv addr 0x1a
[    3.675133] rpmsg-kdrv-eth-switch rpmsg-kdrv-1-mpu_1_0_ethswitch-device-0: Device info: permissions: 3FFFFFFF uart_id: 2
[    3.675139] rpmsg-kdrv-eth-switch rpmsg-kdrv-1-mpu_1_0_ethswitch-device-0: FW ver 0.2 (rev 0)  6/Sep/2024 SHA:7a560c72
[    3.675830] j721e-cpsw-virt-mac main_r5fss_cpsw9g_virt_mac0: rpmsg attach_ext - rx_mtu:1522 features:0000000B tx_mtu[0]:2024 flow_idx:172 tx_cpsw_psil_dst_id:51712 mac_addr:70:ff:76:1d:92:c1 mac-only:0
[    3.693873] virtio_rpmsg_bus virtio5: creating channel ti.ipc4.ping-pong addr 0xe
[    3.700355] j721e-cpsw-virt-mac main_r5fss_cpsw9g_virt_mac0: virt_cpsw_nuss mac loaded
[    3.700363] j721e-cpsw-virt-mac main_r5fss_cpsw9g_virt_mac0: rdev_features:0000000B rdev_mtu:1522 flow_id:172 tx_psil_dst_id:4A00 mac_only:0
[    3.700368] j721e-cpsw-virt-mac main_r5fss_cpsw9g_virt_mac0: local_mac_addr:00:00:00:00:00:00 rdev_mac_addr:70:ff:76:1d:92:c1
[    3.757754] j721e-cpsw-virt-mac main_r5fss_cpsw9g_virt_mac0: virt_cpsw_nuss mac started
[    3.862719] virtio_rpmsg_bus virtio4: creating channel ti.ipc4.ping-pong addr 0xe
[    3.995208] j721e-cpsw-virt-mac main_r5fss_cpsw9g_virt_mac0: virt_cpsw_nuss mac stopped
[    4.007611] j721e-cpsw-virt-mac main_r5fss_cpsw9g_virt_mac0: virt_cpsw_nuss mac started
[    4.028970] 8021q: 802.1Q VLAN Support v1.8
[   83.933923] ------------[ cut here ]------------
[   83.933934] NETDEV WATCHDOG: eth0 (j721e-cpsw-virt-mac): transmit queue 0 timed out
[   83.933981] WARNING: CPU: 1 PID: 931 at net/sched/sch_generic.c:467 dev_watchdog+0x320/0x328
[   83.933984] Modules linked in: 8021q garp stp mrp llc xt_mac xt_iprange iptable_filter ip_tables x_tables rpmsg_char omap_rng ti_j721e_cpsw_virt_mac crct10dif_ce ti_k3_r5_remoteproc vxe_enc vxd_dec pvrsrvkm(O) ti_k3_dsp_remoteproc videobuf2_dma_sg sa2ul v4l2_mem2mem videobuf2_dma_contig virtio_rpmsg_bus videobuf2_v4l2 sha512_generic authenc videobuf2_common m_can_platform videobuf2_memops m_can can_dev rti_wdt optee_rng rng_core sch_fq_codel rpmsg_kdrv_switch cryptodev(O)
[   83.934055] CPU: 1 PID: 931 Comm: Sf_VCt_L2_FC120 Tainted: G           O      5.10.162-g76b3e88d56 #1
[   83.934057] Hardware name: Texas Instruments K3 J721E SoC (DT)
[   83.934062] pstate: 40000005 (nZcv daif -PAN -UAO -TCO BTYPE=--)
[   83.934065] pc : dev_watchdog+0x320/0x328
[   83.934068] lr : dev_watchdog+0x320/0x328
[   83.934070] sp : ffff80001000bdb0
[   83.934072] x29: ffff80001000bdb0 x28: ffff00084bf64880 
[   83.934077] x27: 0000000000000004 x26: 0000000000000140 
[   83.934082] x25: 00000000ffffffff x24: 0000000000000001 
[   83.934087] x23: ffff00084bfb03dc x22: ffff00084bfb0000 
[   83.934091] x21: ffff00084bfb0480 x20: ffff800010f57000 
[   83.934095] x19: 0000000000000000 x18: 0000000000000000 
[   83.934100] x17: 0000000000000000 x16: 0000000000000000 
[   83.934104] x15: ffff00085a2bb900 x14: 00000000000001cd 
[   83.934109] x13: ffff00085a2bbe50 x12: 00000000ffffffea 
[   83.934113] x11: ffff800010fe0430 x10: ffff800010fc83f0 
[   83.934118] x9 : ffff800010fc8448 x8 : 0000000000017fe8 
[   83.934122] x7 : c0000000ffffefff x6 : 0000000000000001 
[   83.934127] x5 : ffff00087f9f4898 x4 : 0000000000000000 
[   83.934131] x3 : 0000000000000027 x2 : 0000000000000023 
[   83.934135] x1 : fea859ffae5abf00 x0 : 0000000000000000 
[   83.934141] Call trace:
[   83.934145]  dev_watchdog+0x320/0x328
[   83.934152]  call_timer_fn.isra.0+0x24/0x80
[   83.934155]  run_timer_softirq+0x400/0x438
[   83.934159]  _stext+0x120/0x268
[   83.934162]  irq_exit+0xc0/0xe0
[   83.934166]  __handle_domain_irq+0x68/0xc0
[   83.934171]  gic_handle_irq+0x58/0x128
[   83.934174]  el0_irq_naked+0x4c/0x54
[   83.934177] ---[ end trace f499a43368672e6c ]---
[   83.934187] j721e-cpsw-virt-mac main_r5fss_cpsw9g_virt_mac0 eth0: txq:0 DRV_XOFF:0 tmo:8960 dql_avail:-1182 free_desc:496
[   89.057953] j721e-cpsw-virt-mac main_r5fss_cpsw9g_virt_mac0 eth0: txq:0 DRV_XOFF:0 tmo:14084 dql_avail:-1182 free_desc:496
[   94.945937] j721e-cpsw-virt-mac main_r5fss_cpsw9g_virt_mac0 eth0: txq:0 DRV_XOFF:0 tmo:19972 dql_avail:-1182 free_desc:496
[   99.805937] j721e-cpsw-virt-mac main_r5fss_cpsw9g_virt_mac0 eth0: txq:0 DRV_XOFF:0 tmo:24832 dql_avail:-1182 free_desc:496
[  411.792333] audit: type=1006 audit(1677885522.244:8): pid=1055 uid=0 subj=_unconfined old-auid=4294967295 auid=0 tty=(none) old-ses=4294967295 ses=1 res=1
[  411.807473] audit: type=1334 audit(1677885522.260:9): prog-id=9 op=LOAD
[  411.807772] audit: type=1334 audit(1677885522.260:10): prog-id=9 op=UNLOAD
[  411.807988] audit: type=1334 audit(1677885522.260:11): prog-id=10 op=LOAD
[  411.808172] audit: type=1334 audit(1677885522.260:12): prog-id=10 op=UNLOAD
[  466.909938] j721e-cpsw-virt-mac main_r5fss_cpsw9g_virt_mac0 eth0: txq:0 DRV_XOFF:0 tmo:5940 dql_avail:-198 free_desc:495
[  472.029943] j721e-cpsw-virt-mac main_r5fss_cpsw9g_virt_mac0 eth0: txq:0 DRV_XOFF:0 tmo:11060 dql_avail:-198 free_desc:495
[  476.893936] j721e-cpsw-virt-mac main_r5fss_cpsw9g_virt_mac0 eth0: txq:0 DRV_XOFF:0 tmo:15924 dql_avail:-198 free_desc:495
[  482.013946] j721e-cpsw-virt-mac main_r5fss_cpsw9g_virt_mac0 eth0: txq:0 DRV_XOFF:0 tmo:21044 dql_avail:-198 free_desc:495
[  486.877923] j721e-cpsw-virt-mac main_r5fss_cpsw9g_virt_mac0 eth0: txq:0 DRV_XOFF:0 tmo:25908 dql_avail:-198 free_desc:495
[  491.997945] j721e-cpsw-virt-mac main_r5fss_cpsw9g_virt_mac0 eth0: txq:0 DRV_XOFF:0 tmo:31028 dql_avail:-198 free_desc:495
[  496.861933] j721e-cpsw-virt-mac main_r5fss_cpsw9g_virt_mac0 eth0: txq:0 DRV_XOFF:0 tmo:35892 dql_avail:-198 free_desc:495
[  501.981943] j721e-cpsw-virt-mac main_r5fss_cpsw9g_virt_mac0 eth0: txq:0 DRV_XOFF:0 tmo:41012 dql_avail:-198 free_desc:495
[  506.845935] j721e-cpsw-virt-mac main_r5fss_cpsw9g_virt_mac0 eth0: txq:0 DRV_XOFF:0 tmo:45876 dql_avail:-198 free_desc:495
[  511.969932] j721e-cpsw-virt-mac main_r5fss_cpsw9g_virt_mac0 eth0: txq:0 DRV_XOFF:0 tmo:51000 dql_avail:-198 free_desc:495
[  558.045933] j721e-cpsw-virt-mac main_r5fss_cpsw9g_virt_mac0 eth0: txq:0 DRV_XOFF:0 tmo:6780 dql_avail:-253 free_desc:500
[  563.933952] j721e-cpsw-virt-mac main_r5fss_cpsw9g_virt_mac0 eth0: txq:0 DRV_XOFF:0 tmo:12668 dql_avail:-253 free_desc:500
[  569.053935] j721e-cpsw-virt-mac main_r5fss_cpsw9g_virt_mac0 eth0: txq:0 DRV_XOFF:0 tmo:17788 dql_avail:-253 free_desc:500
[  574.941934] j721e-cpsw-virt-mac main_r5fss_cpsw9g_virt_mac0 eth0: txq:0 DRV_XOFF:0 tmo:23676 dql_avail:-253 free_desc:500
[  579.805954] j721e-cpsw-virt-mac main_r5fss_cpsw9g_virt_mac0 eth0: txq:0 DRV_XOFF:0 tmo:28540 dql_avail:-253 free_desc:500
[  584.925935] j721e-cpsw-virt-mac main_r5fss_cpsw9g_virt_mac0 eth0: txq:0 DRV_XOFF:0 tmo:33660 dql_avail:-253 free_desc:500
[  590.045934] j721e-cpsw-virt-mac main_r5fss_cpsw9g_virt_mac0 eth0: txq:0 DRV_XOFF:0 tmo:38780 dql_avail:-253 free_desc:500
[  595.933923] j721e-cpsw-virt-mac main_r5fss_cpsw9g_virt_mac0 eth0: txq:0 DRV_XOFF:0 tmo:44668 dql_avail:-253 free_desc:500
[  601.057947] j721e-cpsw-virt-mac main_r5fss_cpsw9g_virt_mac0 eth0: txq:0 DRV_XOFF:0 tmo:49792 dql_avail:-253 free_desc:500

Hi,

Above could be because of Transmission from application is not completed.
Is ETHFW running on MCU2_0? 

Have you made any changes to ETHFW or Virtual MAC Driver?

Best Regards,
Sudheer

Is ETHFW running on MCU2_0? 

Yes.

Have you made any changes to ETHFW or Virtual MAC Driver?

No changes .

I found the following changes in SDK 09_01_00_06 realeaseNote, is it related to this problem? Is the patch repaired?

Hi,

zs xu said:

ETHFW-2084 EthFW: Cable connect/disconnect can cause CPSW unrecoverable condition.

It was observed in SGMII Port mode.
By default SDK not enabled SGMII mode, If you have modified Port configuration and had PHY Driver supported for this you may observe that error.
Also, error was not easily reproducible.

zs xu said:

Is ETHFW running on MCU2_0? 

Yes.

How you have confirmed ETHFW is running?
Can you please check by disconnecting and connecting of any Port Ethernet cable and observe the ETHFW debug prints whether it prints Link Up and Down or not?

Also, once A72 client is successfully registered with ETHFW, then A72 can able to send Broadcast packets to network and able to receive the packets with destination address as A72's from network even if ETHFW is not running.

>>[   83.933934] NETDEV WATCHDOG: eth0 (j721e-cpsw-virt-mac): transmit queue 0 timed out
Above can happen only when Tx from CPSW is not success and stall the CPSW Tx path.

Also, In above case/scenario, can you please also try to ping ETHFW and check whether ping was success or not?

Best Regards,
Sudheer

Port3 of our CPSW is an external PHY connected via SGMII.
The Cpsw_handleLinkDown and Cpsw_handleLinkUp logs are displayed when the CPSW Port3 is connected or disconnected.

This problem can easily be repeated by disconnecting the Ethernet adapter box outside the Port3.
When this problem occurs, Port4 devices can ping Port5 devices, but Port4 devices cannot ping A72.
In this case, the A72 tcpdump checks that it can receive data but cannot send data. After connecting to the Ethernet adapter box of Port3, the problem disappears.

Above can happen only when Tx from CPSW is not success and stall the CPSW Tx path.
-> Does this mean that only CPSW Port0's Tx path is stall?  How to avoid this situation?

can you please also try to ping ETHFW and check whether ping was success or not?
-> We did not configure IP for mcu2_0, so it is estimated that we cannot test

zs xu said:

Port3 of our CPSW is an external PHY connected via SGMII.
The Cpsw_handleLinkDown and Cpsw_handleLinkUp logs are displayed when the CPSW Port3 is connected or disconnected.

Ok, Port-3 configured for SGMII.

Can you please confirm, which SGMII interface was selected for Port-3.
If it is Fixed Link then Port-3 should not be Link down. If not Link Down was fine.

zs xu said:

This problem can easily be repeated by disconnecting the Ethernet adapter box outside the Port3.
When this problem occurs, Port4 devices can ping Port5 devices, but Port4 devices cannot ping A72.
In this case, the A72 tcpdump checks that it can receive data but cannot send data. After connecting to the Ethernet adapter box of Port3, the problem disappears.

Above can happen only when Tx from CPSW is not success and stall the CPSW Tx path.
-> Does this mean that only CPSW Port0's Tx path is stall?  How to avoid this situation?

Yes, from above it seems like Host Port Tx is stalled.
The reason could be by the time we disabled the Port for Link Down state there could some packets forwarding to Port-3 from Host Port then that transfer may not complete as during transfer in between Port may be disabled.

Once Link is Up, Port is enabled back and Host Port will transfer data on Port-3 and process next queued packets.

zs xu said:

can you please also try to ping ETHFW and check whether ping was success or not?
-> We did not configure IP for mcu2_0, so it is estimated that we cannot test

If you are connecting DHCP network to Port-3 instead of static IP then ETHFW will also get an IP. Can be found from ETHFW debug log

Can you check SGMII mode configured in ETHFW, and check the same test by connecting Ethernet cable on Port-3. 

Best Regards,
Sudheer

We are preparing to use this patch verification:
git.ti.com/.../am65-cpsw-nuss.c

Hi,

zs xu said:

git.ti.com/.../am65-cpsw-nuss.c

Above will define the Max RX packet size, from above your side issue was in Tx path of Host Port to External Ports.
Can you please check as pointed in above.

Best Regards,
Sudheer

How do I check if it is "Fixed Link"?
DHCP is disabled.

    {
        .macPort   = ENET_MAC_PORT_3,
        .mii       = { ENET_MAC_LAYER_GMII, ENET_MAC_SUBLAYER_SERIAL },
        .phyCfg    =
        {
            .phyAddr         = 5U,
            .isStrapped      = false,
            .skipExtendedCfg = false,
            .extendedCfg     = &gEnetGesiBoard_dp83867PhyCfg,
            .extendedCfgSize = sizeof(gEnetGesiBoard_dp83867PhyCfg),
        },
        .sgmiiMode = ENET_MAC_SGMIIMODE_SGMII_WITH_PHY,
        .linkCfg   = { ENET_SPEED_1GBIT, ENET_DUPLEX_FULL },
    },

Hi,

Above configuration was fine, It was not forced Link Mode.
sgmiiMode = ENET_MAC_SGMIIMODE_SGMII_WITH_PHY,

In this case, even if you disconnect the cable ETHFW will boot up and proceed for further, Other Ports will work normally.

You should be able to ping A72 from Port-2/5/6/7/8, as all are switch Ports by defaults. Until there was change in Port configuration from default configuration.

Also, can you please share your Port configuration from ETHFW main.c file? 
Also, confirm is there any MAC only Port configuration changes in Linux & ETHFW?

Best Regards,
Sudheer

We verified the patch, but the problem persists.
When there is a problem, A72 cannot ping Port5's mcu.
How to monitor the stall state of CPSW Port0's Tx path and restore it?

Hi,

Doredla Sudheer Kumar said:

Also, can you please share your Port configuration from ETHFW main.c file? 
Also, confirm is there any MAC only Port configuration changes in Linux & ETHFW?

Can you please above details.
Also, please share full ETHFW Logs and A72 Linux Log.

Best Regards,
Sudheer

zs xu said:

We verified the patch, but the problem persists.
When there is a problem, A72 cannot ping Port5's mcu.
How to monitor the stall state of CPSW Port0's Tx path and restore it?

Hi ZS

    please refer to following link, it's a similar issue
      (+) TDA4VH-Q1: Ethernet error: am65-cpsw-nuss c200000.ethernet eth0: txq:0 DRV_XOFF:0 tmo:9068 dql_avail:-464 free_desc:498 - Processors forum - Processors - TI E2E support forums

Regards

    Semon

I made the following changes so that CPSW does not do Cpsw_handleLinkDown(). The problem disappears.

pdk_jacinto_08_06_00_31/packages/ti/drv/enet/src/per/cpsw.c
Cpsw_periodicTick()
- linked = (linkStatus == ENETPHY_GOT_LINK);
+ linked = 1;

Is there any downside to that?
How do I operate the ARP list of the specified CPSW port?

Hi,

zs xu said:

pdk_jacinto_08_06_00_31/packages/ti/drv/enet/src/per/cpsw.c
Cpsw_periodicTick()
- linked = (linkStatus == ENETPHY_GOT_LINK);
+ linked = 1;

Which means you are not allowing Port to be Link Down with a hack in Driver. So, port will be always active.

zs xu said:

Is there any downside to that?

Please check your side, why Link down scenario is executed.

zs xu said:

How do I operate the ARP list of the specified CPSW port?

ARP entry not based on CPSW Port, All switch Ports can receive the from network.

ETHFW will maintain the ARP table using proxy-ARP it will respond to the ARP request of remote clients on behalf of clients.

Best Regards,
Sudheer

I use this modification and the problem disappears.
However, when TDA4-1 ping TDA4-2 through CPSW port4, Port3 is disconnected.
The red box in the screenshot appears: the network delay is too large and the response time is unstable, and the delay of connecting to Port3 again becomes normal.
Why does the CPSW Port3 connection status affect the CPSW Port0 operation?
May I ask what causes CPSW to work abnormally?
How do I solve the problem that CPSW works abnormally?

Hi,

I am not aware of your system connections and configurations.

Can you please share your system connectivity and Port configuration, Also the ETHFW debug logs.

Without having any information, I can't comment.

zs xu said:

Why does the CPSW Port3 connection status affect the CPSW Port0 operation?

If there is a data intended to forward on Port-3 from Host Port, and the FIFO at Port-3 is full then Host port can't forward the data to Port-3 resulting stall in Host Port.

zs xu said:

May I ask what causes CPSW to work abnormally?
How do I solve the problem that CPSW works abnormally?

Handling of Linkup and Link Down of Ports should be properly, also the ALE entries also matters how to forward the data.

zs xu said:

How do I solve the problem that CPSW works abnormally?

1. Make sure, your configuration was proper.
2. Check ALE entries, are as expected or not
3. Check CPSW statistics, which can help you to understand the data flow and any errors in packets.

Please refer to FAQ for dumping ALE and classifiers.
Also, refer to FAQ for dumping CPSW statistics.

Best Regards,
Sudheer

static EthFwBoard_MacPortCfg gEthFw_gesiMacPortCfg[] =
{
    {   /* "SGMII1_1 */
        .macPort   = ENET_MAC_PORT_1,
        .mii       = { ENET_MAC_LAYER_GMII, ENET_MAC_SUBLAYER_SERIAL },
        .phyCfg    =
        {
            .phyAddr         = 7U,
            .isStrapped      = false,
            .skipExtendedCfg = false,
            .extendedCfg     = &gEnetGesiBoard_dp83867PhyCfg,
            .extendedCfgSize = sizeof(gEnetGesiBoard_dp83867PhyCfg),
        },
        .sgmiiMode = ENET_MAC_SGMIIMODE_SGMII_WITH_PHY,
        .linkCfg   = { ENET_SPEED_1GBIT, ENET_DUPLEX_FULL },
    },
    {   /* "SGMII2_3" */
        .macPort   = ENET_MAC_PORT_3,
        .mii       = { ENET_MAC_LAYER_GMII, ENET_MAC_SUBLAYER_SERIAL },
        .phyCfg    =
        {
            .phyAddr         = 5U,
            .isStrapped      = false,
            .skipExtendedCfg = false,
            .extendedCfg     = &gEnetGesiBoard_dp83867PhyCfg,
            .extendedCfgSize = sizeof(gEnetGesiBoard_dp83867PhyCfg),
        },
        .sgmiiMode = ENET_MAC_SGMIIMODE_SGMII_WITH_PHY,
        .linkCfg   = { ENET_SPEED_1GBIT, ENET_DUPLEX_FULL },
    },
    #ifdef CONFIG_MASTER_BOARD

    {   /* "SGMII02_4" */
        .macPort   = ENET_MAC_PORT_4,
        .mii       = { ENET_MAC_LAYER_GMII, ENET_MAC_SUBLAYER_SERIAL },
        .phyCfg    =
        {
            .phyAddr         = ENETPHY_INVALID_PHYADDR,
            //.phyAddr         = 3U,
            .isStrapped      = false,
            .skipExtendedCfg = false,
            //.extendedCfg     = &gEnetGesiBoard_dp83867PhyCfg,
            //.extendedCfgSize = sizeof(gEnetGesiBoard_dp83867PhyCfg),
            .extendedCfg     = NULL,
            .extendedCfgSize = 0,
        },
        .sgmiiMode = ENET_MAC_SGMIIMODE_SGMII_AUTONEG_MASTER,
        .linkCfg   = { ENET_SPEED_1GBIT, ENET_DUPLEX_FULL },
    },
    #endif
    #ifdef CONFIG_SLAVE_BOARD

    {   /* "SGMII02_4" */
        .macPort   = ENET_MAC_PORT_4,
        .mii       = { ENET_MAC_LAYER_GMII, ENET_MAC_SUBLAYER_SERIAL },
        .phyCfg    =
        {
            .phyAddr         = ENETPHY_INVALID_PHYADDR,
            //.phyAddr         = 3U,
            .isStrapped      = false,
            .skipExtendedCfg = false,
            //.extendedCfg     = &gEnetGesiBoard_dp83867PhyCfg,
            //.extendedCfgSize = sizeof(gEnetGesiBoard_dp83867PhyCfg),
            .extendedCfg     = NULL,
            .extendedCfgSize = 0,
        },  
        .sgmiiMode = ENET_MAC_SGMIIMODE_SGMII_AUTONEG_SLAVE,
        .linkCfg   = { ENET_SPEED_1GBIT, ENET_DUPLEX_FULL },
    },
    #endif
         {   /* "RGMII5" */
        .macPort   = ENET_MAC_PORT_5,
        .mii       = { ENET_MAC_LAYER_GMII, ENET_MAC_SUBLAYER_REDUCED },
        .phyCfg    =
        {
            .phyAddr         = ENETPHY_INVALID_PHYADDR,
            .isStrapped      = false,
            .skipExtendedCfg = false,
            .extendedCfg     = NULL,
            .extendedCfgSize = 0,
        },
        .sgmiiMode = ENET_MAC_SGMIIMODE_INVALID,
        .linkCfg   = { ENET_SPEED_1GBIT, ENET_DUPLEX_FULL },
    },
};

[MCU2_0]      5.708618 s: ETHFW: Init ... !!!
[MCU2_0]      5.732832 s: [PHY5&7][Reset Pin] Low
[MCU2_0]      5.752830 s: [PHY5&7][Reset Pin] High
[MCU2_0]      5.770714 s: Warning: Using 6 MAC address(es) from static pool
[MCU2_0]      5.770839 s: ETHFW: Shared multicasts (software fanout):
[MCU2_0]      5.771118 s: EnetMcm: CPSW_9G on MAIN NAVSS
[MCU2_0]      5.780297 s: Mdio_open: [mdio.c][Mdio_open]mdioCfg->c45EnMask:0xffffffff
[MCU2_0]      5.785021 s: PHY 5 is alive
[MCU2_0]      5.785166 s:  EthFwBoard_findPortCfg to find port config !  Port numer = 0
[MCU2_0]      5.785382 s: EnetPhy_open: PHY 7: open
[MCU2_0]      5.785436 s:  EthFwBoard_findPortCfg to find port config !  Port numer = 2
[MCU2_0]      5.785876 s: EnetPhy_bindDriver: PHY 5: OUI:2b8094 Model:03 Ver:0a <-> 'bcm89883' : OK
[MCU2_0]      5.785945 s: EnetPhy_open: PHY 5: open
[MCU2_0]      5.785988 s:  EthFwBoard_findPortCfg to find port config !  Port numer = 3
[MCU2_0]      5.790955 s: CpswMacPort_checkSgmiiAutoNegStatus: MAC 4: soc2 slave bIsAutoNegComplete ok
[MCU2_0]      5.791033 s: CpswMacPort_checkSgmiiAutoNegStatus: MAC 4: soc2 slave link ok
[MCU2_0]      5.791095 s: CpswMacPort_checkSgmiiStatus: MAC 4: SGMII link parter config port: link up: 1-Gbps Full-Duplex
[MCU2_0]      5.791159 s: Cpsw_openPortLinkNoPhy: Port 4: Link up: 1-Gbps Full-Duplex
[MCU2_0]      5.791205 s:  EthFwBoard_findPortCfg to find port config !  Port numer = 4
[MCU2_0]      5.791371 s: Cpsw_openPortLinkNoPhy: Port 5: Link up: 1-Gbps Full-Duplex
[MCU2_0]      5.794531 s:
[MCU2_0] ETHFW Version   : 0.02.00
[MCU2_0]      5.794609 s: ETHFW Build Date: Sep 16, 2024
[MCU2_0]      5.794645 s: ETHFW Build Time: 18:57:30
[MCU2_0]      5.794677 s: ETHFW Commit SHA: 348d7fa1
[MCU2_0]      5.794813 s: ETHFW: Init ... DONE !!!
[MCU2_0]      5.794865 s: ETHFW: Remove server Init ... !!!
[MCU2_0]      5.795054 s: CpswProxyServer: Virtual port configuration:
[MCU2_0]      5.795115 s:   mpu_1_0 <-> Switch port 0: mpu_1_0_ethswitch-device-0
[MCU2_0]      5.795165 s:   mcu_2_1 <-> Switch port 1: mcu_2_1_ethswitch-device-1
[MCU2_0]      5.796110 s: CpswProxyServer: initialization completed (core: mcu2_0)
[MCU2_0]      5.796187 s: ETHFW: Remove server Init ... DONE !!!

Hi,

As per below configuration, Port-4 is configured in SGMII MAC2MAC mode without PHY.

{ /* "SGMII02_4" */
.macPort = ENET_MAC_PORT_4,
.mii = { ENET_MAC_LAYER_GMII, ENET_MAC_SUBLAYER_SERIAL },
.phyCfg =
{
.phyAddr = ENETPHY_INVALID_PHYADDR,


Note:,
Run time Link Up and down will not be handled for no PHY scenario i.e. phyAddr is invalid. So, timer task for Link status monitor will not be applicable for this.

Also, by default Port-4 is configured as MAC only Port and mapped to MCU2_1 client. Make sure MAC only in disabled in your case for switch functionality.

Best Regards,
Sudheer

This is a problem with ports 0 and 3. Is it related to port 4?

Hi,

zs xu said:

This is a problem with ports 0 and 3. Is it related to port 4?

Port-3, it should not be an issue.

By default Port-4, and Port-1 are MAC only Ports (i.e. packet will not be forwarded to any other ports). In you case other than Port-3 only Port-1 & Port-4 are only enabled. So, If Port-3 is link down you can't ping PC using any other port.

The packet sent on Port-4 & Port-1 will only reach to mapped virtual clients and vice versa.

Best Regards,
Sudheer

My ports 0 and 5 are also enabled,
After Port3 is disconnected, I ping A72 from another TDA4 through Port4, and the network delay increases and is unstable

Hi,

zs xu said:

My ports 0 and 5 are also enabled,

Port-0 is Host Port, It is always enabled.

Port-5 connected to MCU CPSW.

zs xu said:

After Port3 is disconnected, I ping A72 from another TDA4 through Port4, and the network delay increases and is unstable

If so, you might have configured Port-4 as non MAC only Port. If So, it is expected to work.

But network delay increase and unstable should not be. Until some processing in S/W or some network congestion with high traffic. 

Best Regards,
Sudheer

Doredla Sudheer Kumar said:

Yes, from above it seems like Host Port Tx is stalled.
The reason could be by the time we disabled the Port for Link Down state there could some packets forwarding to Port-3 from Host Port then that transfer may not complete as during transfer in between Port may be disabled.

You mean to say,
When I disconnect the peripherals of Port3, CPSW needs to disable Port3 first, and then switch to link down state.
In the process of disabling the port, there is data passing through the cause of this problem,
This problem does not arise if no data passes through during the disabling port process,
Am I understanding this right？

Doredla Sudheer Kumar said:

In your case it is SGMII with PHY, clock is internal clock. so, Host port stall will not happen.

But my Host Port Tx is stalled，That contradicts what you said before.

Hi,

zs xu said:

But my Host Port Tx is stalled，That contradicts what you said before.

I expect TDA41 to TDA42 communication should success even when Port-3 is link down. If this working means no stall in Host Port.

Can you please confirm the same? 

Doredla Sudheer Kumar said:

Please refer to FAQ for dumping ALE and classifiers.
Also, refer to FAQ for dumping CPSW statistics.

Also, please check CPSW statistics while running this test and check Host Port rx counters are increasing or not?

Best Regards,
Sudheer

I use the same hardware and the same version of software and test methods, and the problem doesn't recast. It's weird.

Hi,

As per above update from mine, The possibility for stall is when clock is driven by externally.

Please check CPSW statics, ALE & classifier when you are observing this issue and share the logs with us for further analysis.

Best Regards,
Sudheer