windysea Posted March 26, 2018 Posted March 26, 2018 I have tried searching but there doesn't seem to be much info on PPS support. It is a standard part of modern kernels and should be pretty consistent. On a Pine64+ using mainline kernel (debian-stretch-next) I chose an interrupt-enabled pin (PH9) updated /boot/armbianEnv.txt with overlays=pps-gpio uart1 uart2 param_pps_pin=PH9 and rebooted. I have a device (a GPS) with its PPS output connected to the Pi2 bus pin 13 that corresponds to PH9 and during boot this appears to be configured as a new PPS source: [ 5.548061] pps pps0: new PPS source pps@0.-1 [ 5.548135] pps pps0: Registered IRQ 145 as PPS source /dev/pps0 is indeed created by udev, but unfortunately it never sees any assertions beyond the fist: root@pine64:~# ppstest /dev/pps0 trying PPS source "/dev/pps0" found PPS source "/dev/pps0" ok, found 1 source(s), now start fetching data... time_pps_fetch() error -1 (Connection timed out) time_pps_fetch() error -1 (Connection timed out) time_pps_fetch() error -1 (Connection timed out) ^C root@pine64:~# cat /sys/class/pps/pps0/assert 1478193403.873076084#1 I have confirmed the connected device is raising this line for 10ms every 1000ms using a scope and have confirmed this can be seen via the GPIO pin using 'cat' in a while loop to see the value change to 1 and back to 0 each second. It appears the interrupt is not being raised beyond the initial device creation, which would be the reason pulses are never seen by any clients (such as ppstest) root@pine64:~# egrep 145 /proc/interrupts 145: 1 0 0 0 sunxi_pio_edge 41 Edge pps@0.-1 Would anyone have any thoughts here? I may try the legacy kernel to see if there is any difference.
windysea Posted March 26, 2018 Author Posted March 26, 2018 Hmm. Now this looks interesting (yes it appears I am talking to myself!): root@pine64:~# cat /sys/kernel/debug/gpio gpiochip1: GPIOs 0-255, parent: platform/1c20800.pinctrl, 1c20800.pinctrl: gpio-166 ( |cd ) in lo gpio-201 ( |pps-gpio ) in hi IRQ gpiochip0: GPIOs 352-383, parent: platform/1f02c00.pinctrl, 1f02c00.pinctrl: gpio-354 ( |reset ) out lo Note that 'pps-gpio' is attached to gpio-201 and not the proper gpio-233 (PH9 => gpio-233). Noting the difference is exactly 32 makes it appear the wrong pin bank is being selected ('g' instead of 'h') Now to try to find where this is going wrong. . .but if anyone else has suggestions I'm all ears Edit: Sure enough, without changing anything else I connected the PPS line to the physical pin for PG9 instead of PH9 and now see the PPS assertions. This does look like an off-by-one error so to now find where that is. . . Edit2: Found it!: in u-boot script /boot/dtb/allwinner/overlays/sun50i-a64-fixup.scr pin bank 'H' is assigned value '6' when it should be '7'.
reg.swensen Posted July 19, 2018 Posted July 19, 2018 I'm headed down the same rabbit hole. Since it seems you have already found a working solution to getting PPS up can you tell me which physical pin on the Pine64 board you connected to in order to get PPS working? I have looked on docs for the PG9 pin and only found it on the bluetooth connector. Also it seems to be a 2.5v pin rather than 3.3. My gps board outputs 3.3v and I don't really want to burn up the chip. I was also a bit mystified with your second post's solution where you found the problem in the uboot script. I cannot find an 'allwinner'directory under the /boot/dtb tree so I got lost looking there to follow your lead. Thanks for any light you can provide as there seems to be none in the general area. Reg Swensen
martinayotte Posted July 19, 2018 Posted July 19, 2018 2 hours ago, reg.swensen said: I cannot find an 'allwinner'directory under the /boot/dtb tree First, let's say that overlay directory is only on Mainline kernel, it doesn't exist on Legacy kernel. Secondly, PPS is simply using a GPIO pin, it could be almost any one, as long as it is available on some header. The current overlay is defaulting to PD4 of the Euler Bus. Doing "dtc -I dtb -O dts /boot/dtb/allwinner/overlay/sun50i-a64-pps-gpio.dtbo" will display it in plain text...
reg.swensen Posted July 19, 2018 Posted July 19, 2018 Thanks for the clarification. my newbie is showing. The useful thing though is that it is already supported on the PD4 pin. I'll have a go with that one and see if I can get it working.
Recommended Posts