Re: [chrony-dev] [RFC] Support for raw memory mapped clock sources

[S E <s.egbert@xxxxxxxxxxxxx>]

Wow.... Xilinx FPGA MPSoC, nice stuff.  Worked with many Xilinx.

In your case (mind you, it has been 15y since having done 35y of embedded work), I would strongly suggest the 'driver' route.

Really don't want any applications to access the direct memory of a device directly and this includes chrony.

Current prevailing method: use an OS-based driver interface.

Chrony is designed to obtain timestamps and PPS data through standard kernel interfaces (e.g., Linux PHC via clock_gettime() on /dev/ptpX, or SO_TIMESTAMPING for NIC hardware timestamping). Direct user-space memory access to FPGA registers bypasses kernel time discipline, lacks locking, and breaks Chrony’s expectation of stable clock adjustment paths.

Best practice for FPGA MPSoC:

1. Expose your hardware clock or timestamp counter through a kernel driver registered as a PTP Hardware Clock (PHC).

2. Let Chrony access it through the refclock PHC or hwtimestamp mechanism.

3. Use ptp4l or similar tools if servo control is needed in-kernel.

Direct memory mapping is used only in specialized bare-metal or research cases, not in maintained Linux/Chrony deployments.

On Tuesday, October 21, 2025 at 08:40:07 AM CDT, Enguerrand de Ribaucourt <enguerrand.de-ribaucourt@xxxxxxxxxxxxxxxxxxxx> wrote:

Hello,

I have two embedded products which will have a GPS clock source

connected to a Xilinx FPGA MPSoC. However, the GPS PPS and NMEA traffic

will be routed to the programmable logic, not the Linux side..

The FPGA will be able to communicate the timestamps through some

reserved memory connected with the Linux CPU cores. My idea is to reuse

the existing SHM support of chrony. It does pretty much what I want:

read a timestamp binary structure from a memory mapping.

However, the current SHM refclok implementation is specific to SHM

devices, wherehas my FPGA's registers will appear within raw memory

devices like /dev/mem, or /dev/uio..

I see two options for passing the raw memory structure to chrony:

  1. Write an additional middleware that maps the raw memory device and

copies it regularly into an SHM device

  2. Add support for raw memory mappings to chrony, with lots of

resemblance to the current refclock_shm.c implementation

Which approach would you recommend? If adding support to chrony makes

sense for the general public, my company would likely be willing to

contribute this upstream. We have multiple devices in different activity

sectors with this hardware configuration. The options would look like:

  1. GPS -> FPGA -> AXI -> CPU -> /dev/uio -> middleware (custom) ->

/dev/shm -> chrony

  2. GPS -> FPGA -> AXI -> CPU -> /dev/uio -> chrony (patched)

Also, I don't think using DMA should be necessary given the small size

of the struct shmTime. For the PPS signal, the FPGA can connect share a

GPIO, so I will use the pps-gpio driver.

Thank you for your time,

Enguerrand de Ribaucourt,

Savoir-faire Linux (FR)

--

To unsubscribe email chrony-dev-request@xxxxxxxxxxxxxxxxxxxx with "unsubscribe" in the subject.

For help email chrony-dev-request@xxxxxxxxxxxxxxxxxxxx with "help" in the subject.

Trouble?  Email listmaster@xxxxxxxxxxxxxxxxxxxx.