TDA4VM: Ethernet Link status is not getting communicated to A72

Thank you Tanmay for the reply.

This is seen in MCU2_0 EthFW is not conveying Link status to A72 over virtual MAC.

Regards,

Kishore

Hi Tanmay,

Can you please recreate this in your setup ?

Hi Kishore,

Apologies for the delay. I had my setup busy with something else and wasn't able to recreate this on my setup. I will recreate this and post a reply by tomorrow.

I confirmed this with the development team and they confirmed that there is no notification sent from the Ethfw to virtual clients for a link disconnect. The virtual client can query the status, but it will receive no callbacks from ethfw. Hence this behavior is expected.

May I know what use-case is this regarding so that I can propose a solution/workaround for this.

Regards,
Tanmay

Hi Tanmay,

Thank you for the response.

The use case is :

Hi Kishore,

I discussed this with my colleagues and got to know that we currently do not have any functionality to query the link status in the virtual MAC driver.

I have submitted the requirement for the functionality to be added. I will update you on its status here.

Regards,
Tanmay

Hi Tanmay,

Thank you for your response.

If possible, can you provide a quick patch so that we can check it at our end?

Hi Kishore,

The requirement is a work in progress. I will check on the tentative time at which it will be completed. I will share with you the patch that adds this functionality.

If its very urgent, a very hacky workaround for this could be to poll the Ethfw logs for link down message. You can get the ethfw logs using the command "cat /sys/kernel/debug/remoteproc/remoteproc*/trace0". If you poll for the link-down message in this, you can track the status in linux userspace. 

Regards,
Tanmay

Hello Tanmay,

Thank you for this update.

Actually we also planned to read from remote logs. As of now, we can go with it.

Can you please give us the timeline for the proper fix ?

Thanks.

Kishore

Hello Tanmay,

Thanks for the update.

We tried this patch and it seems to be not working,

Is this patch for 8.1 SDK or above ?

Is there also equivalent change/patch for the link status at the ethfw side too ?

Regards,

Kishore

Hi Tanmay,

Gentle reminder.

Hi Tanmay,

We tried the suggested command and did not get the Link status after remove and connect back the Ethernet cable.

The result of the command is as follow:

Every 1.0s: cat /sys/kernel/debug/remoteproc/remoteproc0/trace0 /sys/kernel/debug/remoteproc/remoteproc1/trace0 /sys/kerne2021-12-20 18:15:15

DM Built On: Feb 1 2022 11:02:03
Sciserver Version: v2022.01.1.0-REL.CORESDK.08.02.00.03-11-g14556b+
RM_PM_HAL Version: v2022.01-1-gfc8ee
Starting Sciserver..... PASSED
IPC_echo_test (core : mcu1_0) .....
IPC Driver Revision: 01.00.00.01

No message related to Link Up/Down was observed.

One more method we tried, where we redirected the logs of ./vx_app_arm_remote_log.out.

Here observation is:

Link UP message we were able to grep (Cpsw_handleLinkUp: Port 2: Link up: 1-Gbps Full-Duplex) but Link Down message was not coming.

Link Down message came after next iteration of connecting back the Ethernet cable.

Please let us know if you have a compatible patch for sdk 8.1.

Thanks

Kishore

Hi Kishore,

Though the patch was for current tip of git, there shouldn't be any issue to apply and use the patch with SDK 8.1 as there are no changes to rpmsg-kdrv which is used to send messages to ethfw.

So are you using vision apps? 

Kishore Mali said:

Link Down message was not coming.

If you are not getting a Link Down message in ethfw, then the issue would be different. Is this a new observation or were you unable to see link-down messages earlier as well?

The logs also seem to be correct, there are no prints from ethfw. You should see prints like this :

=======================================================
            CPSW Ethernet Firmware
=======================================================
Warning: Using 6 MAC address(es) from static pool
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_9G on MAIN NAVSS
PHY 0 is alive
PHY 3 is alive
PHY 12 is alive
PHY 16 is alive
PHY 17 is alive
PHY 18 is alive
PHY 19 is alive
PHY 23 is alive
EnetPhy_bindDriver: PHY 12: OUI:080028 Model:23 Ver:01 <-> 'dp83867' : OK
EnetPhy_bindDriver: PHY 0: OUI:080028 Model:23 Ver:01 <-> 'dp83867' : OK
EnetPhy_bindDriver: PHY 3: OUI:080028 Model:23 Ver:01 <-> 'dp83867' : OK
EnetPhy_bindDriver: PHY 16: OUI:0001c1 Model:27 Ver:00 <-> 'vsc8514' : OK
EnetPhy_bindDriver: PHY 17: OUI:0001c1 Model:27 Ver:00 <-> 'vsc8514' : OK
EnetPhy_bindDriver: PHY 18: OUI:0001c1 Model:27 Ver:00 <-> 'vsc8514' : OK
EnetPhy_bindDriver: PHY 19: OUI:0001c1 Model:27 Ver:00 <-> 'vsc8514' : OK
ETHFW Version   : 0.02.00
ETHFW Build Date: Aug  1, 2022
ETHFW Build Time: 10:41:24
ETHFW Commit SHA: 08eae19c
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
  mcu_2_1 <-> Switch port 1: mcu_2_1_ethswitch-device-1
  mpu_1_0 <-> MAC port 1: mpu_1_0_ethmac-device-1
  mcu_2_1 <-> MAC port 4: mcu_2_1_ethmac-device-4
