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.

DRA821U: DRA821U

Part Number: DRA821U


Dear TI,

What are the settings we need to make in the Ethernet Firmware to receive broadcast packets on specific port for vlan interface.

1. We are able to receive broadcast packets on physical interface of A72.

2. But for the vlan created on the same physical interface, broadcast packets are not received. (ex: arp requests are not received on the vlan interface if we see it through tcp dump. We are pining to vlan from external pc vlan interface)

3. If we try sending arp packets from vlan (ping from vlan interface to external pc) it will send and ping will work.

Can you please guide what we need to configure in ethfw related to vlan creation to receive broadcast packets related to that vlan. And ping from exernal pc vlan will work to vlan created on physical interface of A72.

Thanks,

Bharat

  • Dear TI,

    1. We have trouble with ping, as like

    (1) VLAN Ping is failed from PC to A72 core

         such as, VLAN 73 is created on A72 core, and 160.48.199.97 ip address is assigned to eth0.73. for the ping test, we added a network adapter on PC (VLAN ID 73, IP address 160.48.199.96). Here we failed to ping from PC to A72 core, but it works conversely(ping from A72 core to PC).

    (2) Ping with eth0 is succeed from PC to A72 core.

         As it is remarked, If eth0 have an ip address, ping is ok from PC to A72 core. 

    2. By the way, we saw some TI tickets with the same issue, and they are saying that it can be solved with SDK8.1.

        Please confirm it.

      e2e.ti.com/.../3694447

    https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1007735/tda4vm-j7200-7-3-sdk-demo-board-how-to-use-quad-port-ethernet-expansion-board

     e2e.ti.com/.../tda4vm-ethfw-server-and-remote-client-can-not-ping-each-other

    3. Please review CPSW EthFW logs to check whether all is ok.

    root@icon-bam:~# cat /sys/kernel/debug/remoteproc/remoteproc1/trace0
    =======================================================
    CPSW Ethernet Firmware
    =======================================================
    ETHFW: Shared multicasts (software fanout):
    01:00:5e:00:00:01
    01:00:5e:00:00:fb
    01:00:5e:00:00:fc
    33:33:00:00:00:01
    33:33:ff:1d:92:c2
    01:80:c2:00:00:00
    01:80:c2:00:00:03
    ETHFW: Reserved multicasts:
    01:80:c2:00:00:0e
    01:1b:19:00:00:00
    EnetMcm: CPSW_5G on MAIN NAVSS
    Enet_open: cpsw5g: features: 0x00000002
    Enet_open: cpsw5g: errata : 0x00000000
    PHY 0 is alive
    CpswMacPort_configSgmii: MAC 2: Configure SGMII in SGMII_FORCEDLINK mode
    EnetPhy_setNextState: PHY 0: INIT -> FINDING (20 ticks)
    EnetPhy_setNextState: PHY 0: FINDING -> LINK_WAIT (50 ticks)
    EnetPhy_bindDriver: PHY 0: OUI:0d6414 Model:3b Ver:0d <-> 'vsc8514'
    EnetPhy_bindDriver: PHY 0: OUI:0d6414 Model:3b Ver:0d <-> 'dp83822'
    EnetPhy_bindDriver: PHY 0: OUI:0d6414 Model:3b Ver:0d <-> 'dp83867'
    EnetPhy_bindDriver: PHY 0: OUI:0d6414 Model:3b Ver:0d <-> 'bcm89884'
    EnetPhy_bindDriver: PHY 0: OUI:0d6414 Model:3b Ver:0d <-> 'bcm89884' : OK
    EnetPhy_open: PHY 0: open
    EnetPhy_showLinkPartnerCompat: PHY 0: recommended link partner config: manual mode at 1 Gbps full-duplex

    ETHFW Version : 0.02.00
    ETHFW Build Date: Jun 9, 2022
    ETHFW Build Time: 09:32:31
    ETHFW Commit SHA: dd110067

    Starting lwIP, local interface IP is dhcp-enabled
    Host MAC address: 70:ff:76:1d:92:c3
    [LWIPIF_LWIP] Enet LLD netif initialized successfully
    [LWIPIF_LWIP_IC] Interface started successfully
    [LWIPIF_LWIP_IC] NETIF INIT SUCCESS
    [LWIPIF_LWIP_IC] Interface started successfully
    [LWIPIF_LWIP_IC] NETIF INIT SUCCESS
    Added interface 'br4', IP is 0.0.0.0
    CpswProxyServer: Virtual port configuration:
    mpu_1_0 <-> Switch port 0: mpu_1_0_ethswitch-device-0
    mpu_1_0 <-> Switch port 1: mpu_1_0_ethswitch-device-1
    CpswProxyServer: initialization completed (core: mcu2_0)
    [IPC] TX Virtio creation failure: 0
    [IPC] Ipc_lateVirtioCreate: Failed to create VirtIO for procId..
    EthApp_initIpcTask: Ipc_lateVirtioCreate failed: -1
    Function:CpswProxyServer_attachExtHandlerCb,HostId:0,CpswType:5
    EnetPhy_findCommonCaps: PHY 0: local caps: FD1000
    EnetPhy_findCommonCaps: PHY 0: partner caps: FD1000
    EnetPhy_findCommonCaps: PHY 0: common caps: FD1000
    EnetPhy_findCommon1000Caps: PHY 0: local caps: FD1000
    EnetPhy_findCommon1000Caps: PHY 0: partner caps: FD1000
    EnetPhy_findCommon1000Caps: PHY 0: common caps: FD1000
    EnetPhy_findCommonNwayCaps: PHY 0: common caps: FD1000
    EnetPhy_linkWaitState: PHY 0: negotiated mode: 1 Gbps full-duplex
    EnetPhy_setNextState: PHY 0: LINK_WAIT -> LINKED (0 ticks)
    Cpsw_isPortLinkUp: Port 3: Sublayer 1 doesn't support link status
    Cpsw_handleLinkUp: Port 3: Link up: 1-Gbps Full-Duplex
    Function:CpswProxyServer_registerMacHandlerCb,HostId:0,Handle:a2a6f330,CoreKey:38acb7e6, MacAddress:70:ff:76:1d:92:c1, FlowIdx:84, FlowIdxOffset:0
    Cpsw_ioctlInternal: CPSW: Registered MAC address. ALE entry:17, Policer Entry:1
    Function:CpswProxyServer_filterAddMacHandlerCb,HostId:0,Handle:a2a6f330,CoreKey:38acb7e6, MacAddress:33:33:0:0:0:1, vlanId:0, FlowIdx:84, FlowIdOffset:0
    Function:CpswProxyServer_filterAddMacHandlerCb,HostId:0,Handle:a2a6f330,CoreKey:38acb7e6, MacAddress:1:80:c2:0:0:21, vlanId:0, FlowIdx:84, FlowIdOffset:0
    Function:CpswProxyServer_filterAddMacHandlerCb,HostId:0,Handle:a2a6f330,CoreKey:38acb7e6, MacAddress:1:0:5e:0:0:1, vlanId:0, FlowIdx:84, FlowIdOffset:0
    Function:CpswProxyServer_filterAddMacHandlerCb,HostId:0,Handle:a2a6f330,CoreKey:38acb7e6, MacAddress:1:80:c2:0:0:0, vlanId:0, FlowIdx:84, FlowIdOffset:0
    Function:CpswProxyServer_filterAddMacHandlerCb,HostId:0,Handle:a2a6f330,CoreKey:38acb7e6, MacAddress:1:80:c2:0:0:3, vlanId:0, FlowIdx:84, FlowIdOffset:0
    Function:CpswProxyServer_filterAddMacHandlerCb,HostId:0,Handle:a2a6f330,CoreKey:38acb7e6, MacAddress:1:80:c2:0:0:e, vlanId:0, FlowIdx:84, FlowIdOffset:0
    CpswProxyServer_isRsvdMcast: Reserved mcast cannot be added to filter
    Function:CpswProxyServer_filterAddMacHandlerCb,HostId:0,Handle:a2a6f330,CoreKey:38acb7e6, MacAddress:33:33:ff:1d:92:c1, vlanId:0, FlowIdx:84, FlowIdOffset:0
    Function:CpswProxyServer_filterAddMacHandlerCb,HostId:0,Handle:a2a6f330,CoreKey:38acb7e6, MacAddress:33:33:ff:0:0:0, vlanId:0, FlowIdx:84, FlowIdOffset:0
    Function:CpswProxyServer_filterAddMacHandlerCb,HostId:0,Handle:a2a6f330,CoreKey:38acb7e6, MacAddress:1:0:5e:0:0:fc, vlanId:0, FlowIdx:84, FlowIdOffset:0
    Function:CpswProxyServer_filterAddMacHandlerCb,HostId:0,Handle:a2a6f330,CoreKey:38acb7e6, MacAddress:33:33:ff:0:0:69, vlanId:0, FlowIdx:84, FlowIdOffset:0
    Function:CpswProxyServer_filterAddMacHandlerCb,HostId:0,Handle:a2a6f330,CoreKey:38acb7e6, MacAddress:33:33:ff:0:0:e3, vlanId:0, FlowIdx:84, FlowIdOffset:0
    Function:CpswProxyServer_filterAddMacHandlerCb,HostId:0,Handle:a2a6f330,CoreKey:38acb7e6, MacAddress:33:33:0:1:0:3, vlanId:0, FlowIdx:84, FlowIdOffset:0
    root@icon-bam:~#

    4.  Ti page describes that Broadcast/Multicast packets are sent to R5F core, and they should be forwared to A72 core through shared memory Transport.

    We want to clarify whether it is needed for forwarding broadcast packets(ARP request packets). Here we are going to use A72 core mainly, so we want to get all traffics coming into A72 core.

    https://software-dl.ti.com/jacinto7/esd/processor-sdk-rtos-j7200/08_02_00_05/exports/docs/ethfw/docs/user_guide/ethfw_c_ug_top.html#ethfw_intercore_topology

  • Hi,

    Apologies for the delay.

    What are the settings we need to make in the Ethernet Firmware to receive broadcast packets on specific port for vlan interface.

    SDK 8.1+, all the cores will receive the broadcast packets and will be able to register multicast addresses.

    We want to clarify whether it is needed for forwarding broadcast packets(ARP request packets). Here we are going to use A72 core mainly, so we want to get all traffics coming into A72 core.

    The way broadcast and multicast routing is done is indeed by inter-core communication by shared memory transport. So all the broadcast and multicast frames go through ethfw server.

    By the way, we saw some TI tickets with the same issue, and they are saying that it can be solved with SDK8.1.

    Yes, there was such an issue which was caused due to A72 not receiving the broadcast frames. It was resolved in SDK8.1+

    Regards,
    Tanmay