Dear TI support team,
Our goal is to get a PPS signal and two other, custom frequency periodic signals (let's say 2kHz and 2.4kHz) synchronized with PTP from the AM64x SoC physical pins. At the end, we hope to achieve this over redundant ethernet networks (i.e. PRP and HSR), and using as much PRU-ICSSG offload as possible.
I've been testing PTP and PPS features on TMDS64EVM using the latest Processor SDK (08_06_00_42 at the moment) with both tisdk-base-image and tisdk-default-image builds based on 1.2. Building the SDK.
So far, I've had quite a few issues with certain functions that the SoC is said to be capable of. Here are my findings on which some clarification would be highly appreciated:
1.) CPSW ethernet port (eth0) works with PTP and PPS as expected. Although I had to do some digging around to find that the following modifications are required to be able to see the PPS signal on a physical pin:
/* Example of the timesync routing */
mcu_cpts_pps: mcu-cpts-pps {
pinctrl-single,pins = <
/* pps [cpts genf1] in22 -> out37 [cpts hw8_push] */
TS_OFFSET(37, 22)
/* pps [cpts genf1] in22 -> out24 [SYNC0_OUT pin] */
TS_OFFSET(24, 22)
>;
};Not sure though, if I want it to be routed to another external pin, or use a different genf output of the module (e.g for a different frequency) where do I find the numbers to refer to those signals (like 22 and 24 here).
2.) testptp -d /dev/ptp0 -P 1
enables the PPS from the CPTS. OK, I can see it now on the scope. My understanding is (looking at the testptp help menu, because it doesn't seem to be documented in any TI resource) that e.g
testptp -d /dev/ptp0 -p 1000000 -w 500000 -H 0
command should produce from that same clock a 1kHz frequency, 50% duty cycle and 0ns offset periodic signal. Is that correct? Because nothing happens when issuing the command. I also tried manually writing the registers from user-space that are claimed to control the genf_n signal generators (following the TRM), but writing any value to them is also ineffective. How is it possible to generate a custom frequency sync signal from CPTS?
3.) Using an ethernet port driven by PRU-ICSSG (either one of eth1 or eth2 if ...icssg-dualemac... .dtbo is applied) and hw clock attached to it, PTP works as expected. After finding the following section in DTS:
icssg1_iep0_pins_default: icssg1-iep0-pins-default {
pinctrl-single,pins = <
AM64X_IOPAD(0x0104, PIN_OUTPUT, 2) /* (W7) PRG1_PRU0_GPO19.PRG1_IEP0_EDC_SYNC_OUT0 */
>;
};and after enabling PPS with testptp, I can again see the PPS signal on the corresponding header of the am64xxevm. Although after adding
AM64X_IOPAD(0x00FC, PIN_OUTPUT, 2) /* (U7) PRG1_PRU0_GPO17.PRG1_IEP0_EDC_SYNC_OUT1 */
I don't know how to route a PPS signal to SYNC_OUT1 as well.
Also, PPS is not in phase with the master's PPS and always has a random offset between 0-1 sec. How can this be solved? (Just to clarify, when running ptp4l there is no drift, but when disabling and reenabling the PPS, the offset changes)
4.) testptp -d /dev/ptp0 -p 1000000 -w 500000 -H 0
This command does have an effect here, but not what I tell it to do. -w and -H options change nothing, and -p period length can be changed to a maximum frequency of 200Hz too. For -p smaller than 5000000ns the period is always 5ms no matter what. Is this tool supposed to work properly? I also looked at the registers here that are supposed to control the period, on time and phase of the periodic signal, found all of them to contain 0x00000000 (IEP_SYNC_START_REG, IEP_SYNC0_PERIOD_REG, IEP_SYNC_PWIDTH_REG). Writing to them has no effect. Can these parameters be set from user-space?
5.) Finally, PRP/HSR. There is no mention of PRP/HSR using the PRU subsystem in the AM64x PSDK so I followed the one for AM65x. They contain the same PRU-ICSSG and some of the firmware files in /lib/firmware in Am64x rootfs have *am65* in their name anyways...
ip link add name hsr0 type hsr slave1 eth1 slave2 eth2 supervision 45 version 1
command does not work in tisdk-base-image but does in tisdk-default-image. I read somewhere that you are aware of the issue and working on fixing it. Okay. So using tisdk-default-image, the prp0 or hsr0 interface can be succesfully brought up, but the
ethtool -K eth1 prp-rx-offload on
command still doesn't work, which I suppose should load the prp firmware into the PRU? Does this mean that in the prp0 interface the PRU-ICSSG only passes the packets through without processing and the handling of the protocol still happens in Linux? Either way, ptp4l works properly with a link in either eth1 or eth2 ports, and using /dev/ptp2 which should point to a hw clock implemented in IEP inside PRUSS.
PPS and custom frequency periodic signal don't work with /dev/ptp2 though when prp0 interface is brought up. Should they in redundant modes?
Thank you for your assistance in advance,
Gábor
