PPS-GPIO no longer default kernel configuration

[windysea]

After a recent (long overdue) update on my pine64 I found that pps-gpio was no longer working.  Further investigation found that the default kernel configuration with 4.19.x no longer includes CONFIG_PPS_CLIENT_GPIO (nor CONFIG_PPS_CLIENT_LDISC).  Anyone wishing to use pps-gpio (via overlay) will need to configure and build a custom kernel.

 

user@pine64:~$ cat /etc/armbian-release 
# PLEASE DO NOT EDIT THIS FILE
BOARD=pine64
BOARD_NAME="Pine64"
BOARDFAMILY=sun50iw1
VERSION=5.76.190218
LINUXFAMILY=sunxi64
BRANCH=next
ARCH=arm64
IMAGE_TYPE=nightly
BOARD_TYPE=conf
INITRD_ARCH=arm64
KERNEL_IMAGE_TYPE=Image

user@pine64:~$ uname -a
Linux pine64 4.19.25-sunxi64 #5.76.190310 SMP Sun Mar 10 16:22:07 CET 2019 aarch64 GNU/Linux

user@pine64:~$ gzip -d < /proc/config.gz | egrep -i pps
CONFIG_PPS=y
# CONFIG_PPS_DEBUG is not set
# PPS clients support
# CONFIG_PPS_CLIENT_KTIMER is not set
# CONFIG_PPS_CLIENT_LDISC is not set
# CONFIG_PPS_CLIENT_GPIO is not set
# PPS generators support

 

This appears to likely be from upstream changes in default kernel config options, though I haven't investigated this yet.

 

Would it be possible to re-add these to the default armbian configurations (CONFIG_PPS_CLIENT_LDISC and CONFIG_PPS_CLIENT_GPIO)?  I can look to submitting a pull request with the needed changes if needed.

 

[martinayotte]

13 hours ago, windysea said:

I can look to submitting a pull request with the needed changes if needed.

If you provide a PR, it will be there faster ...

 

[windysea]

I figured that so I'll work on it.

 

I'll review the upstream changes to make sure there isn't a specific reason if that is where this change happened.

 

I also now have a conflict between pinctrl and pps that didn't happen with the 4.14.y kernel so want to identify and (hopefully) correct that first.

[windysea]

Well, this went way off into the woods far too quickly

 

I'll need to spend time reviewing the upstream (linux mainline) changes to see what changed.  For now 4.19.y here on a pine64+ is not suitable for PPS nor is it suitable for an NTP reference clock from what I've been able to work out so far:

• Changing the kernel timer (General -> timers)  to a constant rate (not any dyntick configuration) results in an unstable system that ultimately freezes hard.  This is only needed to enable CONFIG_NTP_PPS (IE: use "hardpps", aka kernel-discipline PPS) so will be set aside for now.
• Using a standard serial GPS via GPIO on a pine64 results in significant delays (as much as 1/10 second) reading the NMS sentences, with extremely high jitter.  Jitter is two orders of magnitude higher (100x worse) than with 4.14.y kernel using the same configuration on the same board.
  • This itself indicates something may not be right with this kernel on this board
• Without PPS, the above has no possibility of being tamed.

Using the default kernel config, and simply enabling CONFIG_PPS_CLIENT_GPIO (via the standard kernel configuration 'make config' as part of compile.sh) results in a boot:

[    1.286759] pps_core: LinuxPPS API ver. 1 registered
[    1.286773] pps_core: Software ver. 5.3.6 - Copyright 2005-2007 Rodolfo Giometti <giometti@linux.it>
[    6.199310] sun50i-a64-pinctrl 1c20800.pinctrl: pin PH9 already requested by pps@0; cannot claim for 1c20800.pinctrl:233
[    6.218536] pps-gpio pps@0: failed to request GPIO 233
[    6.223806] pps-gpio: probe of pps@0 failed with error -22

 

No kernel pps device is ever created.

 

Before digging in to the PPS issue, I want to review the mainline commits.  Previously PPS itself was configured as a module, but now it is only configurable as a built-in so something else there may have changed.  I may also give 4.20.y a try.

 

[mute]

@windysea, Did you end up getting anywhere with this? I ran into issues with running GPSd on 3.16, so I gave Armbian a shot but the lack of PPS support makes this a non starter for my use case. I've had no luck finding a workaround so far.

 

Edited March 28, 2019 by mute
Premature Enter!

[windysea]

You can build a new kernel with the option for now.  The option via "make menuconfig" (done automatically by compile.sh if you set KERNEL_CONFIGURE=yes) is under Device Drivers -> PPS support.  You'll want to enable 'PPS client using GPIO'

 

However I seem to be hitting a conflict when the pps-gpio module is loaded so I haven't submitted a PR for this to go back to enabled-by-default yet.  I found some details that might be relevant and hope to get to this soon.

[mute]

Gotcha. I tried building a new kernel but as you mentioned it's not creating the device. I went down the rabbit hole of trying to mess around in the device tree to see if I could get it to work to no avail, but after reading a bit more I'm wondering if we're going to need this patch (or something along these lines): https://github.com/hardkernel/linux/pull/207/commits/fed321e2788aadd81557f862133702c09d744afc

[mute]

(I should mention I am using an Odroid C2, not a Pine64)

[windysea]

To circle back and follow-up on this thread. . .

 

As of today all of the Armbian default kernel configurations now include pps-gpio as a module by default so no custom kernel builds will be required.  Simply configuring 'overlay=pps-gpio' in /boot/armbianEnv.txt will make this available.  Optionally param_pps_* may be used to configure, such as pin.  You'll need to wait for the next nightly builds if you don't want to actually build a kernel.

 

I had also identified the issue with the pin conflict (as I suspected above) and dug into the root cause further before submitting a PR to have it corrected.  This is already in the existing nightly builds for -DEV so this is resolved as well.  This appeared to only affect Allwinner A64 boards such as Pine 64 and should not be relevant for your Odroid C2.

 

I am currently using PPS once again on my PineA64+ successfully.