From owner-freebsd-arm@freebsd.org Fri Aug 2 15:14:39 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 48A50B5575 for ; Fri, 2 Aug 2019 15:14:39 +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 460W0t6K9Vz4B0Z for ; Fri, 2 Aug 2019 15:14:38 +0000 (UTC) (envelope-from ian@freebsd.org) ARC-Seal: i=1; a=rsa-sha256; t=1564758877; cv=none; d=outbound.mailhop.org; s=arc-outbound20181012; b=BCenVL+MNLDW2NeYBnEDWG/MpAWnOfXVvzriDzBXO2bkKYrQKdzRmASFzSWS15s0ycLjxv+OqZXGx A+FcHsSvT77vfIRXIFQaVicKY7xh8ilzJ1a+H9o7OFBYhKZeXuB09YvH6VPemFljDIY2JzOlmlwop5 S9RP2uc6368ddy2mhdAnXz6faMkg3QTYy2PvPDWN2EaOB/V0drIz9kmLnWkqpIrEjKXXteGIiRYtbZ k/cc1XxmygAmI3TxHIJw89UGkxB5WGhnBfsVPPlVztQZXPmWZ6haquvVSroXxEswtuukCt1WIY5LMj uxoDLPZO05w8IJMdiKSBgbBPETA6RkA== 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=KIRX8xinu64DsoRkaB9DkxYCQrxXnUDDA22uxGQsHeg=; b=FnDwKgOcT+P0dS1zcGSa8oPAd4Xy//caOKO+VyKrm5N48dCaURmDs2UbZxP/h1FEr8824KJJS8AdN clCOTuMqekEVKLfakuQmpKsNlzN/rIPHKwH6osGVNP0vPhF2DFPWLgW+00AkeWEm7zxekBD4/QZ6XB g1yj8rxKcsO2BmHy5pfxrcsgG5ckc465FiTRhw4ND1fDlJQhlnFJWX/N5KIb4Fzqsa/o0zSSzNV41M 74tlqfzuNprrGxA326oxyzkHPTdlAfAx6syq4UrAxBbPZg63VksQVnx+0PZHNfOd/B4OF8kGt9KsaB Ii5MvoHZq96HLq4wowT/HB0F8vOEnpg== 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=KIRX8xinu64DsoRkaB9DkxYCQrxXnUDDA22uxGQsHeg=; b=jszPDq/MFScInGSEbT1P/qt9Oicc0axaSIOQkHodo27m1DayvpD7Bnexly575BAwfiOu8lgLGrKhL lPk4ZQSoJA8OnZEiLUzk9b0cxBuw2NvmCA8ORwnqYRYRerr/V00/+oHWxfF1xKsCas//mVH5CnOIvw oLht8832E/C/cypZsrrnzx1OS/gbJlMRj1NFtTLK4QrBxwyxi1N12kQrZ7vHuzgxOG+73Kwj3ghErZ Lno6o6IyjAcVUNO+FzGVg4p3jf/QeTBn9KhomHsLrMmdhO4L77pZ7sNqpWUiutPOeZLA1MzNQ3wHOQ ODrUT3p5YwxGmFxzkRo7DubhgHe8vqw== X-MHO-RoutePath: aGlwcGll X-MHO-User: 3beacde6-b538-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 3beacde6-b538-11e9-85ec-13b9aae3a1d2; Fri, 02 Aug 2019 15:14:36 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.15.2) with ESMTP id x72FEXTe005797; Fri, 2 Aug 2019 09:14:33 -0600 (MDT) (envelope-from ian@freebsd.org) Message-ID: Subject: Re: Pine64-LTS overlays for uart ports fixed! From: Ian Lepore To: Kaya Saman , "freebsd-arm@freebsd.org" Date: Fri, 02 Aug 2019 09:14:33 -0600 In-Reply-To: <0fb22c15-c514-338c-04d0-03ae274e8250@optiplex-networks.com> References: <0fb22c15-c514-338c-04d0-03ae274e8250@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: 460W0t6K9Vz4B0Z X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-0.41 / 15.00]; local_wl_from(0.00)[freebsd.org]; NEURAL_HAM_SHORT(-0.41)[-0.410,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: Fri, 02 Aug 2019 15:14:39 -0000 On Thu, 2019-08-01 at 13:27 +0100, Kaya Saman wrote: > [snip] > > On 7/31/19 5:22 PM, Kaya Saman wrote: > > > > > > > > > > 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). > > > Just found this: > > https://lists.gnu.org/archive/html/gpsd-users/2017-09/msg00031.html > > > Uh, no. lease reread the output. gpsd is accepting the leading edge, and > rejeecting the trailing edge. Just as it should. > > > /Sep 18 23:36:50 k9 gpsd[15453]: gpsd:PROG: KPPS:/dev/ttyS2 assert> / > > /1505777810.100060219, sequence: 8, clear 1505777810.000026753, sequence: 8 / > > /- using: assert/ > > Accepted edge. > > > /Sep 18 23:36:50 k9 gpsd[15453]: gpsd:PROG: PPS:/dev/ttyS2 Assert > > rejected 1Hz / > > /trailing edge/ > > Rejected trailing edge. > > A pulse has two edges. PPS uses the eading one, and ignores the > trailing edge. > > > Looks like it's working properly :-) > > > > > > > > [snip] > > > > > > 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 :-) > > > > > My GPIO file features this: > > > /dts-v1/; > /plugin/; > > / { > compatible = "allwinner,sun50i-a64"; > > fragment@0 { > target = <&pio>; > __overlay__ { > pps_pins: pps_pins { > pins = "PD4"; > function = "gpio_in"; > }; > }; > }; > > fragment@1 { > target-path = "/"; > __overlay__ { > pps@0 { > compatible = "pps-gpio"; > pinctrl-names = "default"; > pinctrl-0 = <&pps_pins>; > gpios = <&pio 3 4 0>; /* PD4 */ > status = "okay"; > }; > }; > }; > }; > > > So in conjunction with reading the example: > > > gpios = <&gpio1 0 GPIO_ACTIVE_HIGH>; /* change this */ > > > If we take the Pi2-bus connector: > http://synfare.com/599N105E/hwdocs/pine64/gpiosgeo.html > > and just use for argument sake pine PC9 as PPS input. > > Using: gpioctl -lv > > the pin number becomes: pin 19: 0 PC9, caps: > > > I'm not sure how to interpret this: gpios = <&pio 3 4 0>; /* PD4 */ > > - as pin PD4 is being registered as: pin 31: 0 PD4<>, caps: > > I can only guess that it is 'bank 3' , 'pin 4' , there > for the line would need to be changed to: > > gpios = <&pio 3 4 0>; -> gpios = <&pio 2 9 0>; Possibly?? <- ok just > tested and it's not working :-( > > > Ian, I think I ran in to an issue with the CTS. It might be exactly as > you mentioned in that the uart port maybe trying to use it for something > else?? I disabled flow control using stty for both cuau4.init and > > > Best Regards,> > > > > > > > Kaya> > > > > _______________________________________________> > freebsd- > arm@freebsd.org mailing list> > > https://lists.freebsd.org/mailman/listinfo/freebsd-arm>; > To > unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org"> > > > ttyu4.init. The interesting thing here is that with the GPS PPS plugged > in I get 'PPS time out' messages, if I move the PPS wire to a different > ping (a GPIO pin for example) then re-plug it back into the uart4 CTS > pin it works? > > > ---- 3rd send attempt; have just contacted @Postmaster about the > issue > and seems like there is an issue so if anyone else is having issues > sending to the list it is being worked on currently :-) -> just an > FYI :-) > > > When gpio pins are banked and a single device instance handles all the banks, which appears to be your case, then it's device-specific how gpioctl maps bank+pin to a linear pin number. I would make the same guesses you did. Or I would look at the driver code, but I don't even know what driver is involved there. One thing to check is to make sure nothing else is trying to configure the PC9 pin if that's the one you chose for gpio-pps input. I created that problem for myself last night while setting up a test... I wrote an overlay that reassigned a given pin as a gpio input, but forgot that elsewhere in the dts that pin was assigned to an sdcard slot. So during kernel init the pin was first getting set to my gpio input, then later when it got to the sd device's pins it got reassigned back to an output. Easily fixed by adding a status = "disabled" for the sd device once I remembered it was there. Another thing I ran into... I wanted to test using CTS as the pps input on an imx6 board, and it wasn't working. Eventually I figured out that the uart driver for imx6 just doesn't support rts/cts signals at all. Doh! So your efforts to use CTS could be running into something like that; I suspect imx6 isn't the only arm uart driver that's basically a 3-wire driver. -- Ian