From owner-freebsd-arm@FreeBSD.ORG Wed Feb 6 19:01:26 2013 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 10A50B7D for ; Wed, 6 Feb 2013 19:01:26 +0000 (UTC) (envelope-from ian@FreeBSD.org) Received: from duck.symmetricom.us (duck.symmetricom.us [206.168.13.214]) by mx1.freebsd.org (Postfix) with ESMTP id 6E6331F3 for ; Wed, 6 Feb 2013 19:01:25 +0000 (UTC) Received: from damnhippie.dyndns.org (daffy.symmetricom.us [206.168.13.218]) by duck.symmetricom.us (8.14.6/8.14.6) with ESMTP id r16J1NuV017970 for ; Wed, 6 Feb 2013 12:01:24 -0700 (MST) (envelope-from ian@FreeBSD.org) Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id r16J1LLj033543; Wed, 6 Feb 2013 12:01:21 -0700 (MST) (envelope-from ian@FreeBSD.org) Subject: Re: SD card -image- for the beaglebone From: Ian Lepore To: Warner Losh In-Reply-To: <52928DD2-AA41-4B3C-A22A-1F755832D220@bsdimp.com> 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> <52928DD2-AA41-4B3C-A22A-1F755832D220@bsdimp.com> Content-Type: text/plain; charset="us-ascii" Date: Wed, 06 Feb 2013 12:01:20 -0700 Message-ID: <1360177280.93359.611.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: freebsd-arm@FreeBSD.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Feb 2013 19:01:26 -0000 On Wed, 2013-02-06 at 07:57 -0700, Warner Losh wrote: > 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@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. Ntpd already does some clock combining stuff, and it's possible to tell ntpd to pass steering info to the kernel, rather than doing a kcbind() in the ntpd refclock driver and then having ntpd monitor the kernel's steering. I don't think ntpd goes all the way to a paper timescale, at least not the older code I'm familiar most with. > 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... Well, besides running a little roll-your-own clock ensemble system, a more mundane use of multiple PPS inputs would be simple failover for ntpd. At least, I think in theory it should work fine to configure ntpd with multiple refclocks and if one goes bad it can continue with others. -- Ian