2410971_en-US

[#1]

LS1028A Felix (swp0): Hardware TX Timestamp Not Produced for Custom-EtherType Frames on the CPU-Inje

1. Environment

• Platform: NXP LS1028ARDB (VSC9959 / Felix switch)

• Kernel: Linux 6.18.2-rt3 (NXP Yocto real-time-edge, PREEMPT_RT)

• Topology (DSA):

  • eno2 (ENETC) = DSA conduit / NPI port

  • swp0 = Felix user port (CPU-injection path: CPU → eno2 → NPI → egress swp0 physical port)

  • eno0 (ENETC) = separate test port (now directly cabled to swp0, used to verify the actual egress frame content)

• Application: AF_PACKET SOCK_RAW socket bound to swp0, SO_TIMESTAMPING(TX_HARDWARE|RAW_HARDWARE), transmitting frames with custom EtherType 0x88B5, expecting the hardware TX timestamp from the socket error queue (SCM_TIMESTAMPING).

• ptp4l is running on swp0 (HWTSTAMP_TX_ON, syncing normally, unaffected).

2. Goal

Obtain a hardware TX timestamp for custom 0x88B5 (non-PTP) frames transmitted on swp0, without breaking PTP synchronization on swp0.

3. Confirmed working

• PTP frames DO get timestamps: using the same AF_PACKET raw socket on swp0, transmitting 0x88F7 + a valid PTP header, 30/30 frames returned a hardware TX timestamp via the error queue (ocelot_get_txtstamp matched, timestamp delivered to the socket error queue).

• The driver timestamp-request path works for the custom frames: 0x88B5 frames reach ocelot_port_txtstamp_request (dmesg shows felix-tx-ts: port 0 non-PTP=1 ts_id=0..3), i.e. ocelot_port->ptp_cmd is non-zero (set by ptp4l) and a timestamp ID is allocated.

4. Problem

For 0x88B5 frames, a timestamp ID is allocated, but the hardware produces no timestamp:

• SYS_PTP_STATUS PTP_MESS_VLD = 0 immediately after sending a burst of 0x88B5 frames (no FIFO entries, no overflow).

• The socket error queue stays empty.

5. What we checked and ruled out (evidence)

Check Result

ocelot_port->ptp_cmd (two-step enable)	non-zero (set by ptp4l)
IFH BYPASS (bit 127)	=1 (driver ocelot_ifh_set_bypass)
IFH REW_OP1 (bits 125–117)	confirmed by code: two-step(3) + ts_id written for 0x88B5 frames
REW_PTP_CFG.PTP_2STEP_DIS	=0 (two-step not disabled)
PTP_CFG_MISC.PTP_ENA	=1
SYS_PORT_MODE.DATA_WO_TS (ports 0/4/6)	=0 (inline timestamp write not disabled)
REW_PORT_CFG.FCS_UPDATE_CPU_ENA	=1 (CPU frames always get FCS recomputed, no bad-CRC drops)
IS2 rules adding two-step authorization for 0x88B5 (ingress swp0, then swp0|NPI)	no effect (CPU-injected frames have BYPASS=1, analyzer/IS2 is skipped)
Inline timestamp insertion SYS_TIMESTAMP_OFFSET (ETH_TYPE_CFG=0x88B5, TIMESTAMP_OFFSET=14; register write/readback verified)	no effect (with swp0↔eno0 direct cable, no timestamp at absolute byte 28 of the egress frame)

6. Questions for Official Confirmation

1. Does the VSC9959/Felix two-step TX timestamping (IFH REW_OP1, REW_OP[2:0]=3) actually work for CPU-injected frames with a non-PTP EtherType? The reference manual (16.4.13.12.3.1) states "can be applied to any frame, also non-PTP frames", but we measure SYS_PTP_STATUS VLD=0 (zero FIFO entries). Is the actual silicon behavior that, even with BYPASS=1 and REW_OP1 in the IFH, the rewriter still requires the frame to be classified as PTP (by EtherType / PTP header) before it produces a timestamp FIFO entry?

2. Does SYS_TIMESTAMP_OFFSET (inline timestamp insertion) have any hidden enable/trigger condition beyond the ETH_TYPE_CFG match? We verified: the register is written correctly (ETH_TYPE_CFG=0x88B5, offset=14), FCS update is enabled, DATA_WO_TS=0, and with a direct swp0↔eno0 cable we confirmed the egress frame content — but no timestamp was written into the frame. Is this feature also restricted on the CPU-injection (BYPASS) path?

3. On the CPU-injection (BYPASS=1) path, is there an officially supported way to get a hardware TX timestamp for arbitrary-EtherType custom frames transmitted on swp0? (e.g., some enable bit, a PTP classification table configuration, or a required frame format.)

4. If neither of the two manual-documented mechanisms supports non-PTP frames on this silicon, is there a known erratum or a recommended alternative?

Re: LS1028A Felix (swp0): Hardware TX Timestamp Not Produced for Custom-EtherType Frames on the CPU-

Two-step TX timestamping for non-PTP CPU-injected frames

The RM documents REW_OP[2:0] = 3 in the CPU Injection Header as “Two-step PTP,” with REW_OP[8:3] carrying the timestamp identifier; IDs 0–3 are explicitly pre-allocated for CPU-injected frames. It also states that two-step timestamping can be applied to “any frame, also non-PTP frames,” because the frame itself is not modified, and the TX timestamp is stored in SYS::PTP_STATUS / SYS::PTP_TXSTAMP . 

So, from the RM, BYPASS=1 + IFH REW_OP[2:0]=3 should be a valid mechanism for CPU-injected two-step timestamping, including non-PTP frames . I did not find RM evidence that the rewriter must first classify the frame as PTP by EtherType/header when the IFH supplies the two-step command. The contradictory part is your measurement: SYS_PTP_STATUS.PTP_MESS_VLD=0 after confirmed IFH REW_OP1 , which is not explained by the RM text I retrieved.

SYS_TIMESTAMP_OFFSET / inline timestamp insertion

ES_SYS_SYSTEM_TIMESTAMP_OFFSET is documented as matching ETH_TYPE_CFG and placing a 64-bit nanosecond TX timestamp at TIMESTAMP_OFFSET ; the manual even gives a “generic timestamp insert (Chronos)” example where offset 14 places the timestamp at absolute byte 28 in the Ethernet frame. 

I did not retrieve documentation that states an additional hidden enable bit beyond the general PTP enable / timestamp-offset configuration, nor documentation that explicitly says this feature is supported or blocked on CPU-injected BYPASS=1 frames. The RM wording supports the generic mechanism, but your direct-cable observation that no bytes are written at the expected offset indicates that, in this CPU-injection path, ETH_TYPE_CFG match alone is not sufficient in your setup.

Officially supported way under Linux DSA to timestamp arbitrary EtherType frames on swp0

The strongest software-side evidence says: generic packet timestamping is not supported by the DSA framework used by the LS1028A switch driver, even though the switch hardware is capable of it . 

Therefore, under the stock/standard DSA Felix driver model, I would treat PTP/IEEE-1588 event message timestamping as the supported path , and arbitrary EtherType 0x88B5 TX timestamping via SO_TIMESTAMPING on swp0 as not officially supported by that software stack . That aligns with your observation that valid 0x88F7 PTP frames timestamp reliably while 0x88B5 does not.

Erratum / recommended alternative

I did not retrieve a timestamp-specific LS1028A/Felix erratum for this behavior. The evidence I found says the published Felix erratum mentioned in the retrieved ticket material is ERR A-050484 , related to NPI flow control / frame-loss management rather than timestamp FIFO generation.