• State
  • Replies 4 replies
  • Subscribers 101 subscribers
  • Views 88 views
  • Users 0 members are here
Support feedback
Options
Options
Related

AM6442: eth 1588 time stamp in send side

Biao Li
Expert 6440 points
Part Number: AM6442

Tool/software:

Hi Expert,

customer have below question, pls help check:

 We are currently using the 1588 timestamp function of am6442's cssg1 network port. The related drivers of Icssg are ported from uboot in Linux SDK 9.0, and the IEP driver is ported from Linux code.

Our current operating system refers to the above code in the Linux driver, and normal timestamps can be obtained from network received messages.

The current network data transmission process of our operating system is : send data ->DMA transmission completion interrupt ->return the transmission completion timestamp. Therefore, it is required that the message sent can obtain the timestamp by reading the DMA descriptor or other external modules during the transmission completion interrupt. We have learned that cadence GMAC IP cores can read timestamps from dam descriptors.

We found that the current Linux driver uses tx_ts0 interrupt to trigger tx_ts_work to read the sending timestamp, which is incompatible with our current mechanism

Can you provide a modification method or example code similar to Cadence's GMAC that obtains the sending timestamp by sending DMA descriptors. The accuracy can be appropriately relaxed.

BR,

Biao 

  • 0
    TI__Genius 16195 points

    Hello Biao, 

    I will need some time to check with our ICSSG Linux driver developer. The fact that ICSSG is used makes things a bit more complicated because there is the PRU_ICSSG firmware involved. It may be the case that the timestamps need to be retrieved from the firmware. 

    Please kindly ping this thread Thursday if you did not hear a response back.

    Is there a particular reason why ICSSG Ethernet is used as opposed to CPSW Ethernet?

    -Daolin

  • 0 in reply to Daolin Qiu
    TI__Expert 5834 points

    Hi Biao,

    Biao Li said:
    We found that the current Linux driver uses tx_ts0 interrupt to trigger tx_ts_work to read the sending timestamp, which is incompatible with our current mechanism

    Getting timestamps through DMA descriptors like Cadence's GMAC isn't possible with ICSS due to fundamental architectural differences.
    Here's how timestamping works: When a host submits a timestamping request packe via PKTDMA descriptort, it includes a cookie for identification later.
    PKTDMA pushes packets to ICSS via PSIL interface, the PKTDMA descriptor is freed, now ICSS uses it's own packet descriptors (not DMA descriptors).
    The TX timestamp (TX_SOF) is only captured when ICSS actually transmits the packet from its port queue to the MII interface.
    At this point, the timestamp is associated with the original cookie (ICSS descriptors contain the cookie copied from PKTDMA descriptor) and now ICSS descriptor returned to the host via the ICSS hardware queue manager. Once this ICSS descriptors is used by the host to read the timestamp host frees it back. This design exists because packets might wait in transmit queues (for example, when Express packets take priority), and TX_SOF timestamping must align with actual MII transmission. This is why DMA descriptors independent of ICSS descriptors.
    Recommended approach: to poll the Hardware queue after submitting packets, rather than using interrupts (if your concern is using interrupt).

    BR
    JC

  • 0 in reply to Jayachandran Rameshbabu
    Prodigy 40 points

    Hi Expert,

    Is there a reference code example for “to poll the Hardware queue after submitting packets”

  • 0 in reply to yuchuan xing
    TI__Expert 5834 points

    Hi Yuchuan,

    Refer AM64x RTOS SDK Icssg_pollTxTs() API in source\networking\enet\core\src\per\icssg.c file

    BR
    JC