• State TI Thinks Resolved
  • Locked Locked
  • Replies 6 replies
  • Answers 1 answer
  • Subscribers 100 subscribers
  • Views 1130 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

Linux/AM5718: Possible bug in latest 05.01.00.11 CPSW driver

JUN SUN
Prodigy 30 points
Part Number: AM5718

Tool/software: Linux

Hi,

Latest SDK Linux-rt 05.01.00.11 CPSW driver drop minimum size (64 byte) Ethernet packets, report them as misaligned/code error packets, but the previous version 04.02.00.09 does not have this issue. Compare the driver code (cpsw.c), I found this is cause by the change of minimum and maximum packet size definition in cpsw.c:

cpsw.c 04.02.00.09 compared with 05.01.00.11:

123,124c124,128
< #define CPSW_MIN_PACKET_SIZE    60
< #define CPSW_MAX_PACKET_SIZE    (1500 + 14 + 4 + 4)
---
> #define CPSW_RX_VLAN_ENCAP_HDR_SIZE        4
> #define CPSW_MIN_PACKET_SIZE    (VLAN_ETH_ZLEN)
> #define CPSW_MAX_PACKET_SIZE    (VLAN_ETH_FRAME_LEN +\
>                  ETH_FCS_LEN +\
>                  CPSW_RX_VLAN_ENCAP_HDR_SIZE)

Here VLAN_ETH_ZLEN is 64, so CPSW_MIN_PACKET_SIZE changed from 60 to 64, that cause the problem.

BTW, I think CPSW_MAX_PACKET_SIZE is also wrong, it changed from 1522 to 1526, the reason is checksum length counted twice.

Please check.

Regards,

Jun

  • 0
    TI__Mastermind 38720 points
    Hi,

    As you point there was a change to allow for VLAN routing type use cases. Could your use case that is having an issue?

    Best Regards,
    Schuyler
  • 0 in reply to Schuyler Patton
    TI__Mastermind 38720 points
    Hi,

    I apologize I did not proof read my last post well enough. My last line was supposed to be this:

    Could you please describe your use case that is having the issue?

    Best Regards,
    Schuyler
  • 0 in reply to Schuyler Patton
    Prodigy 30 points

    Hi,

    I am running IgH EtherCAT master on the AM5718 IDK board. I configure the EtherCAT master to use its "generic" driver which use a raw Ethernet interface to communicate with the slave boards. I use CPSW in dual Ethernet port mode as it is in default Linux RT package without any change. The master send/receive short 64 byte raw Ethernet packets for its routing operation. We observed that the packet is sent but not received, the ethtool reported a lot of mis-aligned/code error packet. 

    But SDK 4.2 do not have this issue. So I think the definition of minimum / maximum size is wrong.

    Regards,

    Jun

  • 0 in reply to JUN SUN
    TI__Mastermind 38720 points
    Hi,

    We will have to take your report under advisement for the moment . This post is the second report of the small packet size causing issues for industrial protocols. There have been additions to the cpsw driver based on linux community input, these changes maybe causing the issues that you are reporting.

    What is IgH? Is this a third party package? Also, when observing, who is sending the packets (the master?) and who is intended to receive the packets (the slave?)? Can you explain how you know it is packet size as the issue and not packet structure? Where are the code error packets being reported?

    At the moment we do not have a solution identified, the cpsw driver changes that have been made are required for other use cases.

    Best Regards,
    Schuyler
  • 0 in reply to Schuyler Patton
    Prodigy 30 points

    Hi,

    IgH is a vendor of EtherCAT master software, sometime also refer as Etherlab, the link is here:

    The master send these short packet out to a slave and slave send them back to master.

    Jun

  • 0 in reply to JUN SUN
    TI__Mastermind 38720 points
    Hi Jun,
    Thanks for the information on the package that you are using for EtherCAT. As I mentioned we currently do not have a solution. As I mentioned earlier the change was made due to another community requirement. We will need to assess how to proceed and find a solution that satisfies your requirement and the community. For the time I would recommend remaining on the earlier SDK that you referenced if that is a possibility.
    Best Regards,
    Schuyler