2328137_en-US

[#1]

i.MX93 - 1PPS input and PTP

Goal: Validate synchronizing PTP time within ENET_QoS Ethernet controller using a Pulse-Per-Second (PPS) signal and GPRMC logs from GPS receiver

Hardware: FRMD i.MX 93

Buildroot: 2025.11.1

Linux: 6.12.16

Linuxptp: 4.4

Device Tree overlay modifications:

• Change eqos status from "disabled" to "okay"
• Remove pinctrl_usdhc2_gpio and pinctrl_usdhc2_gpio_sleep entries from usdhc2 pinctrl-* entries
• Add "MX93_PAD_SD2_CD_B__ENET_QOS_1588_EVENT0_IN      0x31E" entries to pinctrl_eqos and pinctrl_eqos_sleep
• Remove usdhc2 cd-gpios entry and replace it with broken-cd
• Delete pinctrl_usdhc2_gpio and pinctrl_usdhc2_gpio_sleep nodes

 Software location on target:

• Booting from eMMC
• Linux kernel and ptp apps ubooting and running from SD card

 Running linux ptp software:

• ptp4l -E4H -i eth1
• ts2phc -c /dev/ptp1 -s nmea --ts2phc.nmea_remote_host 10.128.240.54 --ts2phc.nmea_remote_port 3001 --ts2phc.pin_index 0  -l 7 -m

PPS Input:

I am currently just trying to verify timestamping of any event prior to having changes made to the FRDM i.MX 93 board to accept the PPS signal from the GPS receiver.  To generate these events, I am inserting an insulator between the legs of the mechanical switch of the SD card socket.  I have manually configured the IO pin connected to SD2_nCD as a GPIO input and verified that this action does change the pin input voltage.  I have assumed that the timestamping of any event by the hardware should not rely on any specific periodicity.

Results of testing:

• ts2phc is receiving the GPRMC logs but logging indicates that polling always returns zero events
• Examination of registers via a script using the devmem program shows the following:
  • SW_MUX_CTL_PAD_SD2_CD_B              0x00000001
  • SW_PAD_CTL_PAD_SD2_CD_B              0x0000031E
  • MAC_SYSTEM_TIME_SECONDS              0x69AB35B0
  • MAC_SYSTEM_TIME_NANOSECONDS          0x10642013
  • MAC_TIMESTAMP_STATUS                 0x00000000
  • MAC_AUXILIARY_CONTROL                0x00000010
  • MAC_AUXILIARY_TIMESTAMP_NANOSECONDS  0x00000000
  • MAC_AUXILIARY_TIMESTAMP_SECONDS      0x00000000
• I can see that the system time registers are appropriately counting time
• I never see anything other than zeros in the aux timestamp registers.  The reference manual is not clear on whether zeros would be expected to be read whenever the FIFO is empty or if they would return the most recent timestamp.
• I have tried this with the SION bit of the SW_MUX_CTL_PAD_SD2_CD_B register set to both 0 and 1 with no difference in outcome.
• I have tried setting all 4 of the ATSEN bits of the MAC_AUXILIARY_CONTROL register just in case the pin_index mapping was not as I expected, with no difference in outcome.

Further questions arising from reading i.MX 93 Applications Processor Reference Manual, Rev. 6, 2025-07-01:

• Chapter 43 Ethernet Controller with TSN (ENET_QoS), Section 43.5, Table 417 lists two different event inputs: 1588_EVENT_AUX_IN and 1588_EVENT_IN.  What external pins or internal device ports do these two signals connect to?  What does the 1588_EVENT_IN port connect to within ENET_QoS?  I presume that 1588_EVENT_AUX_IN connects to ptp_aux_trig_i[0] and is controlled by the ATSEN0 bit.  (That also appears to be what the kernel and ts2phc expect.) Is that correct?
• Chapter 43, Section 43.5, Table 417 lists one event output: 1588_EVENT_OUT.  What external pins or internal device ports does this signal connect to?  What does the 1588_EVENT_OUT port connect to within ENET_QoS?  Is it associated with one of the PPS outputs?
• Chapter 43 does not seem to specify which edge (rising/falling/both) of the ptp_aux_trig_i inputs are used to trigger the timestamping.

Re: i.MX93 - 1PPS input and PTP

Hi,

Thank you for your interest in NXP Semiconductor products,

The AUX_IN signal is used to trigger the latching of the current time (this time will be used as a timestamp value in whatever application you may have) into the timestamp FIFO (you may have multiple timestamp values from previous trigger event).

The EVENT_IN is input  to the media clock generation and recovery block and it’s used to trigger:

• The capture of Target Presentation Time read from the application and yield the result in MAC_PPSn_Target_Time_Seconds if recovery mode is enabled
• The capture of Current Presentation Time  at sampled trigger if generation mode is enabled

1588_EVENT_OUT is used by the processor for driving a PPS output.

Regards

Re: i.MX93 - 1PPS input and PTPWhen you use the term AUX_IN, is that that same as the term 1588_EVENT_AUX_IN in Table 417?
If so, which specific ATSEN* bit does it map to?

Does AUX_IN (1588_EVENT_AUX_IN) connect to the ENET_QOS_1588_EVENT0_IN mode of SW_MUX_CTL_PAD_SD2_CD_B?Re: i.MX93 - 1PPS input and PTP

Hi @Kevin_M 

Yes, it's the 1588_EVENTx_AUX_IN, please review the following fields, this is the AUX usage.

PTGE

Presentation Time Generation Enable When this bit is set the Presentation Time generation will be enabled.

0 - Presentation Time Generation is disabled
1 - Presentation Time Generation is enabled

...

MAC_PPS0_TARGET_TIME_SECONDS

PPS Target Time Seconds Register This field stores the time in seconds.

PPS Target Time Seconds Register

This field stores the time in seconds. When the timestamp value matches or exceeds both Target Timestamp registers, the MAC starts or stops the PPS signal output and generates an interrupt (if enabled) based on Target Time mode selected for the corresponding PPS output in the MAC_PPS_CONTROL register.

...

43.7.9.1 Programming Guidelines for Media Clock Generation

1. To set the PPS instance in Media Clock generation mode, program the appropriate Presentation Time Control (supported generation modes "1001-1011") to PPSCTRL_PPSCMD (for 0th instance)/PPSCMD#i (for 1,2,3 instances) of MAC_PPS_CONTROL register.

2. Based on the selected PPS instance, application must drive the appropriate trigger signal to the corresponding mcg_pst_trig_i[#i].

...

43.7.9.2 Programming Guidelines for Media Clock Recovery

1. Enable the Current Presentation Time (CPT) Counter by setting the PTGE field of MAC_TIMESTAMP_CONTROL register. In addition to programming the initialization values for the System Time, update the MAC_PRESN_TIME_UPDT register with the equivalent Presentation Time init value. Only then the TSINIT field of MAC_TIMESTAMP_CONTROL register is set.

2. The Increment values used for the System time is also used for the Current Presentation time. This is because, the increment value is in Sub-seconds and Sub-nanoseconds.

1. Each ATSEN is mapped to the respective EVENT

2. Correct, you can confirm the AUX_IN here. https://github.com/nxp-imx/linux-imx/blob/lf-6.12.y/arch/arm64/boot/dts/freescale/imx8mp-pinfunc.h#L...

Best regards,

Re: i.MX93 - 1PPS input and PTP

@JosephAtNXP I am not trying to set up a PPS output or anything to do with IEEE 1722.  I am trying to timestamp the moment at which the state of ENET_QOS_1588_EVENT0_IN changes.

Re: i.MX93 - 1PPS input and PTP@JosephAtNXP, are you still looking into the issue of why I cannot seem to get the 1588 PPS input to work with ENET_QoS?Re: i.MX93 - 1PPS input and PTP

@Kevin_M any luck getting this solved? I've hit the same roadblock, where on the ENET instance I can get PTP to sync with a PPS input, but I cannot find a way in the reference manual or the drivers to use the EVENT0_IN pin with the ENET_QOS.

Re: i.MX93 - 1PPS input and PTPNXP has confirmed that the AUX TIMESTAMP feature of the ENET_QoS is not connected to anything inside or outside of the i.MX93 chip.

I have had some success routing PPS via SD2_CMD in 1588_EVENT0_IN mode and reading the time captured in MAC_PPS0_TARGET_TIME_SECONDS with MAC_PPS_CONTROL set to use Presentation Time Control option 0001 to capture presentation time on the rising edge of the PPS signal. Still have lots of details to work out, but this seems to be a possible solution.Re: i.MX93 - 1PPS input and PTPThanks Kevin, that also seems to be the only way to do this, but I see it is not as yet covered by the stmmac driver, so will need to be added in.