From owner-freebsd-arm@freebsd.org Wed Jul 31 15:32:42 2019 Return-Path: Delivered-To: freebsd-arm@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id C7B77A1D0A for ; Wed, 31 Jul 2019 15:32:42 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from outbound2m.ore.mailhop.org (outbound2m.ore.mailhop.org [54.149.155.156]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 45zHVf4KwPz3yCD for ; Wed, 31 Jul 2019 15:32:42 +0000 (UTC) (envelope-from ian@freebsd.org) ARC-Seal: i=1; a=rsa-sha256; t=1564587161; cv=none; d=outbound.mailhop.org; s=arc-outbound20181012; b=GsnOALfAfTaLBjFanqT39jVtimRBIOZf+yeMvAOnt2/gUa8Twm3mn2jAJQpxIC3AhH10SIdwjNwjP UxsQLpL4toFrDZHe0T0sbVnpqJvYA3EBtFTaeSGaIRIE4fTBY7tp8k/v8q7QB32sKTzIIzuDokJu+L bi/+VoBQfvQaxTiw2SAglJdy3hrIfwozv4maPwulV3zMvPeW8bSLQEJvsA/ctjJEUDqjVB80x4qFHK RUjec0POv7UgV6b1zRtot8vMpBpsJXwDjlR2ja2GLDO/eFLSaFwKyA5tyWhxRz8sk+f2mnJ+1aien8 w4r6Z1EHUiNmiBOMIwD7YxdlTSDRfVw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=outbound.mailhop.org; s=arc-outbound20181012; h=content-transfer-encoding:mime-version:content-type:references:in-reply-to: date:to:from:subject:message-id:dkim-signature:from; bh=Tjk3HnQX1BDv1C3qy8BA1krGLD+Itgm2tngXo87j8DU=; b=vOL6PEbXVAoxQCop4Lvm5A57IYRLvCy5eqXAak+ZDlNynN3b//7TDy9bm4euuuyDG53upeGP2vBvq zaan7VYH6KlBJUxlLHV9ypOGOrIpkNFWT2rNgpcZnbm/6bcTn5XKECx70Rh6tiBkVdX8ylBpl6newr 24HeTMTkZ60I9kZ988nGyW2p8DfkMSxPFM1c9DB0Fez9ajVJbiaWGae3ChgFcX74CYu7lJmZgL7YQa H5Z6jJ33CdOFwWHqMrDVx/PfglAptXIqzsipKnIVIodjOLAW989mh3MFnwXE55zVX+TA3TT7rxo3g/ Su+p/6YBVQeNpLolkCuzI3wZCk70IRA== ARC-Authentication-Results: i=1; outbound4.ore.mailhop.org; spf=softfail smtp.mailfrom=freebsd.org smtp.remote-ip=67.177.211.60; dmarc=none header.from=freebsd.org; arc=none header.oldest-pass=0; DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=outbound.mailhop.org; s=dkim-high; h=content-transfer-encoding:mime-version:content-type:references:in-reply-to: date:to:from:subject:message-id:from; bh=Tjk3HnQX1BDv1C3qy8BA1krGLD+Itgm2tngXo87j8DU=; b=JiZMZEUzXZoU4B4IrdNI56JRqzFIJWilQ98BWupv/APVudUgH7X/RQFgVpecg4E3pJoqVPYZP84Vy xmKK0BmM01QjwhOEhbfcFbr8lB66/mPSpOG+VrKzbgEBHg3qzI4brDaYF7Y66kI3IBx8UQjJkjvIIy Adxyk9jwyk2B902aFdtDZvMOUZMzaO+XnWkS0copnRVJ/0mJpyF8/i7o7IB78kEzItyqtcR16RIDzo qHeEAbzqw3pZYnKX4CqDowYrQym0Ki4oR+FxkML54ID6nEpNDv53XVQuYFkMg5BHdY5Odui7tomiFh +XWHwy0R8kiBOemLtuwPNo/mrJsRz5g== X-MHO-RoutePath: aGlwcGll X-MHO-User: 6db30a48-b3a8-11e9-85ec-13b9aae3a1d2 X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 67.177.211.60 X-Mail-Handler: DuoCircle Outbound SMTP Received: from ilsoft.org (unknown [67.177.211.60]) by outbound4.ore.mailhop.org (Halon) with ESMTPSA id 6db30a48-b3a8-11e9-85ec-13b9aae3a1d2; Wed, 31 Jul 2019 15:32:40 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.15.2) with ESMTP id x6VFWcis097366; Wed, 31 Jul 2019 09:32:38 -0600 (MDT) (envelope-from ian@freebsd.org) Message-ID: <8e33e48f83f9a53015e165e53d4123c1c5b4e33e.camel@freebsd.org> Subject: Re: Pine64-LTS overlays for uart ports fixed! From: Ian Lepore To: Kaya Saman , "freebsd-arm@freebsd.org" Date: Wed, 31 Jul 2019 09:32:38 -0600 In-Reply-To: <388e17e7-a277-9cd9-47ea-a38f10c7c741@optiplex-networks.com> References: <5f30c425-60c6-d54a-9593-2584bcf25925@optiplex-networks.com> <09afae63-3583-46bd-8911-82a0f0a3185f@optiplex-networks.com> <2ab16425ac48bb7ff4365561b8959ee3eac50530.camel@freebsd.org> <388e17e7-a277-9cd9-47ea-a38f10c7c741@optiplex-networks.com> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.28.5 FreeBSD GNOME Team Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 45zHVf4KwPz3yCD X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-0.13 / 15.00]; local_wl_from(0.00)[freebsd.org]; NEURAL_HAM_SHORT(-0.13)[-0.127,0]; ASN(0.00)[asn:16509, ipnet:54.148.0.0/15, country:US] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Jul 2019 15:32:42 -0000 On Wed, 2019-07-31 at 16:17 +0100, Kaya Saman wrote: > On 7/31/19 3:06 PM, Ian Lepore wrote: > > On Wed, 2019-07-31 at 14:33 +0100, Kaya Saman wrote: > > > On 7/31/19 1:42 AM, Ian Lepore wrote: > > > > On Wed, 2019-07-31 at 00:46 +0100, Kaya Saman wrote: > > > > > [...] > > > > > > I am seeing this: > > > > > > gpsd:PROG: PPS:/dev/gps1 Assert cycle: 999973, duration: 799977 @ > > > 1564579823.472659791 > > > gpsd:PROG: PPS:/dev/gps1 Assert rejected missing last_fixtime > > > > > > > > > Perfect ;-) > > > > > > > > > I think I need to add pps_mode=0x11 or 17 in dec. as the pulse is > > > inverted. > > > > > > > > > This setup was working previously using a Prolific Serial to USB adapter > > > for testing purposes as of course the USB introduces high latency. > > > > > > > Actually, not so much as you'd think. I expected both high latency and > > a lot of jitter when using a usb-serial for PPS, and what I found was a > > fixed latency of less than a millisecond and jitter on the order of 60- > > 80 microseconds. Even trying to saturate the usb bus by doing > > continuous or bursty IO to a disk drive didn't noticibly increase the > > pps latency or jitter. I was pretty surprised. > > > > -- Ian > > > > > > That's very interesting! > > > My finding was that the accuracy went from the 10's of uS using a > standard RS232 D-Sub port on one of my x64 systems to the 100's of uS > range when switching to the Pine64 and using the USB->Serial adapter. > > > Looks like the PPS signal just kicked in: > > > gpsd:PROG: KPPS:/dev/gps1 Clear cycle: 999974, duration: 799981 @ > 1564585351.860177245 > gpsd:PROG: PPS:/dev/gps1 Clear cycle: 999974, duration: 799981 @ > 1564585351.860177245 > gpsd:PROG: PPS:/dev/gps1 Clear rejected this second already handled > gpsd:PROG: KPPS:/dev/gps1 assert 1564585352.060170121, sequence: 5543, > clear 1564585351.860177245, sequence: 5543 - using: assert > gpsd:PROG: KPPS:/dev/gps1 Assert cycle: 999974, duration: 199992 @ > 1564585352.060170121 > gpsd:PROG: PPS:/dev/gps1 Assert cycle: 999974, duration: 199992 @ > 1564585352.060170121 > gpsd:PROG: PPS:/dev/gps1 Assert rejected 1Hz trailing edge > > > After stopping the gpsd service and restarting it's finding it difficult > to startup again. I attempted with dev.uart.4.pps_mode=0x21 for 'narrow' > pulses even though 200ms-1 shouldn't be considered 'narrow'?? I'm guessing. > > > Once I understand a little bit more about the behavior and quirks of the > setup I'll probably start looking at how to enable an input switch on a > GPIO pin then trying to get/write a driver for lcdproc and the Newhaven > display. The aim is to use the retractive mechanical switch to change > the LCD display from clock to GPS info.... > / { > pps@0 { > compatible = "pps-gpio"; > pinctrl-names = "default"; > pinctrl-0 = <&pinctrl_pps0>; > gpios = <&gpio1 0 GPIO_ACTIVE_HIGH>; /* change this */ > status = "okay"; > }; > }; > > The gpios= property will need to refer to the right bank and > > Still lots of work to go but it's definitely a really fun project :-) > > > Regards, > > > Kaya I've never used gpsd and don't know how to interpret its output. Narrow-pulse mode is for pulses down in the few-microseconds range (professional timekeeping equipment often has very short pps pulses, in the 1-100us range). I've always been uneasy with the idea of using CTS for a pps signal, since the uart hardware itself may want to use that line. I wonder if it would help to use the .lock device to force off rtscts flow control? Or, maybe even better, instead of using that pin as a uart cts signal, maybe redo the pinmux to make it a gpio pin, then use the standard gpiopps driver. You might need to add a symlink from /dev/gpiopps0 to /dev/gps1 or whatever gpsd expects. I'm not sure how to do the pinmux node for a gpio pin on that hardware, but you can probably find an example of that. The dts source to enable a gpio pin for pps is: / { pps@0 { compatible = "pps-gpio"; pinctrl-names = "default"; pinctrl-0 = <&pinctrl_pps0>; gpios = <&gpio1 0 GPIO_ACTIVE_HIGH>; /* change this */ status = "okay"; }; }; The gpios= property will need to refer to the right bank and pin number for that hardware. -- Ian