From owner-freebsd-arm@freebsd.org Wed Jul 31 15:17:46 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 99B61A16C3 for ; Wed, 31 Jul 2019 15:17:46 +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 45zH9P3JPzz3x8M; Wed, 31 Jul 2019 15:17:45 +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 790637210E3; Wed, 31 Jul 2019 16:17:42 +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 ap9xJewso0hu; Wed, 31 Jul 2019 16:17:42 +0100 (BST) Received: from localhost (localhost [127.0.0.1]) by x-ray.optiplex-networks.com (Postfix) with ESMTP id 28B15726464; Wed, 31 Jul 2019 16:17:42 +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 fkc-7vjudT5U; Wed, 31 Jul 2019 16:17:42 +0100 (BST) Received: from x220.optiplex-networks.com (unknown [192.168.0.195]) by x-ray.optiplex-networks.com (Postfix) with ESMTPSA id 0D8BA7210E3; Wed, 31 Jul 2019 16:17:42 +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> From: Kaya Saman Message-ID: <388e17e7-a277-9cd9-47ea-a38f10c7c741@optiplex-networks.com> Date: Wed, 31 Jul 2019 16:17:41 +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: <2ab16425ac48bb7ff4365561b8959ee3eac50530.camel@freebsd.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 45zH9P3JPzz3x8M 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 [-4.90 / 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.20)[+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]; IP_SCORE(-3.60)[ip: (-9.53), ipnet: 212.159.64.0/18(-4.77), asn: 6871(-3.61), country: GB(-0.08)]; MX_GOOD(-0.01)[cached: mail.optiplex-networks.com]; RCPT_COUNT_TWO(0.00)[2]; NEURAL_HAM_SHORT(-0.99)[-0.993,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)[] 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:17:46 -0000 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: >>>> Hi guys, >>>> >>>> >>>> just wanted to say that I managed to fix the overlay issue for >>>> the uart >>>> ports. I just updated my bug report: >>>> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D239390 >>>> >>>> >>>> So, thanks to everyone who provided assistance and especially >>>> Milan for >>>> the introduction to the 'overlay' system and the dtso file :-) >>>> >>>> >>>> Just need to figure out why PPS isn't working now, my GPS >>>> receiver is >>>> sending the information so it definitely is a system config issue >>>> - >>>> either wrong pin or something in the OS... (still looking into >>>> it). Also >>>> needing a driver in lcdproc for my Newhaven displays and after >>>> that the >>>> project will be perfect :-) :-) :-) >>>> >>>> >>>> Best Regards, >>>> >>>> >>>> Kaya >>>> >>>> >>> Is the GPS receiver delivering the pps signal on one of the uart >>> pins >>> such as cts? If it's using cts, you probably need this change to >>> your >>> overlay: >>> >>> --- sun50i-a64-uart4.dts.orig 2019-07-30 18:35:19.188762000 >>> -0600 >>> +++ sun50i-a64-uart4.dts 2019-07-30 18:37:02.015479000 -0600 >>> @@ -30,7 +30,7 @@ >>> target =3D <&uart4>; >>> __overlay__ { >>> pinctrl-names =3D "default"; >>> - pinctrl-0 =3D <&uart4_pins>; >>> + pinctrl-0 =3D <&uart4_pins &uart4_rts_cts_pins>; >>> status =3D "okay"; >>> }; >>> }; >>> >>> You may also need to set sysctl dev.uart.4.pps_mode=3D1 for CTS, in >>> /etc/sysctl.conf. >>> >>> If it's using some other pin such as RI or CD, there is no pre- >>> written >>> pinctrl entry for it in those overlays you found, and some more >>> research into how to add the right pinctrl nodes will be needed. >>> >>> -- Ian >>> >> Bingo!!! :-) :-) >> >> >> Thank you so much Ian..... >> >> >> 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=3D0x11 or 17 in dec. as the pulse is >> inverted. >> >> >> This setup was working previously using a Prolific Serial to USB adapt= er >> 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=20 standard RS232 D-Sub port on one of my x64 systems to the 100's of uS=20 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:=C2=A0 999974, duration:=C2=A0 7999= 81 @=C2=A0=20 1564585351.860177245 gpsd:PROG: PPS:/dev/gps1 Clear cycle:=C2=A0 999974, duration:=C2=A0 79998= 1 @=C2=A0=20 1564585351.860177245 gpsd:PROG: PPS:/dev/gps1 Clear rejected this second already handled gpsd:PROG: KPPS:/dev/gps1 assert=C2=A0 1564585352.060170121, sequence: 55= 43,=20 clear=C2=A0=C2=A0 1564585351.860177245, sequence: 5543 - using: assert gpsd:PROG: KPPS:/dev/gps1 Assert cycle:=C2=A0 999974, duration:=C2=A0 199= 992 @=C2=A0=20 1564585352.060170121 gpsd:PROG: PPS:/dev/gps1 Assert cycle:=C2=A0 999974, duration:=C2=A0 1999= 92 @=C2=A0=20 1564585352.060170121 gpsd:PROG: PPS:/dev/gps1 Assert rejected 1Hz trailing edge After stopping the gpsd service and restarting it's finding it difficult=20 to startup again. I attempted with dev.uart.4.pps_mode=3D0x21 for 'narrow= '=20 pulses even though 200ms-1 shouldn't be considered 'narrow'?? I'm guessin= g. Once I understand a little bit more about the behavior and quirks of the=20 setup I'll probably start looking at how to enable an input switch on a=20 GPIO pin then trying to get/write a driver for lcdproc and the Newhaven=20 display. The aim is to use the retractive mechanical switch to change=20 the LCD display from clock to GPS info.... Still lots of work to go but it's definitely a really fun project :-) Regards, Kaya