Re: [chrony-users] Configuring chrony debian service - BBB

[ Thread Index | Date Index | More chrony.tuxfamily.org/chrony-users Archives ]


The PPS line from the AdaFruit Ultimate GPS breakout board does go into a GPIO pin on the BeagleBone Black. The serial Tx/Rx lines from that breakout board go to the UART4 pins on the BeagleBone. There is no 9 or 25 pin connector, just wires. The NMEA sentences come in on /dev/ttyS4 and I have an overlay loaded on the BeagleBone for configuring the GPIO pin used for the PPS. I attached a photo of the setup.

As an experiment I did a systemctl disable gpsd and rebooted. After reboot I did a dmesg | grep pps  Here's what I see:

debian@beaglebone:~$ dmesg | grep pps
[    1.538021] pps_core: LinuxPPS API ver. 1 registered
[    1.538029] pps_core: Software ver. 5.3.6 - Copyright 2005-2007 Rodolfo Giometti <giometti@xxxxxxxx>
[   25.429435] pps pps0: new PPS source ocp:bs_pinmode_P9_12_0x27_pinm
[   25.429551] pps pps0: Registered IRQ 88 as PPS source

So I no longer see pps0 getting assigned to /dev/ttyS4, as it was when I had gpsd enabled. This makes me relatively confident that gpsd at least in part was getting in the way here. Using ppstest shows I am getting the PPS pulses on /dev/pps0. I am going to try to configure chrony to read /dev/ttyS4 directly and see where that takes me.

Thanks again for all the help you have been providing and your patience. I'm by no stretch an NTP/Chrony expert and my Linux/Unix skills are pretty rusty. I know just enough to get myself into trouble.


On Tue, Nov 28, 2017 at 8:47 PM, Bill Unruh <unruh@xxxxxxxxxxxxxx> wrote:
On Tue, 28 Nov 2017, Joe Smith wrote:

I don't know exactly how pps_ldisc is being loaded. Both greps you suggested yielded zero results. I can only guess that it is
part of pps-tools.

No. pps-tools package has about 5 programs which you can use to test the pps,
and one file, timepps.h, which is needed to compile pps support into chrony,
ntpd and gpsd. pps-ldisc module is being loaded by something.
Sorry I misled you. It is the pps-ldisc module, not pps_ldisk. So grep for the
former.

As far as I know you have your pps line from from your gps receiver attached
to a gpio pin, not to the serial port. I a pretty sure you do not have two
separate pps lines from either one or two gps receivers. It is ONLY the pin
that actually has the pps signal that requires a module to time it. pps-ldisc is for the cts pin on the serial port connector carrying the
interrupt. But I suspect that you have a usb connection to bring in the nmea
sentences, not a good old fashioned 9 or 25 pin serial port.

Somethng is loading the pps-ldisc module. You need to find what is doing that.


I was going to try specifying both /dev/ttyS4 and /dev/pps0 in the gpsd config to see if that helps anything.

???? My suspicion is that you should get rid of that ttyS4 entirely as far as
pps is concerned.

Note that you might be automatically loading pps-ldisc in one of the module
files
grep -r pps-ldisc /etc/mod*




On Tue, Nov 28, 2017 at 9:28 AM, Bill Unruh <unruh@xxxxxxxxxxxxxx> wrote:
      See below

      On Tue, 28 Nov 2017, Joe Smith wrote:

            I verified that the configure script does not find libcap. Tried to apt-get install libcap-dev and
            configure again but it still
            doesn't find it. There appear to be a few debian packages out there for libcap but not sure which one it
            needs. I'm not super
            worried if chronyd has to run as root for my particular application.
            I'm not exactly sure how to determine how gps-gpio is loaded. All I know is that I configured
            /boot/uEnv.txt to load overlays
            for the PPS pin and UART4. Then it was just doing apt-get install to get the packages I need. I ran
            dmesg | grep pps and got the
            following:

            [    1.538080] pps_core: LinuxPPS API ver. 1 registered
            [    1.538089] pps_core: Software ver. 5.3.6 - Copyright 2005-2007 Rodolfo Giometti <giometti@xxxxxxxx>
            [   17.288476] pps_ldisc: PPS line discipline registered
            [   17.308702] pps pps0: new PPS source serial4
            [   17.308799] pps pps0: source "/dev/ttyS4" added
            [   26.049624] pps pps1: new PPS source ocp:bs_pinmode_P9_12_0x27_pinm
            [   26.049749] pps pps1: Registered IRQ 88 as PPS source


      OK, things become slightly clearer. Both ttyS4 and your gpio pin are claiming to
      deliver pps to the system, one on /dev/pps0 and the other on pps1. You
      probably do not want the ttyS4 as a pps source (do you even have a serial port
      and is anything plugged into it. You are running pps_ldisc which is the serial port pps module. You must have
      somewhere that you are telling it to run that. I do it in a script, but you
      could have a systemd program doing it (grep -r pps_ldisc /usr/lib/systemd) or do the same for /etc/init.d



            I'm going to try the slow deliberate approach to loading the packages to isolate where the problems
            begin.


            On Tue, Nov 28, 2017 at 3:45 AM, Miroslav Lichvar <mlichvar@xxxxxxxxxx> wrote:
                  On Mon, Nov 27, 2017 at 04:30:27PM -0500, Joe Smith wrote:
                  > Unfortunately chronyd doesn't appear to like that setting. Upon reboot it
                  > complained that dropping root privileges was not supported.

                  That suggests the development files for libcap were missing when
                  chronyd was built. The configure script should print:

                  Checking for libcap : Yes

                  > I rebuilt again
                  > without it but now appear to be encountering other problems, more related
                  > to BBB and debian I think. Seems like I can't seem to predict very well
                  > what device gets assigned for PPS and why. When I started the setup process
                  > the PPS was going to /dev/pps0 as I would expect. Then after my last reboot
                  > it was getting assigned /dev/pps1 and it appears that device isn't ready at
                  > the time chronyd is started by systemd so it has to be started up manually
                  > using systemctl which is a no-go for my application. I posted to the
                  > BeagleBone google group to see if anyone has ideas as to why. I'm
                  > relatively sure it has to do with the startup order from systemd but I'm
                  > not expert enough to know how to remedy it.

                  It might be an ordering issue between starting gpsd and loading of the
                  pps-gpio module. How is the module loaded?

                  I think gpsd tries to attach a PPS of the serial port, like "ldattach 18"
                  would do, and if that happens before the pps-gpio module is loaded,
                  they would have different numbers assigned. But I'm just guessing
                  here.

                  --
                  Miroslav Lichvar

                  --
                  To unsubscribe email chrony-users-request@xxxxxxxxxxfamily.org
                  with "unsubscribe" in the subject.
                  For help email chrony-users-request@xxxxxxxxxxfamily.org
                  with "help" in the subject.
                  Trouble?  Email listmaster@xxxxxxxxxxxxxxxxxxxg.






Attachment: 20171129_091000.jpg
Description: JPEG image



Mail converted by MHonArc 2.6.19+ http://listengine.tuxfamily.org/