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

Part Number: TDA4VM

Hello Team,

In the TDA4VM Technical Reference Manual (DRA829/TDA4VM Technical Reference Manual (Rev. C)), I found the following information with regards to CPSW 9-port switch ALE Automotive Security Features:

• VLANs can be configured to not allow fragmented IPv4 frames. That is a VLAN can be configured to not allow fragmented IPv4 traffic.

• VLANs can be configured to only allow up to four different IPv4 Protocols or IPv6. Next Header values, for example a VLAN can be configured to only allow TCP traffic in both IPv4 and IPv6 packets.

• Drop invalid Source Addresses, that is drop Source Addresses with bit 40 set (Multicast/Broadcast indicator on Destination Addresses)

• IEEE802.3 Length Check, drop frames that the IEEE802.3 Length is not contained within the frame. (Ether Types 0-1500)

• Any Source Address can be secured to a port dropping any attempts from other ports to masquerade as a service.

• Any source or destination address can be blocked.

• Per Port or Per VLAN ingress checking, dropping traffic from non-member ports.

• Classification, Policing on L2 and L3 information

However, I could not find any information regarding how to configure/enable these features. Could you please provide more information on how these features can be enabled in the CPSW switch?

  • Hi,

    Sorry for the delayed response.

    VLANs can be configured to not allow fragmented IPv4 frames. That is a VLAN can be configured to not allow fragmented IPv4 traffic.

    • VLANs can be configured to only allow up to four different IPv4 Protocols or IPv6. Next Header values, for example a VLAN can be configured to only allow TCP traffic in both IPv4 and IPv6 packets.

    • Drop invalid Source Addresses, that is drop Source Addresses with bit 40 set (Multicast/Broadcast indicator on Destination Addresses)

    • IEEE802.3 Length Check, drop frames that the IEEE802.3 Length is not contained within the frame. (Ether Types 0-1500)

    Above features can be enabled/disabled using the ALE control register configuration.
    Please refer to bit fields 23,22,21,20 (DROP_BADLEN, NODROP_SRCMCST, DEFNOFRAG, DEFLMTNXTHDR) of CPSW_ALE_CTRL2 register from TRM.

    Also, default above features were disabled Software (Ethernet Firmware).

    Any Source Address can be secured to a port dropping any attempts from other ports to masquerade as a service.

    • Any source or destination address can be blocked.

    • Per Port or Per VLAN ingress checking, dropping traffic from non-member ports.

    • Classification, Policing on L2 and L3 information

    Above features can be configured using ALE entries.
    Please refer to FAQ (How to Configure CPSW 5G/9G ALE) for sample ALE configuration to A72 in case of Ethernet Firmware + A72 client Use Case.

    Best Regards,
    Sudheer

  • Hello,

    Thank you for your response. I will take a look into these configurations and get back to you in case of further questions.

    I do have one more question. We would like to disable certain protocols (eg ICMP, ARP etc) in the CPSW switch. However, it looks like these protocols are used by the CPSW driver during boot. Could you tell me what is the use case of these protocols during boot and how can we disable them after boot?

  • Hi,

    We would like to disable certain protocols (eg ICMP, ARP etc) in the CPSW switch.

    These protocols are not handled at CPSW HW level, In case of Ethernet Firmware it will be part of LWIP (Network stack) running on MCU2_0.
    When DHCP network is connected to any of CPSW ports then only ARP messages will be sent by CPSW for allocating IP to the Interfaces (switch/MAC).

    If nothing is connected to CPSW External ports, we may not observe ARP messaged during boot.

    how can we disable them after boot?

    These protocols enabled via defined MACROs, can't be disabled after boot.
    If we don't want we can suppress support from LWIP by undefining MACROs from "<PSDK_RTOS>/<pdk>/packages/ti/transport/lwip/lwip-port/freertos/include/lwipopts.h"

    Best Regards,
    Sudheer

  • Hello,

    Thank you for your response.

    I undefined the macro LWIP_ARP in "<PSDK_RTOS>/<pdk>/packages/ti/transport/lwip/lwip-port/freertos/include/lwipopts.h" but this didn't work. ARP is still functional.

    We are now trying to block ARP using ALE policer. For this, we added a table entry for EtherType ARP and a policer rule to match the EtherType ARP. But how can I configure the policer to drop the ARP packets once it matches the policer? Is it possible to achieve this?

  • Hi Alisha,

    I undefined the macro LWIP_ARP in "<PSDK_RTOS>/<pdk>/packages/ti/transport/lwip/lwip-port/freertos/include/lwipopts.h" but this didn't work. ARP is still functional

    Can you please confirm, have you undefined the LWIP_ARP Macro or defined with '0'. If undefined can you please check by defining it with '0' as "#define LWIP_ARP 0".

    Best Regards,
    Sudheer

  • Hi,

    I accidentally made the changes in tirtos/include/lwipopts.h. Now I have made the changes in the correct file (I have defined LWIP_ARP as 0), but the board does not boot. I believe the driver is using some protocols during boot to communicate with the SCI client. Therefore we were looking for a way to disable the protocols after boot.