I have what I think is a working DTS as the UART is working fine but I cannot get the system to read the PPS from a GPS unit I have connected.
Below is my DTS and the UART 4 is working fine and I have the GPS’s PPS connected to P8-26 and so I’m hoping my DTS puts it into Mode7 on that pin.
PPS support is inside my kernel
Any ideas at all?
Lee
/*
I have what I think is a working DTS as the UART is working fine but I cannot get the system to read the PPS from a GPS unit I have connected.
Below is my DTS and the UART 4 is working fine and I have the GPS's PPS connected to P8-26 and so I'm hoping my DTS puts it into Mode7 on that pin.
PPS support is inside my kernel
Any ideas at all?
I haven't specifically tried PPS through devicetree yet, however..
gps_pps_pins: pinmux_gps_pps_pins {
pinctrl-single,pins = <0x7c 0x27 /* P8.26 gpio1_29 */
>;
and
pps {
compatible = "pps-gpio";
status = "okay";
pinctrl-names = "default";
pinctrl-0 = <&gps_pps_pins>;
gpios = <&gpio2 7 0 >;
assert-rising-edge;
};
are using two different gpio pins. You're setting the pinmux for gpio1_29 then telling pps-gpio to use gpio2_7
Also you should be aware that this will depend on which kernel version you're using.
Some kernels have the &gpio2 reference off-by-one which means that:
0x7c 0x27 /* P8.26 gpio1_29 */ would be referred to as &gpio2 29 as someone ignored the docs which use gpio0,gpio1,gpio2,gpio3 and called them 1-4 instead..
That's fixed in other kernels, but it does mean that your overlay needs to be different for each kernel. Similar off-by-one problems exist elsewhere in the BBB dts, so it's sometimes wise to use dtc to decompile the main dtb and backtrace the references to see if it's really referring to what you think it is!
Ah ok, I do actually mean to use P8.26 which I think is GPIO1_29.
I am using a 3.8 kernel, any way to check at all if it is fixed or not as well?
It's not a kernel issue as such, it's the way the devicetree has been written.
Yes, P8.26 is gpio1_29 in the am3359 datasheet and it corresponds to:
pinctrl-single,pins = <0x7c 0x27 /* P8.26 gpio1_29 */
0x7c is what tells you that - the register address for gpio1_29 is 0x87c and
the devicetree encoding uses 0x800 as the base offset.
Try this:
root@bbb:~# dtc -I dtb -O dts /boot/am335x-boneblack.dtb | grep gpio
the four lines at the bottom of the output will be
gpio1 = "/ocp/gpio@44e07000";
gpio2 = "/ocp/gpio@4804c000";
gpio3 = "/ocp/gpio@481ac000";
gpio4 = "/ocp/gpio@481ae000";
if the off-by-one problem exists, or
gpio0 = "/ocp/gpio@44e07000";
gpio1 = "/ocp/gpio@4804c000";
gpio2 = "/ocp/gpio@481ac000";
gpio3 = "/ocp/gpio@481ae000";
if it doesn't.
If you have the first set, then in your overlay gpio1_29 would be referred to as <&gpio2 29 0>
Confusing isn't it ?
Yes very confusing!
My kernel does seem to have the off by one issue so &gpio2 is correct.
However isn’t it actually pin 31?
pin 31 (44e1087c) 00000027 pinctrl-single
I’m still not getting a PPS input there but am wondering now if the GPS needs a fix before it even outputs one at all.
Lee
However isn’t it actually pin 31?
pin 31 (44e1087c) 00000027 pinctrl-single
that's pin 31 in the pinmux table, it's not a simple relationship from pinmux number to gpio number
on my kernel there's 141 items in that list, but there are only 118 gpios. gpios0,1&2 have 32 pins, gpio 3 only has 22... according to the datasheet anyway...
If you look in the kernel source.. arch/arm/mach-omap2/mux34xx.c seems to contain the mapping, although I can't say I understand how to read it
I’m still not getting a PPS input there but am wondering now if the GPS needs a fix before it even outputs one at all.
Probably, most gps modules I've encountered only output pps after you get a fix, the EM406A I'm using is like that. Depends on the module, but you may be able to check with an LED attached to the pps output. My EM406A has a 1uS pps pulse width, so you need a scope to see that.
You were right the first time, thank you!
It is very confusing isn’t it!
Hi Lee and selsinork, I have gotten PPS working on a BBW A3 with 3.8.13 kernel following your guidance.
I am using the Adafruit Ultimate GPS breakout. I had used UART4 for serial connection to GPS and gpio1_31 (P8#20) for PPS. This pin is actually not a good choice now (I think it conflicts with emmc on BBB), but I had made the PCB this before BBB was released. Lee’s choice of 1_29 should be better.
The gpio1_31 should be coded as gpio2_31 in the overlay as selsinork pointed out. Very confusing indeed.
I had removed assert-rising-edge after seeing here that the default is already for rising edge. Below is my BB-PPSGPIO overlay source:
/dts-v1/;
/plugin/;
/ {
compatible = “ti,beaglebone”, “ti,beaglebone-black”;
part-number = “BB-PPSGPIO”;
version = “00A0”;
/* state the resources this cape uses /
exclusive-use =
/ the pin header uses /
“P8.20”, / gpio1_31 /
/ the hardware ip uses */
“gpio2_31”;
fragment@0 {
target = <&am33xx_pinmux>;
overlay {
gps_pps_pins: pinmux_gps_pps_pins {
pinctrl-single,pins = <
0x84 0x27 /* P8.20 gpio1_31 (63) */
;
};
};
};
fragment@2 {
target = <&ocp>;
overlay {
pps {
compatible = “pps-gpio”;
status = “okay”;
pinctrl-names = “default”;
pinctrl-0 = <&gps_pps_pins>;
gpios = <&gpio2 31 0 >;
};
};
};
};
root@beaglebone:/home/debian# cat /sys/devices/bone_capemgr.8/slots
0: 54:PF—
1: 55:PF—
2: 56:PF—
3: 57:PF—
4: ff:P-O-L Override Board Name,00A0,Override Manuf,BB-UART4
6: ff:P-O-L Override Board Name,00A0,Override Manuf,cape-bone-proto
root@beaglebone:/home/debian# echo BB-PPSGPIO > /sys/devices/bone_capemgr.8/slots
root@beaglebone:/home/debian# cat /sys/devices/bone_capemgr.8/slots
0: 54:PF—
1: 55:PF—
2: 56:PF—
3: 57:PF—
4: ff:P-O-L Override Board Name,00A0,Override Manuf,BB-UART4
6: ff:P-O-L Override Board Name,00A0,Override Manuf,cape-bone-proto
7: ff:P-O-L Override Board Name,00A0,Override Manuf,BB-PPSGPIO
dmsg shows:
[ 1270.098465] bone-capemgr bone_capemgr.8: part_number ‘BB-PPSGPIO’, version ‘N/A’
[ 1270.098571] bone-capemgr bone_capemgr.8: slot #7: generic override
[ 1270.098596] bone-capemgr bone_capemgr.8: bone: Using override eeprom data at slot 7
[ 1270.098619] bone-capemgr bone_capemgr.8: slot #7: ‘Override Board Name,00A0,Override Manuf,BB-PPSGPIO’
[ 1270.098760] bone-capemgr bone_capemgr.8: slot #7: Requesting part number/version based 'BB-PPSGPIO-00A0.dtbo
[ 1270.098784] bone-capemgr bone_capemgr.8: slot #7: Requesting firmware ‘BB-PPSGPIO-00A0.dtbo’ for board-name ‘Override Board Name’, version ‘00A0’
[ 1270.113904] bone-capemgr bone_capemgr.8: slot #7: dtbo ‘BB-PPSGPIO-00A0.dtbo’ loaded; converting to live tree
[ 1270.114270] bone-capemgr bone_capemgr.8: slot #7: #2 overlays
[ 1270.115369] of_get_named_gpio_flags exited with status 63
[ 1270.118823] pps pps0: new PPS source pps.14.-1
[ 1270.118993] pps pps0: Registered IRQ 207 as PPS source
[ 1270.119105] bone-capemgr bone_capemgr.8: slot #7: Applied #2 overlays.
And now we have the captured PPS assert events, showing the count changes by one every second:
debian@beaglebone:~$ date; cat /sys/class/pps/pps0/assert
Fri Jan 31 18:31:40 UTC 2014
1391193100.002460136#133
debian@beaglebone:~$ date; cat /sys/class/pps/pps0/assert
Fri Jan 31 18:31:41 UTC 2014
1391193101.002453270#134
debian@beaglebone:~$ date; cat /sys/class/pps/pps0/assert
Fri Jan 31 18:31:42 UTC 2014
1391193102.002467910#135
Robert Nelson’s 3.8.13 kernels in the recent test images already have pps-gpio client enabled. It works just fine with this overlay. I could not read the NMEA sentences on UART4 using BB-UART4 overlay though. I will try Lee’s overlay for UART4.
Thanks!
George