Date: Fri, 02 Aug 2019 09:14:33 -0600 From: Ian Lepore <ian@freebsd.org> To: Kaya Saman <kayasaman@optiplex-networks.com>, "freebsd-arm@freebsd.org" <freebsd-arm@freebsd.org> Subject: Re: Pine64-LTS overlays for uart ports fixed! Message-ID: <f06336a817a0c895bc1e2ada9d07c504156b50a4.camel@freebsd.org> In-Reply-To: <0fb22c15-c514-338c-04d0-03ae274e8250@optiplex-networks.com> References: <0fb22c15-c514-338c-04d0-03ae274e8250@optiplex-networks.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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<PU>, caps:<IN,OUT,PU,PD> > > > 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:<IN,OUT,PU,PD> > > I can only guess that it is 'bank 3' <PD range> , 'pin 4' <PD4> , 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?f06336a817a0c895bc1e2ada9d07c504156b50a4.camel>