Jump to content

PPS-GPIO no longer default kernel configuration


windysea

Recommended Posts

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.

 

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

 

Link to comment
Share on other sites

@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 by mute
Premature Enter!
Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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.

 

 

Link to comment
Share on other sites

Guest
This topic is now closed to further replies.
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines