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>