Hello,
Under the basic premise of having a super accurate NTP server; how best would I time sync the beagle bone black(green)? Currently using the provided debian image.
If I kick off NTPd & GPSd and include a 1PPS over an io as root, what would my expectations be for offset from utc? Would moving OS also help in this scenario? I believe Chrony/NTPd are comparable on their timesync?
The above assumes I am running on the am335x; is it possible to offload the timesync process onto the PRU? I would assume that it could provide a more accurate time and allow for the processor to handle other tasks?
Would writing a custom driver that takes an interrupt (PPS) over IO (is a certain pin best?), reads time from GNS, & sets time w/ an added offset for delay in reading time from GNS be the best solution? Again, would it be better performance if it ran on the PRU?
The linux kernel has a pps driver, which we have activated…
Here is an older example i did with a GNSS-5-CLICK, using tx/rx and pps signal pin…
once you setup the pps signal, follow the rest of this:
for the software stack…
Regards,
Thank you @RobertCNelson; the information is incredibly helpful and reassuring.
I have followed some similar material here: GPSD Time Service HOWTO
In the material I have followed; it has a summary table for typical accuracy.
Am I correct in assuming that the beagle by default has KPPS support enabled and the method you have described would be closer to the ±1uSec rather than the ±5uSec?
My ultimate goal is for the beagle’s systime time to be as close to UTC as possible, preferably below ±1uSec. If I am trying to bring the offset to UTC down lower; do you know of any such method that involves the PRU? Have I missed something by chance? (That happens alot)
Best & Thank you so much!
Hello @RobertCNelson ; I think I got my BBB into a bad state when editing the uEnv.txt file.
I believe I changed the custom cape line to include the click dtbo file that is in …/firmware;
The BBB is now crashing on startup and gets in a loop. I can provide that information here but I suspect that i did not edit the uEnv file correctly and need to reimage the board. I believe that the univerisal cape option may have also been enabled. Not sure if that was the underlying reason for issue? (I think i had previously enabled that on this board)
How should i correctly include the dts file? Was the dtbo file and editing the uEnv the correct path forward?
Side note; I do all this work with my beagle and its image; am I able to make a backup of the emmc and flash other beagles with it?
can you share a serial boot log?
Regards,
@RobertCNelson see attached:
bbb-SERIAL.txt (5.3 KB)
Best & Many thanks
uboot_overlays: [dtb_overlay=/lib/firmware/PB-UART4-GNSS-5-CLICK.dtbo] ...
uboot_overlays: loading /lib/firmware/PB-UART4-GNSS-5-CLICK.dtbo ...
1226 bytes read in 311 ms (2.9 KiB/s)
failed on fdt_overlay_apply(): FDT_ERR_NOTFOUND
PB = PocketBeagle…
For the BeagleBone Black, you’ll need to change these 3 pins… P2_05_uart_pin, P2_07_uart_pin and P2_03_gpio_pin, and then update gpio0 23 and uart4…
fragment@2 {
target = <&uart4>;
__overlay__ {
status = "okay";
pinctrl-names = "default";
pinctrl-0 = <
&P2_05_uart_pin
&P2_07_uart_pin
>;
};
};
fragment@3 {
target-path="/";
__overlay__ {
pps {
status = "okay";
compatible = "pps-gpio";
pinctrl-names = "default";
pinctrl-0 = <&P2_03_gpio_pin>;
gpios = <&gpio0 23 GPIO_ACTIVE_HIGH>;
};
};
};
};
@RobertCNelson Thank you for your time with your response. Admittedly, overlaps/capes have probably been the trickery part for me (besides how to take advantage of the pru).
Using uart4 on the BB;
“P2_05_uart_pin” should be “P9_11_uart_pin”?
Which would make “P2_07_uart_pin” → “P9_13_uart_pin”?
Does using a pwm pin for the pps make sense? I think that pin is a pwm according to diagram.
So would it be like: “&P2_03_gpio_pin” → “&P9_14_ehrpwm1a”?
I plan on downloading your file from github, renaming it to bb-…CLICK.dts applying the above changes, and then compiling with something like “dtc -O dtb -o BB-UART4-GNSS-5-CLICK.dts -b 0 -@ PB-UART4-GNSS-5-CLICK.dts” , does that seem correct?
Am I able to fix the state that my beagle is in or should I re-flash it?
Best
To kinda start over… How are you wiring these two board together… Are you using mikroe’s adapter?
Or bread-boarding it?
Which P8_xy and P9_xy pins are you planning to use?
Regards,
Bread Boarding it.
I was planning on uart4 for the gps RX/TX.
Additionally, I do make use of pins p9_19 & p9_20 (i2c2) along with p9_33 → p9_40 (analog in).
Best & Kind Thanks,
Then i’d start with:
/*
* Copyright (C) 2018 Robert Nelson <robertcnelson@gmail.com>
*
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License version 2 as
* published by the Free Software Foundation.
*
*/
/dts-v1/;
/plugin/;
#include <dt-bindings/gpio/gpio.h>
#include <dt-bindings/pinctrl/am33xx.h>
#include <dt-bindings/interrupt-controller/irq.h>
#include <dt-bindings/board/am335x-bbw-bbb-base.h>
/ {
/*
* Helper to show loaded overlays under: /proc/device-tree/chosen/overlays/
*/
fragment@0 {
target-path="/";
__overlay__ {
chosen {
overlays {
BB-UART4-GNSS-5-CLICK = __TIMESTAMP__;
};
};
};
};
/*
* Free up the pins used by the cape from the pinmux helpers.
*/
fragment@1 {
target = <&ocp>;
__overlay__ {
P9_13_pinmux { status = "disabled"; }; /* uart4_txd */
P9_11_pinmux { status = "disabled"; }; /* uart4_rxd */
P9_14_pinmux { status = "disabled"; };
};
};
fragment@2 {
target = <&uart4>;
__overlay__ {
status = "okay";
pinctrl-names = "default";
pinctrl-0 = <
BONE_P9_13 (PIN_OUTPUT | MUX_MODE6) // gpmc_wpn.uart4_txd_mux2
BONE_P9_11 (PIN_INPUT | MUX_MODE6) // gpmc_wait0.uart4_rxd_mux2
>;
};
};
fragment@3 {
target-path="/";
__overlay__ {
pps {
status = "okay";
compatible = "pps-gpio";
pinctrl-names = "default";
pinctrl-0 = <
BONE_P9_14 (PIN_INPUT | MUX_MODE7)
>;
gpios = <&gpio1 18 GPIO_ACTIVE_HIGH>;
};
};
};
};
Okay, I took the file/dts you provided and as root put it in the firmware directory w/ name “BB-UART4-GNSS-5-CLICK.dts”. Is this the wrong place for dts files?
My compilation attempt is below:
root@beaglebone:/lib/firmware# dtc -O dtb -o BB-UART4-GNSS-5-CLICK.dtbo -b 0 -@ BB-UART4-GNSS-5-CLICK.dts
Error: BB-UART4-GNSS-5-CLICK.dts:13.1-9 syntax error
FATAL ERROR: Unable to parse input tree
root@beaglebone:/lib/firmware#
Any thoughts/recommendations?
Best & Many Thanks,
There’s a makefile in this repo for a reason…
Just copy the file under ./src/arm/
and run:
make
sudo make install
Regards,
Robert,
Updated the bb-org-overlays & added in the file you supplied above in src/arm. Backed up 2 levels, used the make && sudo make install. Added the file to the uEnv.txt and rebooted the device. I am not seeing a pps0 in /dev/ so I wonder if I did something wrong.
here is the output from dmseg;
debian@beaglebone:~$ dmesg | grep pps
[ 0.317829] pps_core: LinuxPPS API ver. 1 registered
[ 0.317838] pps_core: Software ver. 5.3.6 - Copyright 2005-2007 Rodolfo Giometti giometti@linux.it
[ 46.800013] pps-gpio pps: ignoring dependency for device, assuming no driver
[ 46.906949] pps-gpio pps: ignoring dependency for device, assuming no driver
[ 47.020447] pps-gpio pps: ignoring dependency for device, assuming no driver
[ 47.244651] pps-gpio pps: ignoring dependency for device, assuming no driver
[ 49.709550] pps-gpio pps: ignoring dependency for device, assuming no driver
[ 50.449594] pps-gpio pps: ignoring dependency for device, assuming no driver
[ 50.630802] pps-gpio pps: ignoring dependency for device, assuming no driver
[ 50.653597] pps-gpio pps: ignoring dependency for device, assuming no driver
Do you have any thoughts/suggestions? Thank you a million.
Best,
Please post your kernel version and the source of your overlay, something is fishy…
Regards,
Hello Robert,
I think you want something like this:
debian@beaglebone:~$ uname -a
Linux beaglebone 4.19.94-ti-r42 #1buster SMP PREEMPT Tue Mar 31 19:38:29 UTC 2020 armv7l GNU/Linux
Source of overlay?..
This:
bb-cape-overlays::/opt/source/bb.org-overlays$ apt-cache policy bb-cape-overlays
Installed: 4.14.20210821.0-0~buster+20210821
Candidate: 4.14.20210821.0-0~buster+20210821
Version table:
*** 4.14.20210821.0-0~buster+20210821 500
500 http://repos.rcn-ee.com/debian buster/main armhf Packages
100 /var/lib/dpkg/status
or did you mean this?
/dts-v1/;
/plugin/;
#include <dt-bindings/gpio/gpio.h>
#include <dt-bindings/pinctrl/am33xx.h>
#include <dt-bindings/interrupt-controller/irq.h>
#include <dt-bindings/board/am335x-bbw-bbb-base.h>
/ {
/*
* Helper to show loaded overlays under: /proc/device-tree/chosen/overlays/
*/
fragment@0 {
target-path="/";
__overlay__ {
chosen {
overlays {
BB-UART4-GNSS-5-CLICK = __TIMESTAMP__;
};
};
};
};
/*
* Free up the pins used by the cape from the pinmux helpers.
*/
fragment@1 {
target = <&ocp>;
__overlay__ {
P9_13_pinmux { status = "disabled"; }; /* uart4_txd */
P9_11_pinmux { status = "disabled"; }; /* uart4_rxd */
P9_14_pinmux { status = "disabled"; };
};
};
fragment@2 {
target = <&uart4>;
__overlay__ {
status = "okay";
pinctrl-names = "default";
pinctrl-0 = <
BONE_P9_13 (PIN_OUTPUT | MUX_MODE6) // gpmc_wpn.uart4_txd_mux2
BONE_P9_11 (PIN_INPUT | MUX_MODE6) // gpmc_wait0.uart4_rxd_mux2
>;
};
};
fragment@3 {
target-path="/";
__overlay__ {
pps {
status = "okay";
compatible = "pps-gpio";
pinctrl-names = "default";
pinctrl-0 = <
BONE_P9_14 (PIN_INPUT | MUX_MODE7)
>;
gpios = <&gpio1 18 GPIO_ACTIVE_HIGH>;
};
};
};
};
Apologies and my sincerest thanks.
Hello Robert,
I hit a wall on that issue; so I went back a couple of steps. I found another thread that you helped with and I followed along. I had to rearrange some wirings, but it was managable to switch from uart4->uart1 for me. I have a PPS coming into the device but I still have some struggles. It seems the device was not receiving the nmea data from the device or possibly any binary output. GPSMON showed nothing with “/dev/ttyS1” or ttyO1.
I’ve attached the dts, uEnv.txt I am using now along with a cgps output and gpsd warnings for consideration.
DD-GPS-DTS.txt (2.2 KB)
working-uEnv.txt (2.3 KB)
cgps-output.txt (1.8 KB)
gpsd-warnings.txt (821 Bytes)
Same kernel version as before.
Best,
Hmmm,
I had the wrong mode set; i changed a 6->0 and I am getting gpsd to work and can see my lock&info nicely(ish) with cgps.
Best,
Bob
