Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 1 Aug 2019 13:27:01 +0100
From:      Kaya Saman <kayasaman@optiplex-networks.com>
To:        "freebsd-arm@freebsd.org" <freebsd-arm@freebsd.org>
Subject:   Re: Pine64-LTS overlays for uart ports fixed!
Message-ID:  <0fb22c15-c514-338c-04d0-03ae274e8250@optiplex-networks.com>

next in thread | raw e-mail | index | archive | help

[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, i=
n
>> 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, an=
d
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=20
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.=C2=A0 You might need to add a symlink from /dev/gpiopp=
s0 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.=C2=A0 The dts source to =
enable
>> a gpio pin for pps is:
>>
>> / {
>> =C2=A0=C2=A0=C2=A0=C2=A0pps@0 {
>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 compatible =3D "pps-gpio";
>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 pinctrl-names =3D "default"=
;
>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 pinctrl-0 =3D <&pinctrl_pps=
0>;
>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 gpios =3D <&gpio1 0 GPIO_AC=
TIVE_HIGH>; /* change this */
>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 status =3D "okay";
>> =C2=A0=C2=A0=C2=A0=C2=A0};
>> };
>>
>> The gpios=3D property will need to refer to the right bank and pin num=
ber
>> for that hardware.
>>
>> -- Ian
>>
>
> This might work better. I'll have a go later today. I did have issues=20
> while trying things out on Armbian so I don't know if it will the same=20
> case with FreeBSD. Virtually what happened was that setting the pin in=20
> the loader didn't take effect.
>
>
> Thanks again Ian :-)
>
>
> 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"


My GPIO file features this:


/dts-v1/;
/plugin/;

/ {
 =C2=A0=C2=A0=C2=A0 compatible =3D "allwinner,sun50i-a64";

 =C2=A0=C2=A0=C2=A0 fragment@0 {
 =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 target =3D <&pio>;
 =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 __overlay__ {
 =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 pps_pins: pps_p=
ins {
 =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=
=A0 pins =3D "PD4";
 =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=
=A0 function =3D "gpio_in";
 =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 };
 =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 };
 =C2=A0=C2=A0=C2=A0 };

 =C2=A0=C2=A0=C2=A0 fragment@1 {
 =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 target-path =3D "/";
 =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 __overlay__ {
 =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 pps@0 {
 =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=
=A0 compatible =3D "pps-gpio";
 =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=
=A0 pinctrl-names =3D "default";
 =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=
=A0 pinctrl-0 =3D <&pps_pins>;
 =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=
=A0 gpios =3D <&pio 3 4 0>; /* PD4 */
 =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=
=A0 status =3D "okay";
 =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 };
 =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 };
 =C2=A0=C2=A0=C2=A0 };
};


So in conjunction with reading the example:


gpios =3D <&gpio1 0 GPIO_ACTIVE_HIGH>; /* change this */


If we take the Pi2-bus connector:=20
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:=C2=A0=C2=A0=C2=A0 0=C2=A0=C2=A0=C2=A0 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:=C2=A0=C2=A0=C2=A0 0 PD4<>, c=
aps:<IN,OUT,PU,PD>

I can only guess that it is 'bank 3' <PD range> , 'pin 4' <PD4> , there=20
for the line would need to be changed to:

gpios =3D <&pio 3 4 0>; -> gpios =3D <&pio 2 9 0>; Possibly?? <- ok just=20
tested and it's not working :-(


Ian, I think I ran in to an issue with the CTS. It might be exactly as=20
you mentioned in that the uart port maybe trying to use it for something=20
else?? I disabled flow control using stty for both cuau4.init and=20
ttyu4.init. The interesting thing here is that with the GPS PPS plugged=20
in I get 'PPS time out' messages, if I move the PPS wire to a different=20
ping (a GPIO pin for example) then re-plug it back into the uart4 CTS=20
pin it works?


---- 3rd send attempt; have just contacted @Postmaster about the issue=20
and seems like there is an issue so if anyone else is having issues=20
sending to the list it is being worked on currently :-) -> just an FYI :-=
)


Regards,


Kaya




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?0fb22c15-c514-338c-04d0-03ae274e8250>