Question: GPS disciplined stratum 1 NTP service with PPS?

[Dan Cross]

I'm curious if anyone has set up a GPS-disciplined, stratum 1 time
server using a PPS signal on Dragonfly? I have an old PCEngines apu1d
that I plan to dedicate to this task, and I'd like to run Dragonfly on
this machine. I see that Chrony is in the ports collection (though a
slightly older version), and I'd like to use that as the NTP server
software; my question is more about the PPS signal, and finding a
source for that.

On the hardware side, in many respect, the apu1d is almost an ideal
system for this application: it's small, fanless, low-power, has a
battery-backed RTC, provides fairly robust storage in the form of
mSATA, and (importantly) has two UARTs; one at RS-232 levels, and the
second that runs at 3V3. The internal clocks are probably good enough
to get ~1usec accuracy; definitely within a few 10s of usec.
Typically, one uses the first for a console; the second could easily
accommodate the NMEA output of a GPS receiver. A downside is that,
according to the schematic, the second UART's modem control signals
aren't lined out and are currently NC, though it looks simple enough
to jumper them to a header by soldering some thin-gauge wire directly
to the relevant IC's pins (e.g., to expose DCD for the GPS's PPS
signal). The apu1d also has a fairly large GPIO unit, one pin of which
could be dedicated to a PPS signal. Or, I could make no modifications
and run the console on the second UART, perhaps building a small PCB
with a level-shifter to convert the serial signals and PPS coming out
of the GPS to RS-232 levels, and just connect to the first UART.
Anyway, the point is, the hardware seems capable enough.

The question is more about support for PPS. There is some support in
the kernel already, and there's a `PPS_SYNC` option and `pps`
pseudo-device that one can enable in custom kernel configs. It also
appears as though the serial driver will inject PPS "events" into the
kernel's timing machinery when DCD is asserted (or de-asserted, for
that matter). It's lacking the `gpiopps` driver that's in FreeBSD and
NetBSD, but perhaps that's not needed, and piggybacking off of the
modem control signals is "good enough".

So it seems like all of the pieces are there. My question is: has
anyone else tried this? Is my analysis wrong? Are there any other
caveats to consider? Thanks for any insight!

        - Dan C.