Pine64-LTS overlays for uart ports fixed!

[Kaya Saman]

[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 at 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 :-)
>
>
> Best Regards,
>
>
> Kaya
>
> _______________________________________________
> freebsd-arm at freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-arm
> To unsubscribe, send any mail to "freebsd-arm-unsubscribe at freebsd.org"


My GPIO file features this:


/dts-v1/;
/plugin/;

/ {
     compatible = "allwinner,sun50i-a64";

     fragment at 0 {
         target = <&pio>;
         __overlay__ {
             pps_pins: pps_pins {
                 pins = "PD4";
                 function = "gpio_in";
             };
         };
     };

     fragment at 1 {
         target-path = "/";
         __overlay__ {
             pps at 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 
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 :-)


Regards,


Kaya