Date: Fri, 2 Aug 2019 20:09:11 +0100 From: Kaya Saman <kayasaman@optiplex-networks.com> To: Ian Lepore <ian@freebsd.org>, "freebsd-arm@freebsd.org" <freebsd-arm@freebsd.org> Subject: Re: Pine64-LTS overlays for uart ports fixed! Message-ID: <3e2688d9-0a13-5ecd-8495-ce947c7b176b@optiplex-networks.com> In-Reply-To: <f06336a817a0c895bc1e2ada9d07c504156b50a4.camel@freebsd.org> References: <0fb22c15-c514-338c-04d0-03ae274e8250@optiplex-networks.com> <f06336a817a0c895bc1e2ada9d07c504156b50a4.camel@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 8/2/19 4:14 PM, Ian Lepore wrote: > 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, seque= nce: 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 signa= l, >>>> 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 hardwa= re, >>>> but you can probably find an example of that. The dts source to ena= ble >>>> a gpio pin for pps is: >>>> >>>> / { >>>> pps@0 { >>>> compatible =3D "pps-gpio"; >>>> pinctrl-names =3D "default"; >>>> pinctrl-0 =3D <&pinctrl_pps0>; >>>> gpios =3D <&gpio1 0 GPIO_ACTIVE_HIGH>; /* change this */ >>>> status =3D "okay"; >>>> }; >>>> }; >>>> >>>> The gpios=3D property will need to refer to the right bank and pin n= umber >>>> 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 sam= e >>> case with FreeBSD. Virtually what happened was that setting the pin i= n >>> the loader didn't take effect. >>> >>> >>> Thanks again Ian :-) >>> >>> >> My GPIO file features this: >> >> >> /dts-v1/; >> /plugin/; >> >> / { >> compatible =3D "allwinner,sun50i-a64"; >> >> fragment@0 { >> target =3D <&pio>; >> __overlay__ { >> pps_pins: pps_pins { >> pins =3D "PD4"; >> function =3D "gpio_in"; >> }; >> }; >> }; >> >> fragment@1 { >> target-path =3D "/"; >> __overlay__ { >> pps@0 { >> compatible =3D "pps-gpio"; >> pinctrl-names =3D "default"; >> pinctrl-0 =3D <&pps_pins>; >> gpios =3D <&pio 3 4 0>; /* PD4 */ >> status =3D "okay"; >> }; >> }; >> }; >> }; >> >> >> So in conjunction with reading the example: >> >> >> gpios =3D <&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 =3D <&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> , ther= e >> for the line would need to be changed to: >> >> gpios =3D <&pio 3 4 0>; -> gpios =3D <&pio 2 9 0>; Possibly?? <- ok ju= st >> 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 somethi= ng >> 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 plugge= d >> in I get 'PPS time out' messages, if I move the PPS wire to a differen= t >> 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 =3D "disabled" for the sd devi= ce > 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 > > Initially I performed a few tests on gpio just to see if the OS pin=20 mappings correlated to the the actual mappings. Starting with gpioctl -lv - I got a listing of all the pins; great ;-) pin 19:=C2=A0=C2=A0=C2=A0 0=C2=A0=C2=A0=C2=A0 PC9<PU>, caps:<IN,OUT,PU,PD= > pin 20:=C2=A0=C2=A0=C2=A0 0=C2=A0=C2=A0=C2=A0 PC10<PU>, caps:<IN,OUT,PU,P= D> pin 21:=C2=A0=C2=A0=C2=A0 0=C2=A0=C2=A0=C2=A0 PC11<PU>, caps:<IN,OUT,PU,P= D> pin 22:=C2=A0=C2=A0=C2=A0 0=C2=A0=C2=A0=C2=A0 PC12<PU>, caps:<IN,OUT,PU,P= D> pin 23:=C2=A0=C2=A0=C2=A0 0=C2=A0=C2=A0=C2=A0 PC13<PU>, caps:<IN,OUT,PU,P= D> pin 24:=C2=A0=C2=A0=C2=A0 0=C2=A0=C2=A0=C2=A0 PC14<PU>, caps:<IN,OUT,PU,P= D> pin 25:=C2=A0=C2=A0=C2=A0 0=C2=A0=C2=A0=C2=A0 PC15<PU>, caps:<IN,OUT,PU,P= D> pin 26:=C2=A0=C2=A0=C2=A0 0=C2=A0=C2=A0=C2=A0 PC16<IN>, caps:<IN,OUT,PU,P= D> Then I tried to assign PC9 and PC16 which are adjacent as output pins.=20 As I don't have a multimeter on hand or CRO I used the next best thing,=20 a 5v LED. Using jumper cables I coupled the LED between PC9 first and=20 GND. Then ran: gpioctl -c 19 OUT observe output using -lv and yes it has changed. Afterwards I tried to=20 set the pin to a 'high' level: gpioctl 19 1 LED illuminates. Fantastic! Same procedure for pin 26 too. Satisfied=20 that the pin numbers are correct and mapped properly I then looked at=20 connecting a switch. First set pin 26 to IN. Connect switch between GND=20 and PC16. Press button and observe output of pin... nothing. Ok fine, it=20 is waiting for a state change and is already at 0 doh! Let's attempt to=20 invert the behavior: gpioctl -c 26 II -> no change, nothing is working. Aaaah but there is a 3.3v output header on the board so let's try that=20 instead of GND and bang waddya know.... state change from 0 to 1 whoohoo=20 :-) :-) Next thing is just simply tying the pin to Lcdproc which shouldn't be=20 too difficult. for reference to GPIO I found this=20 (https://vzaigrin.wordpress.com/2014/04/18/working-with-gpio-on-raspberry= -pi-with-freebsd/) Something interesting I found out. It seems at the initialization=20 (startup) stage that the TTL -> RS232 shifter is going high on the CTS=20 pin. This is the reason why my PPS signal is not being detected. If I=20 power down the board and remove the PPS jumper wire from the CTS header=20 then power up and start GPSD as normal, then insert the PPS jumper back=20 into the CTS pin it functions fine. Accuracy is also very good: # ntpq -p =C2=A0=C2=A0=C2=A0=C2=A0 remote=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 refid=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 st t when poll rea= ch=C2=A0=C2=A0 delay offset=C2=A0=20 jitter =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D =C2=A0SHM(0)=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 .NMEA= .=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 0 l=C2=A0=C2= =A0 12=C2=A0=C2=A0 16=C2=A0 377=C2=A0=C2=A0=C2=A0 0.000 -31.383=C2=A0=20 16.450 *SHM(1)=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 .PPS.=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 0 l=C2=A0=C2= =A0 11=C2=A0=C2=A0 16=C2=A0 377=C2=A0=C2=A0=C2=A0 0.000 -0.004=C2=A0=C2=A0= 0.002 Here I need to do one of two things; 1. set the CTS pin to disabled in=20 FreeBSD until the PPS signal starts pulsing then enable it - or - 2.=20 introduce a mechanical switch into the signal path to manually=20 enable/disable the PPS signal. Testing with my trusty LED, at startup the voltage on the RS232-TTL=20 shifter is at a constant high, ie. LED is on. After a while it will=20 start to pulse. Hence my thoughts above. Perhaps " Easily fixed by adding a status =3D "disabled" for the sd device once I remembered it was there. " is what I'm looking for? Where is this set? Regards, Kaya
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3e2688d9-0a13-5ecd-8495-ce947c7b176b>