AM62A3: Failed to write hardware timestamp parameters through ioctl.

? ?

Part Number: AM62A3

Tool/software:

During the initialization of the hardware timestamp, the ioctl fails to write the hardware timestamp parameters. tx_type is HWTSTAMP_TX_ON, rx_filters is HWTSTAMP_FILTER_PTP_V2_EVENT. The following error occurs when the linuxPTP open source protocol stack v4.2 release is used, the following error occurs:

ptp4l[6.307]: selected /dev/ptp0 as PTP clock
ptp4l[6.364]: Setting HWTSTAMP: tx_type = 1, rx_filter = 12
ptp4l[6.364]: driver rejected most general HWTSTAMP filter
ptp4l[6.364]: Failed to set HWTSTAMP with rx_filter = 12: Invalid argument
ptp4l[6.364]: Retrying with alternative rx_filter = 9
ptp4l[6.364]: ioctl SIOCSHWTSTAMP failed: Invalid argument
ptp4l[6.416]: port 1 (eth0): INITIALIZING to FAULTY on FAULT_DETECTED (FT_UNSPECIFIED)
ptp4l[6.416]: port 0 (/var/run/ptp4l): INITIALIZING to LISTENING on INIT_COMPLETE
ptp4l[6.417]: port 0 (/var/run/ptp4lro): INITIALIZING to LISTENING on INIT_COMPLETE

The relevant code is as follows, sk.c/hwts_init

case HWTS_FILTER_NORMAL:

cfg.tx_type = tx_type;

cfg.rx_filter = orig_rx_filter = rx_filter;

pr_info("Setting HWTSTAMP: tx_type = %d, rx_filter = %d", cfg.tx_type, cfg.rx_filter);

err = ioctl(fd, SIOCSHWTSTAMP, &ifreq);

if (err < 0) {

pr_info("driver rejected most general HWTSTAMP filter");

pr_err("Failed to set HWTSTAMP with rx_filter = %d: %m", orig_rx_filter);

init_ifreq(&ifreq, &cfg, device);

cfg.tx_type = tx_type;

cfg.rx_filter = orig_rx_filter = rx_filter2;

pr_info("Retrying with alternative rx_filter = %d", orig_rx_filter);

err = ioctl(fd, SIOCSHWTSTAMP, &ifreq);

if (err < 0) {

pr_err("ioctl SIOCSHWTSTAMP failed: %m");

return err;

}

if (cfg.rx_filter == HWTSTAMP_FILTER_SOME)

cfg.rx_filter = orig_rx_filter;

break;

}

The following parameters are obtained using ethtool

root@am62axx-evm:~# ethtool -T eth0
Time stamping parameters for eth0:
Capabilities:
hardware-transmit
software-transmit
hardware-receive
software-receive
software-system-clock
hardware-raw-clock
PTP Hardware Clock: 0
Hardware Transmit Timestamp Modes:
off
on
Hardware Receive Filter Modes:
none
ptpv2-l4-event
ptpv2-l4-sync
ptpv2-l4-delay-req
ptpv2-l2-event
ptpv2-l2-sync
ptpv2-l2-delay-req
ptpv2-event
ptpv2-sync
ptpv2-delay-req

root@am62axx-evm:/tmp# ethtool -i eth0
driver: am65-cpsw-nuss
version: 6.6.32-ti-ge204a3987642
firmware-version:
expansion-rom-version:
bus-info: 8000000.ethernet
supports-statistics: yes
supports-test: no
supports-eeprom-access: no
supports-register-dump: yes
supports-priv-flags: yes

Based on the above information, can you tell me the failure information? I think the parameters set are within the support range

7 months ago

0 Daolin Qiu 7 months ago

TI__Genius 15655 points

Hello,

First can you answer the following questions

1. What Linux SDK version are you using?

2. Is the test being run on a custom board or a TI AM62Ax EVM?

3. What is your test setup? How many devices are connected via Ethernet and how are they being connected?

4. What is the specific step-by-step procedure you used to run your test? (including any changes to the code you made)

