AM6442: Connecting DP83869HM SFD (TX/RX) Signals to AM6442 ICSSG for PTP (IEEE 1588) Hardware Timestamping

nadhem zarai said:

What is the recommended way to connect the TX_SFD and RX_SFD outputs from DP83869HM to the AM6442’s ICSSG PRU GPI pins?

You can connect them to PRU_ICSSG0/1_PR1_EDC0/1_LATCH0/1_IN pins

nadhem zarai said:

Our end goal is to perform accurate hardware timestamping using the SFD pulses routed to PRU GPI pins.

ICSSG PRUETH supports 802.1AS, via MAC side time stamping. AM243x MCU+ SDK: Ethernet TSN ICSSG gPTP TimeReceiver (gPTP Slave) Example which can achieve < 100ns level synchronization jitter performance

I will let other colleagues comment on Linux support

Hello Pratheesh,

Thank you for your response and clarification.

To confirm, we are planning to use the TX_SFD and RX_SFD outputs from the DP83869HM PHY and connect them respectively to:

• TX_SFD → PRG0_IEP0_EDC_LATCH_IN0 (ball V1)

• RX_SFD → PRG0_IEP0_EDC_LATCH_IN1 (ball T1)

Our goal is to perform hardware timestamping of Ethernet frames using the SFD pulses captured via PRU GPI pins. We're targeting a Linux-based system, not MCU+ SDK.

I understand from your message that ICSSG PRUETH supports MAC-side timestamping for 802.1AS, but we would like to achieve finer precision via external timestamp capture using these latch inputs.

Could you please help us clarify the following:

1. How do we configure the PRG0_IEP0_EDC_LATCH_IN0/1 pins in the Linux device tree?
   Are there any pinctrl examples or IEP bindings to enable these as timestamp capture inputs?

mypruicssg0iep1_pins_default: mypruicssg0iep1-default-pins {
pinctrl-single,pins = <
AM64X_IOPAD(0x01a8, PIN_INPUT, 2) /* (V1) PRG0_PRU0_GPO18.PRG0_IEP0_EDC_LATCH_IN0 */
AM64X_IOPAD(0x017c, PIN_INPUT, 2) /* (T1) PRG0_PRU0_GPO7.PRG0_IEP0_EDC_LATCH_IN1 */
>;
};

1. Once connected, how can we test that the SFD pulses are being captured by the IEP timer?
   Is there a way to access these timestamps from Linux userspace ? 

2. Can the IEP latch mechanism be integrated or bridged into the Linux PTP stack ?

Any example or further pointers (particularly for Linux use) would be extremely helpful.

Thanks again for your support!

Best regards,

My recommendation will be to use  PRG0/1_IEP1_EDC_LATCH_IN0/. I will need to defer to Linux experts to answer remaining queries.

nadhem zarai said:

Once connected, how can we test that the SFD pulses are being captured by the IEP timer?
Is there a way to access these timestamps from Linux userspace ? 

Continuous capture mode is enabled by default in IEP. So, if pinmux configured right together with Time sync router etc, you shall see IEP_CAP_STATUS_REG updated with Hit status.

You can read the timestamps from IEP_CAPR/F6/7_REG0/1 for CAP6 (Latch0), CAP7 (Latch1) Rising/Falling edges.

IEP_CAP_CFG_REG.CAP_EN description in TRM is vague, this is not required for continuous latch mode but there is a possibility to latch the next timestamp only post CPU/PRU acknowledge by reading IEP_CAPR/F6/7_REG0/1 (then HIT status will be cleared in IEP_CAP_STATUS_REG)

Following threads may be useful

(+) [FAQ] How to synchronize the PRU IEP timer with Linux system time? - Processors forum - Processors - TI E2E support forums

(+) AM6442: Inter-Core Time Sync Routing (between A53 and R5) - Processors forum - Processors - TI E2E support forums

Hello Pratheesh,

Thank you for your valuable input. I have a few follow-up questions and clarifications, mainly to better understand the reasoning behind your recommendations and how to proceed under Linux.

1. Why use IEP1 specifically?

You recommended using PRG0/1_IEP1_EDC_LATCH_IN0/1 is there a technical reason for preferring IEP1 over IEP0?
From what I understand, both IEP0 and IEP1 are functionally similar on ICSSG, and I’m curious to know if there are hardware routing or driver limitations that make IEP1 preferable for capturing SFD pulses.

2. Device Tree and Pinmux

Based on the pinmux you've described, I’ve added the following lines in the device tree to route the SFD signals:

Are these sufficient for enabling timestamp capture via IEP1? Or is additional configuration required beyond pinctrl?

3. Clarification on Time Sync Router

You mentioned:

“If pinmux is configured right together with Time Sync Router etc…”

I'm not familiar yet with the Time Sync Router, especially in the context of external signals like SFD that are physically connected to SoC balls (e.g., W5 and P5).
Could you please clarify:

• What is the role of the Time Sync Router when using latch input pins directly?

• Is Time Sync Router configuration necessary when the SFD signals are connected physically to latch input balls?

If possible, could you provide an example or reference based on my pinmux configuration?

4. Verifying SFD timestamps in Linux

You mentioned that the IEP_CAP_STATUS_REG is updated with hit status when a signal is latched, and the captured values are stored in IEP_CAPR_F6/F7_REGx.

Is there any utility or debugfs/sysfs interface in the Linux SDK to read these values from user space?
Or do I need to:

