From owner-freebsd-arm@freebsd.org Wed Jul 31 16:23:02 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 65274A30F6 for ; Wed, 31 Jul 2019 16:23:02 +0000 (UTC) (envelope-from kayasaman@optiplex-networks.com) Received: from x-ray.optiplex-networks.com (mail.optiplex-networks.com [212.159.80.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 45zJcj0mxfz429n; Wed, 31 Jul 2019 16:23:01 +0000 (UTC) (envelope-from kayasaman@optiplex-networks.com) Received: from localhost (localhost [127.0.0.1]) by x-ray.optiplex-networks.com (Postfix) with ESMTP id 6B6B77210E3; Wed, 31 Jul 2019 17:22:57 +0100 (BST) Received: from x-ray.optiplex-networks.com ([127.0.0.1]) by localhost (x-ray.optiplex-networks.com [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id JwmYpydbaCc1; Wed, 31 Jul 2019 17:22:57 +0100 (BST) Received: from localhost (localhost [127.0.0.1]) by x-ray.optiplex-networks.com (Postfix) with ESMTP id 118E272645A; Wed, 31 Jul 2019 17:22:57 +0100 (BST) X-Virus-Scanned: amavisd-new at x-ray.optiplex-networks.com Received: from x-ray.optiplex-networks.com ([127.0.0.1]) by localhost (x-ray.optiplex-networks.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 749T2rK4aoyU; Wed, 31 Jul 2019 17:22:57 +0100 (BST) Received: from x220.optiplex-networks.com (unknown [192.168.0.195]) by x-ray.optiplex-networks.com (Postfix) with ESMTPSA id F1E477210E3; Wed, 31 Jul 2019 17:22:56 +0100 (BST) Subject: Re: Pine64-LTS overlays for uart ports fixed! To: Ian Lepore , "freebsd-arm@freebsd.org" 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> <8e33e48f83f9a53015e165e53d4123c1c5b4e33e.camel@freebsd.org> From: Kaya Saman Message-ID: <20926ddd-425d-601c-0d8d-46bb480f61ff@optiplex-networks.com> Date: Wed, 31 Jul 2019 17:22:56 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.7.2 MIME-Version: 1.0 In-Reply-To: <8e33e48f83f9a53015e165e53d4123c1c5b4e33e.camel@freebsd.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US X-Rspamd-Queue-Id: 45zJcj0mxfz429n X-Spamd-Bar: ++ Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of kayasaman@optiplex-networks.com designates 212.159.80.20 as permitted sender) smtp.mailfrom=kayasaman@optiplex-networks.com X-Spamd-Result: default: False [2.46 / 15.00]; ARC_NA(0.00)[]; TO_DN_EQ_ADDR_SOME(0.00)[]; RCVD_COUNT_FIVE(0.00)[6]; RCVD_VIA_SMTP_AUTH(0.00)[]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(0.00)[+mx]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_LAST(0.00)[]; DMARC_NA(0.00)[optiplex-networks.com]; SH_EMAIL_DBL(7.00)[0.0.0.0]; BAD_REP_POLICIES(0.10)[]; IP_SCORE(-3.55)[ip: (-9.41), ipnet: 212.159.64.0/18(-4.71), asn: 6871(-3.57), country: GB(-0.08)]; MX_GOOD(-0.01)[cached: mail.optiplex-networks.com]; RCPT_COUNT_TWO(0.00)[2]; NEURAL_HAM_SHORT(-0.97)[-0.973,0]; SUBJECT_ENDS_EXCLAIM(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:6871, ipnet:212.159.64.0/18, country:GB]; MID_RHS_MATCH_FROM(0.00)[]; SH_EMAIL_ZRD(0.00)[0.0.0.0] 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 16:23:02 -0000 On 7/31/19 4:32 PM, Ian Lepore wrote: > 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). Ok then I don't need to use it as my receiver isn't capable of anything below 20ms-1 http://static.garmin.com/pumac/GPS_18x_Tech_Specs.pdf > > 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? I could try this though I'm not sure how to go about it. Would this be performed by the stty command? Currently -ixon is set on the port so that makes output control disabled. I could also try setting -ixoff to disable the input queue.... > > 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 > This might work better. I'll have a go later today. I did have issues while trying things out on Armbian so I don't know if it will the same case with FreeBSD. Virtually what happened was that setting the pin in the loader didn't take effect. Thanks again Ian :-) Best Regards, Kaya