TDA4VP-Q1: Ethernet Firmware for PTP and PTP adaptation

Hi, 

Our ethernet expert is out of office today. Please expect a delay in responses.

Regards,

Josiitaa

Hi,

mohamed elghoury said:

Could you please support to provide a documentation for the Time sync feature support for the Ethernet firmware that will be run on R5F0_0 core

ETHFW support timesync with external network using gPTP from R5F0_0.

ETHFW User Guide explains about how to run gPTP Demo.
https://software-dl.ti.com/jacinto7/esd/processor-sdk-rtos-jacinto7/09_02_00_05/exports/docs/ethfw/docs/user_guide/demo_ethfw_combined_top.html#ethfw_demo_gptp

Also, some API Guide available from PDK.
https://software-dl.ti.com/jacinto7/esd/processor-sdk-rtos-j784s4/10_01_00_04/exports/docs/pdk_j784s4_10_01_00_25/docs/apiguide/j784s4/html/group__gptp.html

gPTP stack is from third party.

mohamed elghoury said:

we are working on architecture design for the time sync feature, and it will be run on A72 cores 

You mean running gPTP from client? It is not supported from SDK.
You can route gPTP packets to client instead of server running on MCU2_0 R5F.

You can use native Linux driver for CPSW9G, then you use case gPTP supported on Linux for timesync.

Best Regards,
Sudheer

Regarding your reply "You mean running gPTP from client? It is not supported from SDK.
You can route gPTP packets to client instead of server running on MCU2_0 R5F."

So, if there are some applications run on A72 cores and need the info of the timestamp of the global network, these applications shall use the APIs which are supported from TI SDK to get this info from R5F0_0?

am i understand correctly?

Hi,

mohamed elghoury said:

Regarding your reply "You mean running gPTP from client? It is not supported from SDK.
You can route gPTP packets to client instead of server running on MCU2_0 R5F.

Yes, TI SDK doesn't support running gPTP from client.
As CPTS is owned by ETHFW server, client can't control the H/W module.

mohamed elghoury said:

So, if there are some applications run on A72 cores and need the info of the timestamp of the global network, these applications shall use the APIs which are supported from TI SDK to get this info from R5F0_0?

Yes, we have this support in QNX client running on A72 core but not on Linux client.
QNC client will register hwpush event to CPTS via server and get the CPTS timestamp from server via notify event. The frame work is already available in TI SDK.

Best Regards,
Sudheer

Also another Question, is gPTP stack ASILB? and also the drivers which is used for the TimeSync feature from TI side?

Hi,

mohamed elghoury said:

Also another Question, is gPTP stack ASILB? and also the drivers which is used for the TimeSync feature from TI side?

No, these are not ASIL qualified.

mohamed elghoury said:

Could you please share with me the used APIs from QNX side to register the notification callback and also for hwpush events of CPTS?

Please refer to below APIs in QNX.


EnetIf_calcSyncTimeParams() will calculate the adjustments required to match network synchronized time.

Also, refer to QNX SDK documentation.
https://software-dl.ti.com/jacinto7/esd/processor-sdk-qnx-j784s4/10_01_00_04/exports/docs/qnx_sdk_components_j784s4.html#cpsw9g-devnp-driver

Best Regards,
Sudheer

thanks for these inputs, maybe i have another question related to gPTP stack which shall be run over R5F0 core, Can the stack verify the ethernet frame that is used for the Time Sync feature using CRC as an integrity check on the frame?

also i need to know the asility level of the following module from this link: Ethernet Firmware: User Guide

IPC LLD, UDMA LL D and Enet LLD

Hi,

mohamed elghoury said:

Can the stack verify the ethernet frame that is used for the Time Sync feature using CRC as an integrity check on the frame?

Do you mean by gPTP frames? if so, the Ethernet packet it self has CRC.
If you mean by messages passed to client with CPTS timestamp info then No as it is IPC messages internally managed message between cores.

mohamed elghoury said:

also i need to know the asility level of the following module from this link: Ethernet Firmware: User Guide

IPC LLD, UDMA LL D and Enet LLD

These modules used together for supporting CPSW5G/CPSW9G ETHFW server and Client.

Best Regards,
Sudheer

Hi, 

are these modules "IPC LLD, UDMA LL D and Enet LLD" ASIL-B? and also for Remote Config Server/Client?

Hi,

mohamed elghoury said:

are these modules "IPC LLD, UDMA LL D and Enet LLD" ASIL-B? and also for Remote Config Server/Client?

In latest TI SDK UDAM LLD, IPC LLD are ASIL.
ENET LLD is QM not ASIL.
Remote Config server/client from ETHFW is also not ASIL.

Best Regard,
Sudheer

okay, and what about the CPSW LLD? is it ASIL-B ?

and also what is the difference between Enet and Remote Config? and where i can find the supported APIs for the remote config client/server?

Hi,

mohamed elghoury said:

okay, and what about the CPSW LLD? is it ASIL-B ?

CPSW using ENET LLD, which is not ASIL qualified.

mohamed elghoury said:

and also what is the difference between Enet and Remote Config? and where i can find the supported APIs for the remote config client/server?

ENET is LLD for CPSW configuration, where as Remote Config is frame work for ETHFW client and server communication.
Please refer to ETHFW User Guide points to components locations used in ETHFW server & clients.
https://software-dl.ti.com/jacinto7/esd/processor-sdk-rtos-j784s4/10_01_00_04/exports/docs/ethfw/docs/user_guide/ethfw_c_ug_top.html#ethfw_component_location

Best Regards,
Sudheer

but if there is a CRC error in the ethernet packet of the gptp frame it either be dropped or passed to gPTP stack without nay notification that it has a CRC error? as per TRM, so in this case we will not be sure if the content of the frame is corrupted or not

Hi,

mohamed elghoury said:

but if there is a CRC error in the ethernet packet of the gptp frame it either be dropped or passed to gPTP stack without nay notification that it has a CRC error? as per TRM, so in this case we will not be sure if the content of the frame is corrupted or not

As informed above, if any CRC errors found H/W will drop the packet and S/W will know anything about that error frame.

Best Regards,
Sudheer