I am adding the dts file of am335x-boneblack.dts to make the pps work with the kernel but I have this error when I compile the dts files. Any help @RobertCNelson @silver2row @BobTheBuilder ?
Thank you,
Rony Vargas.
I am adding the dts file of am335x-boneblack.dts to make the pps work with the kernel but I have this error when I compile the dts files. Any help @RobertCNelson @silver2row @BobTheBuilder ?
Below is DMESG after insmod the k-module for pps generation.
[ 1099.931732] pps_gen_gpio: loading out-of-tree module taints kernel.
[ 1099.939595] GPIO PPS signal generator
“Show-pins” is now giving me:
P9.16 19 fast rx down 7 gpio 1.19 lo >> pps-gen (pinmux_pps_gen_pins)
which looks right when compared to:
P9.26 96 fast rx 0 uart 1 rxd serial@48022000 (pinmux_bb_uart1_pins)
P9.24 97 fast 0 uart 1 txd serial@48022000 (pinmux_bb_uart1_pins)
The DTS file I am using is similar to the one Rony has posted for robert. I lack the
status = “okay”;
in the pps-gen / pps_gen fragment (Not sure proper naming convention for this param, github’s or Rony’s?).
I made a small edit and ensured that “make” & “make install” ran. The new DD-GPS-00A0-2 .dtbo file from the dts file
DD-GPS-00A0-2.dts (2.2 KB)
@rony_vargas besides reviewing your linux headers as previously mentioned, i’d check the device tree and if you got your pins setup correctly sir.
Best,
a simple builder
1 Like
Hello Rony,
Seth here. I have found little and tried a bit less than I would have liked thus far. There are some kernel related dtbo files that can be built into kernels if building outside of what the BBB persons are building in their kernel.
There is also a new git.beagleboard.org site I found via this forum. They have some Device-Tree ideas.
Right now, I am not sure whether you need to build in the kernel, u-boot, or if beagleboard.org persons have already made some .dts files to alter for your use. I am sorry. I have fallen aside.
Seth
Hi, I am interested in this aswell. Has somebody got it working in the meantime?
1 Like
Rony, Seth here. Okay…so it seems that if allowed via the DTS and beagleboard.org persons, PPS should work. I found this in the kernel docs: PPS - Pulse Per Second — The Linux Kernel documentation .
Seth
P.S. I have not tried this idea yet but it seems it is plausible. I will try to find time. I cannot promise anything.
Also…there is another page on this forum regarding PPS in the kernel.
Update
Okay…so. pps-ktimer is not found by modprobe. This means it is not installed via sysfs for now for whatever reason. Since we are dealing w/ actual hardware and the source files need to be installed alongside sysfs, one would have to bundle it w/ a new build?
Reviewing the kernel docs gives some inclination on how to install pps-tools via a package manager (apt and it works) but I am new to pps-tools. I will learn some more…
Another Update
Look here and it has armhf availability. Try it. I will try it later… Enjoy! Oops. Here: GitHub - redlab-i/pps-tools: User-space tools for LinuxPPS
Why do this in a kernel module? If the sum total of the requirements are that it come from the bbb platform over a gpio header, why not use one of the pru?
I don’t know how accurate this pulse needs to be, but aren’t even kernel modules subject to interrupt delays?
sorry if I missed where the requirements specify a kernel module
gomer
I got the option of the pps-generator, that @RobertCNelson pointed out earlier, somewhat working on the beaglebone black on a custom 5.10.162 Kernel . But it s not very consistent. Nearly every 5-10th Pulse goes missing. Sometimes even every 3rd.
I can share the exact steps to build the custom kernel, adding the driver and adding the overlay for the specified pin, if anyone needs that. But in essence, I put the files from damon-kwok into the correct places in BB-Kernel, build the driver as a module(I had some problems when it was build into the kernel), replaced the boot Image with the new build Image and added a Device Tree Overlay. The devicetree overlay seems to autoload the pps-gen module when booting.
I stumbled upon another repo by damon-kwok that seems to be based of jsln.
The main difference I saw is that the time was changed from “timespec” to “timespec64” and instead of “getnstimeofday” “ktime_get_real_ts64” is used. I am not very versed in kernel drivers and don’t know the difference. The only reason I used damon-kwok’s repo is that I saw his first.
I am using a GPS module to generate and synchronize the BBB with Chrony. The time difference between the GPS Pulse and the generated Pulse is ~150us . Depending on your application this might already be enough.
For this I had to compile the pps-generator driver into the Kernel. So using the “normal” Kernel image provided by BeagleBone is not an option. Additionally, I created an Device Tree Overlay that can be loaded to use the driver, instead of editing another device tree file, like it is done in damon-kwok. The overlay file is here BB-BONE-P9_16-PPS-GEN.dts (1.3 KB)
I also tried to use this driver on the BeagleBone AI64 but there it does not seem to work properly.
I have appended some images from my oscilloscope so you can see the difference between the Generated PPS Signal (Channel 1 yellow) and the PPS-Signal from the Module (Channel 2 blue).
Unsychonized:
-
Remark that the 5th. pulse is missing. The driver prints “We are late this time[…]” to dmesg everytime this happens. Maybe someone can a have look at the driver. I am trying to see if this can be resolved aswell.
Synchronized:
But when the PPS is generated it works okay. The pulsewidth may need to be adjusted in the driver.
Update
Currenlty, I have experienced some problems using the current pps-gen driver. BeagleBone-Black crashes when restarting chrony.service when using custom kernel - #3 by benedict.hewson
There is a workaround if you encounter the same errors, described in the thread above.
Removing the pps_gen_gpio kernel module before restarting chrony and once chrony is up an running reinsterting the module works aswell.
Update 2
I have the same setup running on BB-AI64. Here the generated PPS-Pulse is way more consistent and closer to the original pps of the gps module. Probably because of the higher computional power. But sometimes some pps signals are lost but way less than with the BBB. A custom kernel is required here aswell. I made another Device Tree Overlay for the BeagleBone AI64:
BBAI64-P9_16-PPS-GEN.dts (814 Bytes)
Another problem popped up here: I had to remove and reinsert the pps_gen_gpio module in order to receive the generated PPS Signal. The signal is generated shortly after boot, but stops after ~4 seconds.
The following pictures show 2 PPS signals from two seperate gps-modules (Channel2 green and Channel4 blue) and both generated pps signals from BBB(Channel1 yellow) and BBAI64(Channel3 purple).
And just for the sake of completness: The time difference from the two gps pps signals. Only roughly 90ns!
The driver needs some love but in principle works fine.
1 Like
the history log below creates what appears to be a 10% 1PPS. Even using the pru is overkill. Where is it written that this effort requires a kernel module?
501 config-pin -q P9.22
502 config-pin -a P9.22 pwm
503 config-pin -q P9.22
504 cd /sys/class/pwm
505 ls
506 echo 0 > pwmchip1/export
507 ls
508 cd pwm-1:0
509 ls
510 cat *
511 sudo sh -c “echo 1000000000 > period”
512 sudo sh -c “echo 100000000 > duty_cycle”
513 sudo sh -c “echo 1 > enable”
gomer
is this synchronized to the system time or does this create the pps signal “anytime”?
certainly not synchronized to anything. Thanks for clearing up the requirements, now I can sleep
gomer
1 Like
I just wanted to share a link to a forked repo for the gps-pps-gpio driver which includes the instructions for my previous post: GitHub - NotAGnelf/pps-gen-gpio: Linux kernel PPS generator using GPIO pins