[time-nuts] Beaglebone Black driver for hardware timer capture

[Dan Drown]

I wrote a kernel driver for the BBB timer hardware. It produces pps events for things like ntpd to consume. The source for it is at https://github.com/ddrown/pps-gmtimer

A side effect of this driver is it measures the interrupt latency and jitter on the BBB hardware. The attached file interrupt-latency.png contains an interrupt latency histogram and cumulative distribution function. This interrupt latency should be similar to what the pps-gpio driver experiences on this hardware. The difference is the timer hardware driver can remove the effects of the interrupt latency.

The graphs of offset over 7 days worth of samples don't show a huge difference. The *-timer.png file is from pps-gmtimer and the *-gpio.png file is from pps-gpio. The stddev of the offsets are 244ns from the gpio run and 143ns from the timer run.

The BBB hardware supports hardware IEEE1588/PTP timestamps, so people might be interested in that as well. The driver for it is already in Linux, but not enabled in the default BBB kernel config.

Let me know if you have any questions.

Unrelated to the PPS driver: all the feedback on the software frequency temperature compensation has been useful. 90% of the time, the local clock is within 173ppb. 98% of the time, it's within 218ppb. I think I can narrow this range even further with a temperature rate of change variable. All the graphs are at http://dan.drown.org/bbb/latest/

[Iain Young]

Hey Dan,

Post by Dan Drown
I wrote a kernel driver for the BBB timer hardware. It produces pps events for things like ntpd to consume. The source for it is at https://github.com/ddrown/pps-gmtimer
A side effect of this driver is it measures the interrupt latency and jitter on the BBB hardware. The attached file interrupt-latency.png contains an interrupt latency histogram and cumulative distribution function. This interrupt latency should be similar to what the pps-gpio driver experiences on this hardware. The difference is the timer hardware driver can remove the effects of the interrupt latency.
The graphs of offset over 7 days worth of samples don't show a huge difference. The *-timer.png file is from pps-gmtimer and the *-gpio.png file is from pps-gpio. The stddev of the offsets are 244ns from the gpio run and 143ns from the timer run.

Great work. I will have to try this driver, I've been using the FreeBSD
equivalent, it's good to see someone has actually done the Linux version
as well now. That will be anoŧher Christmas/New Year project!

Post by Dan Drown
The BBB hardware supports hardware IEEE1588/PTP timestamps, so people might be interested in that as well. The driver for it is already in Linux, but not enabled in the default BBB kernel config.

Indeed, this support is still missing in FreeBSD, and the PRU support is
much more mature on linux (although it does work on FreeBSD, I had some
issues with working out what was going on at times, but that might well
have been operator error without time to debug)

Post by Dan Drown
Let me know if you have any questions.

Is your code able to support multiple inputs simultaneously ? FreeBSD's
doesn't due to some architecture issue with the timing subsystem as I
understand it.

Or is it like the FreeBSD code, and I have to select exactly one of
TIMER4-TIMER7 input pins to drive the PPS ?

The Beaglebone also has the facility for an external clock input. Are
you planning on doing any work in order to get the Linux kernel to
select the TCLKIN as the clock ?


Best Regards

Iain
_______________________________________________
time-nuts mailing list -- time-***@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

[Dan Drown]

Post by Iain Young
Is your code able to support multiple inputs simultaneously ? FreeBSD's
doesn't due to some architecture issue with the timing subsystem as I
understand it.
Or is it like the FreeBSD code, and I have to select exactly one of
TIMER4-TIMER7 input pins to drive the PPS ?

In theory it should support multiple timers, each with their own
/dev/ppsX file. I haven't tested that part yet, though :)

The timer hardware to use is selected with the device tree overlay.
Creating multiple pps-gmtimer device tree elements, each with their
own timer should be possible. I'm not sure how much having two or
more timer capture interrupts at the same time will affect timing
accuracy. That's also something that needs experimenting with. The
calculation of when the event happened is done in the interrupt
handler, and it subtracts how long ago the event happened from the
current time. Since I'm not currently adjusting for local clock
speed, this adds 1 nanosecond of error for every 17 microseconds the
interrupt is delayed (assuming 60ppm local clock error).

Post by Iain Young
The Beaglebone also has the facility for an external clock input. Are
you planning on doing any work in order to get the Linux kernel to
select the TCLKIN as the clock ?

It should be pretty easy to switch to TCLKIN, the function
"omap_dm_timer_set_source" is already there for it. Either the main
timer used for the system clock (in arch/arm/mach-omap2/timer.c) or
this module could be changed to use TCLKIN. If this module was
extended to also be a clocksource, it could be used for system time as
well.

I don't have any hardware to experiment with TCLKIN on hand, so I
won't be doing that this month at least.
_______________________________________________
time-nuts mailing list -- time-***@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.