CpswProxyServer: initialization completed (core: mcu2_0)
Function:CpswProxyServer_attachExtHandlerCb,HostId:4,CpswType:6
Function:CpswProxyServer_ioctlHandlerCb,HostId:4,Handle:a2a49524,CoreKey:38acb976, Cmd:1010401,InArgsLen:0, OutArgsLen:4
Function:CpswProxyServer_ioctlHandlerCb,HostId:4,Handle:a2a49524,CoreKey:38acb976, Cmd:1010201,InArgsLen:24, OutArgsLen:4
Function:CpswProxyServer_registerMacHandlerCb,HostId:4,Handle:a2a49524,CoreKey:38acb976, MacAddress:70:ff:76:1d:92:c4, FlowIdx:179, FlowIdxOffset:7
Cpsw_ioctlInternal: CPSW: Registered MAC address. ALE entry:6, Policer Entry:1
Function:CpswProxyServer_registerRemoteTimerHandlerCb,HostId:4,Handle:a2a49524,CoreKey:38acb976, Name:mcu_2_1_ethswitch-device-1, Timer:1, PushNum:2
Function:CpswProxyServer_attachExtHandlerCb,HostId:4,CpswType:6
Function:CpswProxyServer_ioctlHandlerCb,HostId:4,Handle:a2a49524,CoreKey:38acb976, Cmd:1010401,InArgsLen:0, OutArgsLen:4
Function:CpswProxyServer_ioctlHandlerCb,HostId:4,Handle:a2a49524,CoreKey:38acb976, Cmd:1010201,InArgsLen:24, OutArgsLen:4
Function:CpswProxyServer_registerMacHandlerCb,HostId:4,Handle:a2a49524,CoreKey:38acb976, MacAddress:70:ff:76:1d:92:c5, FlowIdx:180, FlowIdxOffset:8
Cpsw_handleLinkUp: Port 3: Link up: 1-Gbps Full-Duplex
Added interface 'br4', IP is 192.168.50.42
EthFw: TimeSync PTP enabled
Rx Flow for Software Inter-VLAN Routing is up

Is something like this not visible at all?

Regards,
Tanmay

Hello Tanmay,

Regarding 

>>If you are not getting a Link Down message in ethfw, then the issue would be different. Is this a new observation or were you unable to see link-down messages earlier as well?

: We are able to see link up-down logs as I mentioned in my previous comment that 

Link UP message we were able to grep (Cpsw_handleLinkUp: Port 2: Link up: 1-Gbps Full-Duplex) but Link Down message was not coming.

Link Down message came after next iteration of connecting back the Ethernet cable.

So, we are able to get Link up-down message.

Basically, our requirement is to get the link status in A72 side.

Thanks.

Kishore

Hi Tanmay,

Thanks for your update.

As we have TDA4VM custom board.
I followed the steps suggested by you :

1. Run "ethtool eth0" command on custom board to see the link status.

root@j7-evm:~# ethtool eth0
Settings for eth0:
Link detected: no
root@j7-evm:~# ethtool eth0
Settings for eth0:
Link detected: no
root@j7-evm:~# ethtool eth0
Settings for eth0:
Link detected: no
root@j7-evm:~# ethtool eth0
Settings for eth0:
Link detected: no

It is showing as "Link detected: no" always, irrespective of the cable state (Plugged in/out).

2. One more query,
Regarding your comment :
One thing to note would be that the link status is only applicable for mac-only port (eth2 in default SDK). It doesn't make sense for switch port (eth1 in default SDK).

So, as you mentioned that link status is only applicable for mac-only port.
In the code, it seems to be SWITCH_PORT. Do you mean changing it to MAC_PORT, will it work ?

static EthFw_VirtPortCfg gEthApp_virtPortCfg[] =
{
{
.remoteCoreId = IPC_MPU1_0,
.portId = ETHREMOTECFG_SWITCH_PORT_0,
},
{
.remoteCoreId = IPC_MCU2_1,
.portId = ETHREMOTECFG_SWITCH_PORT_1,
},
#if 0
{
.remoteCoreId = IPC_MPU1_0,
.portId = ETHREMOTECFG_MAC_PORT_2,
},
{
.remoteCoreId = IPC_MCU2_1,
.portId = ETHREMOTECFG_MAC_PORT_4,
},
#endif
};

Hi,

The MAC_PORT and SWITCH_PORT are two quite different type of port. MAC_PORT is kind of one-to one connection with the external port where as SWITCH_PORT is can communicate with all the external ports which are switch ports. Please find more information here.

So changing the port type would be a design decision. Changing it to MAC_PORT will work, but I don't know if it will be useful for you.

Reagrds,
Tanmay

Hi Tanmay,

In our custom board, we are using SWITCH_PORT configuration.

So switching to MAC_PORT  is not useful for us.

Thanks,

Kishore