TDA4VM: Ethernet communication issue in SDK 8.4

Dear Sir,

     So your Ethernet tasks work well in SDK8.2? 

      In this case could you test in a default SDK 8.4 environment to see if it can work normally? If it is ok then please add your change like vlan one by one and try to localize where the error happens.

BR

Sikai

Dear Sir,

     Do you use Linux or QNX on A72? If you are using QNX, could you try your change on LINUX side to see if it still exists? In Linux side and ETHFW SDK 8.2 and 8.4 is almost the same. You only need to copy the ETHFW binary to Linux side should be fine.

BR

Sikai

Dear Experts,

     Some details from customers:

     1. They confirm their modification based on SDK8.2 is usable. However it is difficult for them to test all the modification step by step since most of the modification are related to hardware. So they cannot test in a default SDK8.4 environment.

     2. During merge,they find some codes in 8.2 cannot find corresponed one in SDK8.4. For example, there are some changes in pdk/packages/ti/drv/enet/examples/utils/V1. As a result, they are not quite sure if their merge is correct. Some of the changes are related to hardware, so they need to do the merge otherwise their board cannot boot.

    3. Here are their changes:

    3.1 modification based on SDK8.2

sdk0802_adcudev_delta.zip

    3.2 modification based on the merge of SDK8.4

sdk0804mod_delta.zip

    3.3 RGMII SCH

    4. Their current configuration: RGMII2 -> PHY2; RGMII3 -> PHY1; RGMII4 -> PHY4, RGMII6 for board internal communication.

Dear Baorui,

     When you say internal communication does it mean MAC-MAC?

BR

Sikai

Hi Sikai,

Yes it is MAC-MAC connection.

Regards

Hui Baorui

Hi Baorui,

>>But TCP and UDP failed. As we captured the ethernet packets on PC and A72 side, we found that the packet has been changed during transmission. For example, an UDP packet got two different destination port captured on both sides.
Do you mean destination port number in UDP packet got changed as compared with packet on PC and A72?
Can you please share packet capture at PC side & A72 side?

Best Regards,
Sudheer 

Hi Sudheer,

Sorry I've got problems uploading the pcap files for some reason. But I have shared them with Sikai before so I think maybe he can help.

Hi Sikai,

I think you still kept the pcap files containing the captured packets on both PC and A72 (tcptest_pc.pcap and tcptest_A72.pcap) I send to you in the emails we talked about this issue at the first time? So would you please help upload them here? Thank you very much!

Best regards

Hui Baorui

Dear Baorui,

     Do you mean this?

https://e2e.ti.com/cfs-file/__key/communityserver-discussions-components-files/791/tcptest_5F00_a72.pcaphttps://e2e.ti.com/cfs-file/__key/communityserver-discussions-components-files/791/tcptest_5F00_pc.pcap

BR

Sikai

Hi Sikai,

Yes, correct. Thank you very much!

Regards

Hui Baorui

Dear Sudheer,

     Some update for better tracking:

     1. This is their change on SDK8.2 compared with default SDK8.2

Sikai Lu said:

sdk0802_adcudev_delta.zip

         And this is their change on SDK8.4 compared with default SDK8.4

Sikai Lu said:

sdk0804mod_delta.zip

    2. Have talked with customer, let them provide the diff file instead of the .c file so that we can know the changes better.

    3. On our evm board, SDK8.4 works fine. Although customer board is different from EVM, I think after they modify related hardware configurations, they still can run a default ETHFW right? So let customer test if they can run normally with a default 8.4 SDK. So that we can avoid this is caused by hardware.

BR

Sikai

Hi Sikai,

Understood.

>>I think after they modify related hardware configurations, they still can run a default ETHFW right
Yes, They can run ping, tcp, udp with default SDK.

Will wait for further update from customer.

Best Regards,
Sudheer

Hi Experts,

We take some time trying to identify what changes are causing this issue following Sikai's suggestion, and we luckily identified only one change is causing the issue. This change is at line 215 in ethfw\utils\intervlan\src\eth_hwintervlan.c:

    pCpswCfg->aleCfg.portCfg[CPSW_ALE_HOST_PORT_NUM].pvidCfg.forceUntaggedEgressMask = 0;

Original value configued here is  CPSW_ALE_ALL_PORTS_MASK, we changed to 0 to keep the vlan tag in packets.

Tests are taken under following situation:

1, keep the original value here, test network works normally without vlan, but met some issue when using vlan (ping to IP with vlan failed);

2, modify this value to 0, network works not normal without vlan, same issue as mentioned before: UDP dest port changing randomly causing UDP communication to fail. But seems working normally when using vlan.

Would you please help to check what is the root cause for this issue and how could we fix it?

Thank you very much!

Best regards.

Hello Sikai,

>>pCpswCfg->aleCfg.portCfg[CPSW_ALE_HOST_PORT_NUM].pvidCfg.forceUntaggedEgressMask = 0;
I do see same configuration in SDK 8.2.
Is the same observed in 8.2 SDK?

>>, keep the original value here, test network works normally without vlan, but met some issue when using vlan (ping to IP with vlan failed);
It is expected as we configured to remove/suppress VLAN tag from packet.

>>, modify this value to 0, network works not normal without vlan, same issue as mentioned before: UDP dest port changing randomly causing UDP communication to fail. But seems working normally when using vlan.
It should work normally if we send VLAN packets.

Best Regards,
Sudheer

Hi Sudheer,

Let me answer you these questions.

Doredla Sudheer Kumar said:

Is the same observed in 8.2 SDK?