5. What command are you using to run linuxptp (what are the ptp4l options you're using)?

-Daolin

0 ? ? 7 months ago in reply to Daolin Qiu

Prodigy 70 points

1. What Linux SDK version are you using?

-->root@am62axx-evm:~# cat /etc/os-release
ID=arago
NAME="Arago"
VERSION="2023.10"
VERSION_ID=2023.10
VERSION_CODENAME="${DISTRO_CODENAME}"
PRETTY_NAME="Arago 2023.10"
CPE_NAME="cpe:/o:openembedded:arago:2023.10"

root@am62axx-evm:~# uname -r
6.6.32-ti-ge204a3987642

root@am62axx-evm:~# cat /proc/version
Linux version 6.6.32-ti-ge204a3987642 (oe-user@oe-host) (aarch64-oe-linux-gcc (GCC) 13.3.0, GNU ld (GNU Binutils) 2.42.0.20240620) #1 SMP PREEMPT Thu Jan 2 21:15:22 UTC 2025

2. Is the test being run on a custom board or a TI AM62Ax EVM?

--> a custom board

3. What is your test setup? How many devices are connected via Ethernet and how are they being connected?

--> At present, one device is used as gPTP slave device node, according to linuxptp release 4.2 version, the configuration file is automotive-slave.cfg, the configuration is as follows:

# Automotive Profile example configuration for clients containing those

# attributes which differ from the defaults. See the file, default.cfg, for

# the complete list of available options.

[global]

# Options carried over from gPTP.

gmCapable 1

priority1 248

priority2 248

logSyncInterval -3

syncReceiptTimeout 3

neighborPropDelayThresh 800

min_neighbor_prop_delay -20000000

assume_two_step 1

path_trace_enabled 1

follow_up_info 1

transportSpecific 0x1

ptp_dst_mac 01:80:C2:00:00:0E

network_transport L2

delay_mechanism E2E

# Automotive Profile specific options

BMCA noop

clientOnly 1

inhibit_announce 1

asCapable true

ignore_source_id 1

# Required to quickly correct Time Jumps in master

step_threshold 1

operLogSyncInterval -3

logMinPdelayReqInterval 0

operLogPdelayReqInterval 0

msg_interval_request 1

servo_offset_threshold 30

servo_num_offset_values 10

Two devices are connected to each other over Ethernet. One serves as the primary gPTP device and the other serves as the secondary gPTP device

4. What is the specific step-by-step procedure you used to run your test? (including any changes to the code you made)?

--> The linuxptp stack code, other than the configuration file shown above, has not changed much, and there is no special testing procedure, that is, the ioctl fails to write hardware timestamp parameters

5. What command are you using to run linuxptp (what are the ptp4l options you're using)?

--> usr/sbin/ptp4l -f etc/linuxptp/ptp4l.conf -i eth0 -m -H

0 Daolin Qiu 7 months ago in reply to ? ?

TI__Genius 15655 points

Hello,

Thank you for answering those questions. If I'm understanding correctly, you are using Linux Kernel 6.6 (not necessarily from the TI Linux SDK 10.1), and are using the ptp4l stack that you built separately?

Can you try verifying the following linuxptp setup works on your system?

Run "ptp4l -P -2 -H -i eth0 -f gPTP.cfg --step_threshold=1 -m -q -p /dev/ptp0" where gPTP.cfg contains the following on the device serving as the grandmaster clock? For the device following the grandmaster clock, change "priority1" in the gPTP.cfg to 240.

# 802.1AS example configuration containing those attributes which
# differ from the defaults. See the file, default.cfg, for the
# complete list of available options.
#
[global]
gmCapable 1
priority1 100
priority2 248
logAnnounceInterval 0
logSyncInterval -3
syncReceiptTimeout 3
neighborPropDelayThresh 800
min_neighbor_prop_delay -20000000
assume_two_step 1
path_trace_enabled 1
follow_up_info 1
transportSpecific 0x1
ptp_dst_mac 01:80:C2:00:00:0E
network_transport L2
delay_mechanism P2P
ingressLatency 88
egressLatency 288

? ? said:
Two devices are connected to each other over Ethernet. One serves as the primary gPTP device and the other serves as the secondary gPTP device

I'm assuming both devices that are connected via Ethernet are custom boards?

-Daolin

0 ? ? 7 months ago in reply to Daolin Qiu

Prodigy 70 points

Although there is no failure to write the hardware timestamp through the ioctl, the time synchronization does not succeed either

service:

service

client:
client

I'm assuming both devices that are connected via Ethernet are custom boards?

--> yes, you are using Linux Kernel 6.6, and from the TI Linux SDK 10.1, basically no changes, and the linuxPTP protocol stack is also directly using the release version, did not do any additional code changes

0 Daolin Qiu 7 months ago in reply to ? ?

TI__Genius 15655 points

Hello,

Daolin Qiu said:
Run "ptp4l -P -2 -H -i eth0 -f gPTP.cfg --step_threshold=1 -m -q -p /dev/ptp0" where gPTP.cfg contains the following on the device serving as the grandmaster clock? For the device following the grandmaster clock, change "priority1" in the gPTP.cfg to 240.

I assume the "service" output is from the PTP grandmaster device? If so, you should make sure the "priority1" is configured to 100. The follower device should be 240.

Just to clarify, both connected devices are connected via their respective "eth0" ports?

Can you do a tcpdump on the eth0 interfaces of both devices and see if you see the expected PTP messages (e.g. Peer_Delay_Req)?

-Daolin

0 ? ? 7 months ago in reply to Daolin Qiu

Prodigy 70 points

Thanks for your support, I understand. The current problem has been solved

0 Daolin Qiu 7 months ago in reply to ? ?

TI__Genius 15655 points

Hello,

Glad to hear it was solved. As a reference for future readers of this thread, can you share some information about how the problem was solved?

-Daolin

0 ? ? 7 months ago in reply to Daolin Qiu

Prodigy 70 points

When defined in the service file, you need to set the user and Group permissions to root, otherwise there may be problems when loading the configuration file, such as the ioctl write hardware timestamp error

Processors

Processors forum

AM62A3: Failed to write hardware timestamp parameters through ioctl.