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.

How to filter out FCS data in Ethernet packet on AM335x?

Hi,

I'm just starting to learn AM335x, and am writing a program on Linux. 

This program is to deal with Profinet packet. And the FCS data in ethernet packet is also passed to my application program which is not my need. I'd like to know how to configure the AM335x chip or CPSW to filter out FCS data.

My hardware is similar to official AM335x develop board, so I think it is not related to hardware design.

Thank you!

Charles

  • Hi,

    I'll forward this to the factory team. Which Linux kernel version are you using?

    Best regards,
    Miroslav

  • I am not sure this is a CPSW issue since this sounds like you are setting up a raw socket in your application. Could you post how you are opening the socket and what the FCS portion you are concerned about? 

  • Hi Miroslav,

    Linux kernel 3.2 and I made a RT-Preempt patch v10.0.

    Best wishes,

    Charles

  • Schuyler Patton said:

    I am not sure this is a CPSW issue since this sounds like you are setting up a raw socket in your application. Could you post how you are opening the socket and what the FCS portion you are concerned about? 

    Actually this issue is from my German colleague. He told me that in his application APIs of libpcap were called and the length of ethernet telegram was got through pcap structure "pcap_pkthdr". The content of the telegram was delivered by a pointer. He had no means to distinguish between FCS and non-FCS frames.

    The telegram he got was like this

    locRcvRtn[0]: header->len = 68
      88 33 14 f6 b9 a2 00 0e 8c ac a9 55 81 00 c0 00
      88 92 c0 03 00 00 00 00 00 00 00 00 00 00 00 00
      00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
      00 00 00 00 00 00 00 00 00 00 00 00 b2 e0 35 00
      ad 52 81 38

    As is known, the shortest length of one telegram should be 64 bytes. I don't know why there are extra 4 bytes.

    Version of Linux is 3.2 and I have patched RT-preempt v10.0. And libpcap version is 1.3.0 with compiler arm-none-linux-gnueabi-gcc(arm-2010q1).

  • That looks like what we do when implementing Profinet on PRU-ICSS... we have to add 4 to packet buffer length to compensate for storing the FCS.

    On the low level you are receiving a byte stream including FCS. That allows any application to also check the FCS. If it is not needed then just reduce length by 4 when working on the buffer. I think that is what network stacks do to. They just remove the FCS once it is not needed anymore.

    regards,

  • Frank Walzer said:

    That looks like what we do when implementing Profinet on PRU-ICSS... we have to add 4 to packet buffer length to compensate for storing the FCS.

    On the low level you are receiving a byte stream including FCS. That allows any application to also check the FCS. If it is not needed then just reduce length by 4 when working on the buffer. I think that is what network stacks do to. They just remove the FCS once it is not needed anymore.

    regards,

    Yes, we're implementing Profinet Controller Stack on AM335x with Linux. The stack doesn't accept the FCS data and returns error.

    Like what you suggest, we just ignore the 4 bytes FCS in buffer. It could be the most convenient way to get stack running for the time being. But I still think there should be some switch in driver to enable or disable PHY delivering FCS.