No we didn't observed this issue in 8.2 SDK, and thus we kept this modification in SDK 8.2.

Doredla Sudheer Kumar said:

It should work normally if we send VLAN packets.

We haven't done a test on it, but we do observed that when sending UDP packets through VLAN, the UDP packets captured on both side are the same.

So any advise on fix this issue? or you may need more information please let me know.

Thanks and best regards

Hui Baorui

Hi Hui,

CPSW can't control the port number filed in UDP packet, we are suspecting it might be from application side.

Can you please recheck is there any changes in application using with SDK8.2 & SDK8.4?

Also, there is no difference in Ethfw between SDK 8.2 & 8.4 especially related to InterVlan Demo.
When you want to work with VLAN network we have disable InterVlan and if not we can enable InterVlan.

Can you please share log of attached script before and after running your test, to check register settings.
https://e2e.ti.com/cfs-file/__key/communityserver-discussions-components-files/791/Cpsw_5F00_reg_5F00_logging_5F00_script.sh

Best Regards,
Sudheer

Hi Sudheer,

Would you please address again what kind of application changes you're looking for? For our applications, there're no changes at all comparing SDK 8.2 to SDK 8.4.

And we've conducted an additional test with this flag disabled by simply sending UDP packets (unicast and broadcast) and use tcpdump to capture the packets on both sides. Here are what we've found:

    1, Using an IP without vlan, PC can receive packets sent from A72, but A72 could not receive packets sent by PC.

    2, Using an IP without vlan, the packets sent contains no vlan tag on A72 side but vlan tags are found with vlan id = 300 in the packets received by PC, also the UDP dst port is changing packet to packet.

    3, Everything is normal when using an IP with vlan config.

And below is the register settings after this test. the register value have no changes before and after the test:

=================Reading CPSW Registers=================
    CPSW_ALE_CONTROL_REG (0x0c03E008)          : 0x800000C4
    CPSW_ALE_UVLAN_MEMBER_REG (0x0c03E090)     : 0x00000000
    CPSW_ALE_UVLAN_URCAST_REG (0x0c03E094)     : 0x00000000
    CPSW_ALE_UVLAN_RMCAST_REG (0x0c03E098)     : 0x00000000
    CPSW_ALE_UVLAN_UNTAG_REG (0x0c03E09C)      : 0x00000000
    CPSW_CONTROL_REG (0x0c020004)              : 0x0000E00E
    CPSW_VLAN_LTYPE_REG (0x0c020050)           : 0x88A88100
    CPSW_P0_VLAN_REG (0x0c021014)              : 0x0000E12C
    CPSW_P1_VLAN_REG (0x0c022014)              : 0x00000000
    CPSW_P2_VLAN_REG (0x0c023014)              : 0x00000000
    CPSW_P3_VLAN_REG (0x0c024014)              : 0x00000001
    CPSW_P4_VLAN_REG (0x0c025014)              : 0x00000001
    CPSW_P5_VLAN_REG (0x0c026014)              : 0x00000001
    CPSW_P6_VLAN_REG (0x0c027014)              : 0x00000001
    CPSW_P7_VLAN_REG (0x0c028014)              : 0x00000000
    CPSW_P8_VLAN_REG (0x0c029014)              : 0x00000000

What we've observed is that seems after disabling this flag, cpsw will add a vlan tag even if the packet itself did not contain a vlan tag. Is that expected behivour for cpsw?

By the way, although we can confirm that by enabling this flag, the cpsw works fine for IPs without vlan, but the boradcast issue for vlan still exists. Meaning that we could not send broadcasts to A72 within vlan.

I would like to add some of our test results like tcpdump files for you to check but I've got issues when uploading them, is there any alternative ways to upload files?

Thanks for your kindly support.

Best regards.

Hui Baorui

Hi Hui,

Sorry for delayed response.

>>Would you please address again what kind of application changes you're looking for?
I mean UDP test application using to test 8.2 & 8.4 SDKs.

>> 1, Using an IP without vlan, PC can receive packets sent from A72, but A72 could not receive packets sent by PC.
>> 2, Using an IP without vlan, the packets sent contains no vlan tag on A72 side but vlan tags are found with vlan id = 300 in the packets received by PC,
From point 2 it seems like A72 receiving the packets sent from PC and has no vlan tag.
packets from A72 to PC will have vlan of 300 is expected as per register configuration, if no valn tag in packet Host port will add vlan value configured in it's VLAN register (CPSW_P0_VLAN_REG (0x0c021014) : 0x0000E12C).

>> 3, Everything is normal when using an IP with vlan config.
Expected as VLAN stripping is disabled on egress ports while configuring the ALE.


>>What we've observed is that seems after disabling this flag, cpsw will add a vlan tag even if the packet itself did not contain a vlan tag. Is that expected behivour for cpsw?
yes, As CPSW is configured in VLAN aware mode. If packet on egress ports will not have VLAN then CPSW will add VLAN configured in port specific registers.

>> By the way, although we can confirm that by enabling this flag, the cpsw works fine for IPs without vlan,
yes, as Intervlan is enabled along with stripping of VLAN on egress ports.

>>but the boradcast issue for vlan still exists. Meaning that we could not send broadcasts to A72 within vlan.
Will check and update you on this.

>>I would like to add some of our test results like tcpdump files for you to check but I've got issues when uploading them, is there any alternative ways to upload files?
Please let us know what kind of error you are getting, If restrictions from your organization please send logs to s-doredla@ti.com , will upload here on your behalf.

Best Regards,
Sudheer