From owner-freebsd-arm@FreeBSD.ORG Wed Feb 6 21:54:46 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 1427DCEA for ; Wed, 6 Feb 2013 21:54:46 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from mail-oa0-f41.google.com (mail-oa0-f41.google.com [209.85.219.41]) by mx1.freebsd.org (Postfix) with ESMTP id CE38FD68 for ; Wed, 6 Feb 2013 21:54:45 +0000 (UTC) Received: by mail-oa0-f41.google.com with SMTP id i10so2077364oag.28 for ; Wed, 06 Feb 2013 13:54:39 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:sender:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to:x-mailer:x-gm-message-state; bh=G+MTvkhGNCVtRuRFbgUKkqPUR4E79tE8GZelJ2zxnJY=; b=FXu1/iKdevtd499lIReHTgtm7Wm3jwpBbX7g+wSuR7hN1+7zyEzYGktkxoMdBp0MGC 9ZsULThhPIP9kY7txiv1eXdFMJPqX019gkiMJM6xzh5yN4ejDZbj4cLxJOT/YGeT3Bp8 958nH/Txy/9qkSp06SYKhrPI//qK3p2GYBRhbhzj6wXUnOOY/cscadxdSWcy9JetN2+S 64KKp2CJpBfH43LiBGM/z0yiE4OFySa8cHX95o1UnOBIbmrvvtc40I/X+rKG7wZ6E3bs EJ13m7Up3ggaiaCLA8EPr42v8a2j7HnJTZELnEwGlThIiiJzGYfEi/mRvXugSR8T3Kwf R4MQ== X-Received: by 10.182.43.103 with SMTP id v7mr22195683obl.17.1360187679473; Wed, 06 Feb 2013 13:54:39 -0800 (PST) Received: from monkey-bot.int.fusionio.com ([209.117.142.2]) by mx.google.com with ESMTPS id b6sm31727864oee.3.2013.02.06.13.54.36 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 06 Feb 2013 13:54:37 -0800 (PST) Sender: Warner Losh Subject: Re: SD card -image- for the beaglebone Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: <1360177280.93359.611.camel@revolution.hippie.lan> Date: Wed, 6 Feb 2013 14:54:34 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <19C1F505-69C3-4DAB-8FE0-A34B30F08582@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> <1360177280.93359.611.camel@revolution.hippie.lan> To: Ian Lepore X-Mailer: Apple Mail (2.1085) X-Gm-Message-State: ALoCoQnV3gw+4skah1pKpkhxKZUfgSX6sZqWlAZAaNh8dX84xk4bX1jYYwWAi3Jf/tBdpJWmQIX0 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 21:54:46 -0000 On Feb 6, 2013, at 12:01 PM, Ian Lepore wrote: > On Wed, 2013-02-06 at 07:57 -0700, Warner Losh wrote: >> On Feb 6, 2013, at 6:46 AM, Ian Lepore wrote: >>=20 >>> 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.) >>=20 >> Yes, this is an edge case that is a whole in the current no-lock = algorithm... >>=20 >>> 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. >>=20 >> 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. >=20 > 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. =20 True. But ntpd will pick the best and steer to that rather do something = more sophisticaed. > I don't think ntpd goes all the way to a paper timescale, at least not > the older code I'm familiar most with.=20 No, it doesn't. >> 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... >=20 > 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. You could do that, but the daemon to control the rollover would need to = be in userland. The kernel certainly has no notion of failure = criteria... I doubt your theory though. I've never had multiple ref clock work out = well. Ever. Maybe the newer ntpd copes better, but the experiments I ran = about 10 years ago were at best abject failures. Warner=