Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 6 Feb 2013 07:57:04 -0700
From:      Warner Losh <imp@bsdimp.com>
To:        Ian Lepore <ian@FreeBSD.org>
Cc:        freebsd-arm@FreeBSD.org
Subject:   Re: SD card -image- for the beaglebone
Message-ID:  <52928DD2-AA41-4B3C-A22A-1F755832D220@bsdimp.com>
In-Reply-To: <1360158409.93359.590.camel@revolution.hippie.lan>
References:  <510A4F5B.7000407@g7iii.net> <1359646574.93359.327.camel@revolution.hippie.lan> <510AE1D6.8010203@g7iii.net> <1360124308.93359.557.camel@revolution.hippie.lan> <5112115D.5040709@g7iii.net> <1360158409.93359.590.camel@revolution.hippie.lan>

next in thread | previous in thread | raw e-mail | index | archive | help

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:
>>=20
>>> Check out what I taught my beaglebone to do today...
>>>=20
>>> root@bb:/ # ntpq -p
>>>      remote           refid  st t when poll reach   delay   offset  =
jitter
>>> =
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>>> 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
>>>=20
>>> 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.  :)
>>>=20
>>> 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.
>>=20
>> Thanks for that, looks great, and very interesting. I'll do more than
>> play with it (well when the 8 Gig card arrives anyway!)
>>=20
>> First thought, extending for multiple PPS :) [Because I can :P]
>>=20
>=20
> 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.
>=20
> 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=



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?52928DD2-AA41-4B3C-A22A-1F755832D220>