• State Resolved
  • Locked Locked
  • Replies 6 replies
  • Subscribers 99 subscribers
  • Views 719 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

TDA4VM: TDA4VM CPSW9G Native Ethernet Mode Ping on eth4 but no packets received

Kevin Peng
Expert 3752 points
Part Number: TDA4VM

Hi Ti Ethernet experts,

My customer is enabling J721e CPSW9g Native Ethernet mode by applying “k3-j721e-quad-port-eth-exp.dtbo”. Then he got 4 eth on J721e with Quad-Port Ethernet Expansion board. The 4 eth are all up. But he cannot ping on eth 4 in CPSW9G native ethernet mode.

BTW, the CPSW2g is also in Native Ethernet mode, and it can ping.

The following shows the stage results he got:

  • enabled J721e CPSW9g Native Ethernet mode, add env in uboot uEnv.txt:

 

  • Eth4 is on VSC8514 is link up

 

 

But cannot ping PC using eth4 with CPSW9G, no packets received.

The tcpdump on the eth4 shows below, there is no packets received when pc ping the board. But the link status showing “yes”

But with the same steps the eth0 of CPSW2G can be pinged and packets can be received successfully.

Could you please provide some feedback on this question, it seems the status shows the eth4 in CPSW9G native ethernet mode is connected correctly, but why there is no packets received?

Thank you so much!

Kevin

  • 0
    TI__Expert 3752 points

    To make it more clear, 

    Customer is using the latest SDK 8.6. In the default virtual client mode, all the 4 ports in CPSW9G can ping with packets received successfully, but according to the SDK documentation, customers applied the k3-j721e-quad-port-eth-exp.dtbo and configured the CPSW9G in native ethernet, then they can not ping any of the 4 ports in CPSW9G, the status is correct but no packets can receive. However, the port0 in CPSW2G still can ping with packet received.

  • 0 in reply to Kevin Peng
    TI__Guru 50045 points

    Hi Kevin,

    Did customer remove the EthFW firmware R5 binary from SD card?

    It is under rootfs/lib/firmware/ethfw. Or remove the j7-main-r5f0_0-fw link.

    Regards,
    Stanley

  • 0 in reply to Stanley Liu
    TI__Expert 3752 points

    Hi Stanley,

    Thanks for your reply. The EthFW firmware R5 binary from SD card is not removed. However, from the log of default ethernet mode, the r5f image including EthFW in main domain is not loaded and started. In the default virtual client mode, the log shows the r5f image in main domain is loaded. So, the r5f image in main domain seems may not be the cause of this problem.

    Kind Regards,

    Kevin

  • 0 in reply to Kevin Peng
    TI__Mastermind 38370 points

    Hi Kevin,

    Can you please refer to this FAQ and see if you see anything there which can resolve your issue.

    If you can't find anything, please share the linux kernel boot logs.

    Do you also see the issue on eth1, eth2, eth3 ?

    Regards,
    Tanmay

  • 0 in reply to Tanmay Patil
    TI__Expert 3752 points

    Hi Tanmay & Stanley,

    By following the FAQ & removing the EthFW Firmware R5, eth1,2,3,4 can ping successfully.

    There are two more points based on it may need you double confirm.

    1: When cable is unplugged & plugged again, the IP address is lost and need to configure again. Is this the necessary thing need to be done in this situation?

    2: When two eth is available (eth1 & eth2), eth2 can not ping, but when eth1 is down, then the eth2 can ping. Is there any restriction in this situation?

    Thanks a lot!

    Kevin

  • +1 in reply to Kevin Peng
    TI__Mastermind 38370 points

    Hi Kevin,

    Kevin Peng said:
    When cable is unplugged & plugged again, the IP address is lost and need to configure again. Is this the necessary thing need to be done in this situation?

    This is the default behaviour. You can also statically assign an IP address to the interface from systemd.networkd service in linux which will reconfigure the IP address when cable is reattached.

    Kevin Peng said:
    When two eth is available (eth1 & eth2), eth2 can not ping, but when eth1 is down, then the eth2 can ping. Is there any restriction in this situation?

    This is because both eth1 and eth2 are in the same subnet. If you are connected on diffrent network, you should use diffrent subnets. You can also use "-I eth2" flag with the ping command to force the ping to go through eth2 interface ("ping -I eth2 12.168.1.200")

    Regards,
    Tanmay