• Write a kernel module to map the IEP registers.

Best regards,

Hello,

IEP0 / IEP1

I'll leave Pratheesh to comment on the IEP0 / IEP1 question.

Time Sync Router: needed?

You have lots of questions. I'll start with just discussing time sync router and we can talk about other questions later.

We care about the signal getting from the pin to the IEP timer. If a direct connection exists between the pin and the IEP timer, and you do not have any pinmux conflicts, then there is no need to use the time sync router. However, if a direct signal connection does not exist, then you could pinmux a signal that comes into the time sync router, and then configure the time sync router to send the signal to the IEP timer.

More information at https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1061474/faq-am64x-what-is-the-time-sync-router-for-how-do-i-use-it

I am running out of time tonight, so I will not be able to verify whether that pin signal has a direct connection to the IEP peripheral.

Regards,

Nick

Nick Saulnier said:

I'll leave Pratheesh to comment on the IEP0 / IEP1 question.

In the context of PRUETH firmware - IEP0 is wrapping around counter (every 1 ms), IEP1 is a free running 64-bit counter and preferred option for timestamping and conversions

Hello Nick,

Thank you very much for your explanation about the Time Sync Router, that helps clarify when it's required.
From your explanation, and unless I’m missing something, I understand that in my case, it's not needed since I am connecting external signals (SFD from DP83869HM) directly to SoC pins that map to PRG0_IEP1_EDC_LATCH_IN0 and LATCH_IN1, with no mux conflicts.

Just to make things clear:

I want to use DP83869HM’s TX_SFD and RX_SFD outputs for hardware timestamping, to compensate latency introduced by the PHY or MAC.
I plan to connect them to the following SoC pins:

• TX_SFD → PRG0_PRU1_GPO18.PRG0_IEP1_EDC_LATCH_IN0 (ball P5)

• RX_SFD → PRG0_PRU1_GPO7.PRG0_IEP1_EDC_LATCH_IN1 (ball W5)

My goal is to use these pulses to latch timestamps into the ICSSG IEP1 registers.

Now, my questions are:

1. Is any further configuration needed in the device tree, beyond enabling the correct pinctrl-single,pins for these two balls? For example:

2. Once the signals are physically connected and the pinmux is applied, what should I do next in Linux to ensure the latched timestamps are processed?

3. Is there any way to test or read the contents of the IEP latch registers (e.g., IEP_CAPR_F6/F7_REGx, IEP_CAP_STATUS_REG) from Linux userspace?

4. I’d like to proceed step by step to validate this external timestamping path, so any recommendation on the correct next step to test the timestamp capture would be really appreciated.

Thanks again for your support.
Best regards,

Hello Nadhem,

I am not very clear on exactly what you are trying to do - can you provide a bit more information?

Are you taking TI's prebuilt PRU Ethernet firmware and trying to give it input signals?

Are you writing your own custom Ethernet protocol with custom PRU firmware?

Are you doing something else?

Regards,

Nick

Hello Nick,

I'am using TI's prebuilt PRU Ethernet firmware, to give it SFD Tx and Rx as input signals.

Regards,

Hello Nadhem,

Let me check with the developers to see if what you are trying to do is supported by the current software. Feel free to ping the thread if I have not replied within a few business days.

Regards,

Nick

Hello Nick,

Thank you, I am looking forward to receiving your answer.

Regards,

Hi Nick,

I wanted to check if TI’s prebuilt PRU Ethernet firmware currently supports using the SFD signals for PTP timestamping. This is important for the hardware timestamping setup I’m working on.

Do you happen to know if this is supported, or if there are any plans for it?

Thanks in advance, and looking forward to your update.

Best regards,

Hello Nadhem,

I am still in conversation with the developers. Please ping the thread if I have not replied again by Wednesday.

Regards,

Nick

Hello Nick,

Any update?

Regards,

Hello Nick,

Hope you're doing well. Just following up as it's been a little while since your last message. Let me know if there's any update from the developers.

Regards,

Hello Nick,

Thank you for the clarification. To be clear, we are not looking to implement any custom code. We are using TI’s prebuilt PRU Ethernet firmware, and we were hoping to use the DP83869HM’s SFD outputs for hardware timestamping. If this is not supported, we would like to know if TI offers any Ethernet PHY that supports internal hardware timestamping (IEEE 1588), is compatible with RGMII, and supports 1G fiber. I found the DP83TG721x-Q1, but it doesn’t seem to support fiber. Do you have any recommendations?

Best regards,

Hello Nadhem,

Is there a specific reason you are evaluating PRU Ethernet for this usecase? Or is CPSW Ethernet also an option for you?

You can find the Linux CPSW documentation here:
https://software-dl.ti.com/processor-sdk-linux/esd/AM64X/11_01_05_03/exports/docs/linux/Foundational_Components/Kernel/Kernel_Drivers/Network/CPSW-Ethernet.html

where the PTP information is under TSN with CPSW > PTP.

Regards,

Nick

Hello Nick,

Thank you for the information and the CPSW documentation link.

We are using PRU Ethernet mainly due to its real-time behavior. I performed some stress tests and observed that latency with CPSW Ethernet was generally higher compared to PRU Ethernet. Additionally, we plan to use four Ethernet ports across the two ICSSG instances, which PRU Ethernet supports more conveniently.

Out of curiosity, has TI done any latency comparisons between CPSW and PRU Ethernet firmware under load or real-time conditions?

Best regards