SD card -image- for the beaglebone

[Warner Losh]

On Feb 6, 2013, at 6:46 AM, Ian Lepore wrote:

> On Wed, 2013-02-06 at 08:16 +0000, Iain Young wrote:
>> On 06/02/13 04:18, Ian Lepore wrote:
>> 
>>> Check out what I taught my beaglebone to do today...
>>> 
>>> root at bb:/ # ntpq -p
>>>      remote           refid  st t when poll reach   delay   offset  jitter
>>> ==========================================================================
>>> oPPS(0)          .PPS.        0 l    4   16  377    0.000    0.399   0.008
>>> +dvb.hippie.lan  .GPS.        1 u   55   64  377    1.411    0.666   0.126
>>> +tflex.hippie.la .GPS.        1 u   15   64  377    0.901    1.867   0.904
>>> +paranoia.hippie .PPS.        1 u   61   64  377    0.396    0.426   0.025
>>> xutcnist2.colora .ACTS.       1 u   71   64  376   34.136  -11.277   4.656
>>> xnist1.symmetric .ACTS.       1 u   63   64  377   59.880   12.327   2.113
>>> -ntp.your.org    .CDMA.       1 u    4   64  377   51.185   -4.212   4.215
>>> xntp1.conectiv.c .IRIG.       1 u   51   64  377   99.067   17.784   3.445
>>> 
>>> It turns out the chip has nice timer hardware that can latch the
>>> freeruning timercounter in response to the PPS signal.  That allows for
>>> a PPS driver that doesn't use interrupts at all.  The timecounter code
>>> has a specific interface for such hardware, but there isn't much example
>>> code in the base for how to use it.  Soon there'll be more.  :)
>>> 
>>> I'll attach a patch in case anyone else wants to play with this.  To use
>>> it, apply the patch, add "options PPS_SYNC" to the kernel config, and
>>> choose which timer pin you want to put the pps on.  The attached patch
>>> uses the timer4 pin, which is exposed on the P8 connector as pin #7.
>>> You can use any of the timer4-timer7 pins, just set the one you want to
>>> use to "input" in the dts and the driver will use it.
>> 
>> Thanks for that, looks great, and very interesting. I'll do more than
>> play with it (well when the 8 Gig card arrives anyway!)
>> 
>> First thought, extending for multiple PPS :) [Because I can :P]
>> 
> 
> This kind of no-interrupt PPS driver that's tied closely to the system
> timecounter can only handle a single PPS signal.  (There's only one
> system timer, and it has just one trigger pin.)  Connecting more than
> one PPS is still going to require an interrupt-driven gpio solution.
> 
> Even though there are four timers on the chip that have an external
> trigger input wired to a pin, it's basically impossible with the current
> freebsd timing code to combine triggered-capture of the pps pulse time
> with traditional interrupt handling to harvest the captured counter.
> When you try to do this, you occasionally end up with a sequence where
> the hardware latches the counter, then the timekeeping code switches to
> a new set of timehands before the interrupt handler is invoked, then you
> end up grabbing a latched counter value that matches up with the wrong
> set of timehands, and you get a measurement jump equal to the timer tick
> period.  (I know most people don't care about these details, but it's
> actually nice to get them in writing somewhere searchable for future
> reference.)

Yes, this is an edge case that is a whole in the current no-lock algorithm...

> I've never configured a system for multiple PPS inputs, that'll be an
> interesting thing to play with.  I need to learn more about our gpio
> framework (such as it is) and see if it's possible to put in a nice
> generic PPS driver that uses it.

The current time keeping stuff assumes you have *THE* source of time in the PPS. Having multiple sources requires more sophisticated techniques than the simple FLL/PLL loop the kernel implements, since you effectively have to construct a paper clock.

If you are creating a measurement system, and not just pacing system time to a good, solid reference frequency, then you'll have to have time counters that can latch the signals independently, and have some sort of interrupt/poll routine that harvests the data for later analysis. The analysis and construction of paper clocks ranges from "easy, but with so-so results" all the way to "extremely hard, but with extremely good results." The devil is in the details, and usually in the details of what you do when one or more signals go away...

Warner

Warner