GPS and Gl.iNet AR150 No PPS Line

For Developers
1

Hello,
Hoping this is the right forum to post to, if not please let me know where I should post this.

I have pulled LEDE from git and I have been attempting to build firmware for the AR150 travel router. I need PPS support because I have a GPS I am trying to use for accurate time keeping. I was using OpenWRT but the switch from LEDE to OpenWRT seems to have changed something (it was a build from early 2016)

Under Kernel I enabled Device Drivers -> PPS -> Support, PPS line, PPS client, PPS kernel

Under Config I enabled as build-in all the kmod-pps* modules.

I also applied the patch.

For the most part, it compiles without any issues, but I get no further information about the PPS line, nor do I get a PPS /dev/ device. What is going on here and what can I do to further test this and get it working again?

2

Which GPS module do you use?
Most modules do not have PPS output.

3

Hello,
I'm using the MTK3339 module for GPS, it has PPS exposed

4

Bit more information, the patch and reference path modify the mach-gl-inet file
Adding logging, but it never seems to print anything.

5

Thought I might add my own 2c here cause im the author of that original patch.

I would be highly supprised if it worked beyond the 4.1 kernels. The original work was based on the gpio intterrupt patch that was written by someone else and never got ported beyond 4.1... eventually the interrupt patch was re-merged back into the mainline linux kernel and is now in LEDE, but my gpio/pps patch wouldn't work with it... However, as luck would have it, I too have an AR150 and did some work to get the AR150 working with a 4.1 kernel (on openwrt) so i could have all that I needed. At some point in the future, i'll redo my gpio/pps patch (from what I can tell no one has added gpio/pps support for the AR9331 beyond 4.1 in the actual kernel?).. In tthe meantime, if all your after is gpio/pps support on the AR150, i have a firmware here: https://github.com/takigama/glinet_ar150_gps_daughterboard/tree/master/openwrt-firmware but it assumes the pps line is gpio 14 (hard coded), and has most of the tooling required to work (gpsd, chrony, ntpd and some linuxptp stuff that wont as yet work) but make sure you disable the serial console.

Theres also my fork of that firmware here, https://github.com/takigama/openwrt-ar150-gps-pps-timeserver (switch to the ar150-gps-pps branch)

6

Oh hey! Thank you for finding this and replying, your original work was why I tried getting this working on the AR150 in the first place. My understanding is limited, but pps-gpio is still available but the special customizations added it in the and around the __init are just not triggering. I'll look more closely this weekend but I appreciate you replying after all this time.

7

its actually both more and less complicated... the whole dev tree was re-written after 4.1 (hence why my firmware is based on 4.1) and then later they re-merged the interrrupt patch for the ar9331... however the pps-gpio code is now more generic, and so adding support for the ar9331 should be a lot easier, just a case of added some lines to the dtsi (as far as i can tell)...

havent had the chance to actually do that myself, but i think should be fairly trivial... from what i can tell, the lede code base should have everything needed.. if i get a chance on the weekend i'll have a mess around with it.

I did manage to have a quick look a short time ago, and the one thing i was expecting to see (but couldn't find) was the RPI's implementation of this as my original patch is based on the pps-gpio code for RPI.

A good example is possibly this one: https://github.com/torvalds/linux/blob/master/arch/arm/boot/dts/imx6qdl-gw54xx.dtsi you can see a pps devtree entry in here. Again tho, i've only briefly re-read up on this, so i may be missing something there

8

Im hoping someone in the know might be able to give me some hints for moving forward... after much tracing thru the kernel I can see now where the newer platform agnostic interfaces into the kernel all tie in... I can see where platforms like the ath79 platform are trying gpio's to interrupts.. in fact the gpio interrupt code seems now to be quite well integrated into the rest of how the platform interrupts are generated. The plus is its all dynamic and comes together well... but in the older 4.1 kernels, the gpio_to_irq (and associated functions) where very platform specific (ad-hoc), these are now consumed into platform agnostic ones...

From what I can tell the code that ties the gpio's to IRQ's generates a bunch of data that should get to the new gpio consumer interface... but it doesnt... obviously in this particular platform (for the pps-gpio driver) it call's gpio_to_irq to find the interrupt it needs but the data that gpio_to_irq (actually legacy code which calls gpiod_to_irq) relies on simply isnt there...

As a hack, i've got a work around for that in tthe pps-gpio code until I can figure out how to get the information generated in linux/drivers/gpio/gpiolib.c and linux/kernel/irq/irqdomain.c. The irq_find_mapping was quite useful here as it ultimately gets called when the irq's are being mapped...

What I cant figure out on the ath79 platform (and cant see in other platforms) is how the gpio descriptor interaces get their data populated or how thats supposed to work. Would love to write a patch to complete that loop if anyone can point me in the right directiion.

9

Update (cause i cant reply to this post anymore):

Ok, so after a fair amount of testing, i now have two firmwares i'm pretty happy with (one based on lede git and the other on openwrt git)... read the readme, but https://github.com/takigama/glinet_ar150_gps_daughterboard/tree/master/openwrt-firmware is where they are.

Once i figure out which doco for submitting patches to openwrt is correct, i'll submit the main patch for upping the irq count and added the pps info for the AR150