This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

DP83640: Hardware PTP communication error on Linux

Part Number: DP83640

Hi team,

One of our customer's issues, I'm forwarding it below, could you please provide some troubleshooting suggestions? Any troubleshooting ideas are appreciated.

Currently we are using the DP83640PHY chip to implement the PTP protocol on the Linux side and the following error is reported when testing (Directive: ./ptp4l -i eth0   -m -H) with the ptp4l software:

ptp4l[1970.968]: port 1: assuming the grand master role
ptp4l[1971.969]: timed out while polling for tx timestamp
ptp4l[1971.969]: increasing tx_timestamp_timeout may correct this issue, but it is likely caused by a driver bug
ptp4l[1971.969]: port 1: send sync failed

ptp4l[90.823]: port 1: MASTER to FAULTY on FAULT_DETECTED (FT_UNSPECIFIED)
ptp4l[107.026]: port 1: FAULTY to LISTENING on INIT_COMPLETE
ptp4l[114.285]: port 1: LISTENING to MASTER on ANNOUNCE_RECEIPT_TIMEOUT_EXPIRES

Based on our current testing, it has not called the following function in the DP83640 driver

The master chip we currently use is stm32mp157

Linux kernel version 4.19

May I know how I can troubleshoot the issue?  We look forward to hearing from you.

Best Regards,

Amy Luo

  • Amy,

    I suggest that the customer use the 5.15 kernel driver file. Since the customer is using 4.19 kernel, we have to check what features are enabled in the later releases.

    Here is the link to the 5.15 Linux driver:
    https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/drivers/net/phy/dp83640.c?h=v5.15.74

    Sincerely,
    Jason Lee

  • Hi Jason,

    Below is the customer feedback:

    Thank you for your suggestion, I've tried it, but the problem hasn't improved. Here are some of my attempts:

    1. I tried to use the driver in the 5.15 kernel, but it failed to compile in the 4.19 kernel.

    2. I tried to downgrade to the driver in the 5.1 kernel, I can compile and use this driver, but the test results are still unchanged.

    Here is some information about the use environment that want to help with problem analysis

    1, the communication interface of dp83640 and MAC is RMII.

    2, currently using dp83640 can be normal network communication.

    3, the above problem exists when using PTP hardware time stamps.

    I have a question about this drive:

    The communication interface used by our hardware is RMII interface, but the information described in the driver file is MII interface. Is there a problem with this?

    Thanks,

    Amy

  • Amy,

    The only driver we have is for 5.15; Backporting requires customers to do mapping themselves (Manually add all functions from 5.15 to 4.19 then check functionality) Simply copy-and-pasting is not enough; They will need to match everything.

    Sincerely,

    Jason Lee

  • Hi Jason,

    Below is the customer feedback:

    Thank you for your suggestion, I tried to do the backporting but I found that this was too much of a problem to drive the 4.19 kernel and I cannot guarantee that the porting was correct.

    The current version is still 4.19

    And then I made some adjustments to the kernel configuration, attached is my kernel configuration file

    3644.config.txt

    Currently testing with ptp4l does not report ptp4l[1971.969]: port 1: send sync failed", but it reports a new error that reads as follows

    ./ptp4l -i eth0 -m -H -f ./ptp4l.conf
    ptp4l[550.155]: selected /dev/ptp0 as PTP clock
    ptp4l[550.372]: port 1: INITIALIZING to LISTENING on INIT_COMPLETE
    ptp4l[550.373]: port 0: INITIALIZING to LISTENING on INIT_COMPLETE
    ptp4l[557.582]: port 1: LISTENING to MASTER on ANNOUNCE_RECEIPT_TIMEOUT_EXPIRES
    ptp4l[557.582]: selected local clock 362530.fffe.0a8d7e as best master
    ptp4l[557.582]: port 1: assuming the grand master role
    ptp4l[563.590]: port 1: received DELAY_REQ without timestamp
    ptp4l[564.603]: port 1: received DELAY_REQ without timestamp
    ptp4l[565.609]: port 1: received DELAY_REQ without timestamp
    ptp4l[566.536]: port 1: received DELAY_REQ without timestamp
    ptp4l[566.622]: port 1: received DELAY_REQ without timestamp
    ptp4l[567.978]: port 1: received DELAY_REQ without timestamp
    ptp4l[568.608]: port 1: received DELAY_REQ without timestamp

    ./ptp4l -i eth0 -m -H -s -f ./ptp4l.conf
    ptp4l[70.044]: selected /dev/ptp0 as PTP clock
    ptp4l[70.261]: port 1: INITIALIZING to LISTENING on INIT_COMPLETE
    ptp4l[70.262]: port 0: INITIALIZING to LISTENING on INIT_COMPLETE
    ptp4l[77.233]: selected local clock 8a6a12.fffe.3f2e3c as best master
    ptp4l[82.387]: port 1: new foreign master 362530.fffe.0a8d7e-1
    ptp4l[83.386]: port 1: received SYNC without timestamp
    ptp4l[83.896]: selected local clock 8a6a12.fffe.3f2e3c as best master
    ptp4l[84.386]: port 1: received SYNC without timestamp
    ptp4l[85.386]: port 1: received SYNC without timestamp
    ptp4l[86.386]: port 1: received SYNC without timestamp
    ptp4l[86.403]: selected best master clock 362530.fffe.0a8d7e
    ptp4l[86.403]: port 1: LISTENING to UNCALIBRATED on RS_SLAVE
    ptp4l[87.386]: port 1: received SYNC without timestamp
    ptp4l[88.386]: port 1: received SYNC without timestamp
    ptp4l[89.387]: port 1: received SYNC without timestamp
    ptp4l[90.387]: port 1: received SYNC without timestamp
    ptp4l[91.387]: port 1: received SYNC without timestamp

    I tried this to fix:[PATCH 5.6 06/41] net: stmmac: enable timestamp snapshot for required PTP packets in dwmac v5.10a - Greg Kroah-Hartman (kernel.org)

    But the problem still arises.

    I look forward to your reply on how I can fix it.

    Thank you,

    Amy Luo

  • Amy,

    Unfortunately, our team does not have the specific expertise to support backporting; Our best recommendation is still to use the latest version. 

    Sincerely,

    Jason Lee