Unable to achieve PPS with Jetpack 5.0.2

Autonomous Machines Jetson & Embedded Systems Jetson Xavier NX
,
1

Hi,

We have previously used PPS with our Jetson Xavier NX (JP4.4) successfully, to get a precise time sync (PPS from GPS to NX). I have now upgraded the NX to Jetpack 5.0.2 and tried to follow the same procedure to enable PPS support, and have been able to get pps0 to show, but not pps1. Pps0 is the ktimer signal, I need the gpio-based one.

Here is what I have done:
Built kernel from source, with the following set in .config:

CONFIG_PPS=y
CONFIG_PPS_CLIENT_KTIMER=y
CONFIG_PPS_CLIENT_LDISC=y
CONFIG_PPS_CLIENT_GPIO=y

Built the kernel, flashed the image to the Jetson board.

I then create pps.dts:

/dts-v1/;
/plugin/;
/ {
overlay-name = “Jetson PPS”;
compatible = “nvidia,p3509-0000+p3668-0001”;
fragment {
target-path = “/”;
overlay {
pps: pps_gpio {
compatible = “pps-gpio”;
gpios = <&tegra_main_gpio 105 1>;
status = “okay”;
};
};
};
};

Compile with

sudo dtc -I dts -O dtb -@ -o pps.dtbo pps.dts

It creates the pps.dtbo as expected.

Running

sudo /opt/nvidia/jetson-io/config-by-hardware.py -l

doesn´t show the “Jetson PPS” as it did previously though.

Compiling manually with

sudo fdtoverlay -i tegra194-p3668-0000-p3509-0000.dtb -o tegra194-p3668-0000-p3509-0000-user-custom.dtb pps.dtbo

and replacing in extlinux.conf seems to work, but does not make /dev/pps1 show either.

I also tried modifying the hardware/nvidia/platform/t19x/jakku/kernel-dts/tegra194-p3668-all-p3509-0000.dts, but with the same result.

Are there any changes in 5.0.2 compared to 4.4 that could impact this?
Has anyone successfully enabled GPIO-based PPS on the NX with Jetpack 5.0.2?

Best regards,
Milan

3

hello mhtechdev,

could you please look into kernel logs, can you register pps correctly? i.e. $ dmesg | grep pps
please also test with pps utility, for example, $ sudo apt install pps-tools
you may check with… $ sudo ppstest /dev/pps0 to check whether you’re able to get one timer trigger for each pulse.

4

Thank you for your quick answer.
The output of dmesg is as follows:

tmp_4285694c-a394-4d31-8559-e205b49a1d0f

pps-test shows a once-per-second signal, even with no pps connected to the PPS input.

5

could you please also refer to this thread. HOW to Increase GNNS timing module on Xavier? - #9 by shgarg

6

Thanks, but that seems to match what I have been doing. I tried to enable the CONFIG_PPS_CLIENT_GPIO as module and insmod it, but the /dev/pps1 still does not appear. The output of dmesg | grep pps stays the same, no mention of the GPIO PPS.

Edit:
I have now tried to decompile the dtb file from /boot/dtb with:

sudo dtc -I dtb -O dts -o output.dts tegra194-p3668-0000-p3509-0000.dtb

Interestingly, there is no mention of pps in the output.

Adding

pps_gpio {
compatible = “pps-gpio”;
gpios = <0xffffffff 0x69 0x01>;
status = “okay”;
};

to output.dts and recompiling with

sudo dtc -I dts -O dtb -o dtb/kernel_tegra194-p3668-0000-p3509-0000.dtb output.dts

still does not show a /dev/pps1.

7

Finally managed to get the /dev/pps1 to show.

The two things I did:

  1. Set CONFIG_PPS_CLIENT_GPIO=m, as mentioned in the thread linked by @JerryChang
  2. Make sure that it is set in tegra_defconfig as well
  3. Build, and manually copy the tegra194-p3668-0000-p3509-0000.dtb to the NX’s /boot/dtb and replace the existing file

Now, after adding the PPS GPIO with insmod, /dev/pps1 is shown.

Thanks for the help!

8

Actually, while the /dev/pps1 shows, it doesn´t register the changes on the GPIO13 (GPIO3_PN.01).

After some comparison with the old setup, I realised that there is a difference in the ouput of cat /sys/kernel/debug/gpio.

On the old setup with Jetpack 4.4, it shows:

gpio-393 (GPIO13 |pps-gpio ) in lo

On the Jetpack 5.0.2 setup however:

gpio-419 (PN.01 |pps ) in lo IRQ ACTIVE LOW

How come the gpio number is different? gpio-393 matches GPIO13 according to the NX pinmux table, and so does PN.01, but why does it suddenly show gpio-419 instead of 393?

I am guessing that I made a mistake when doing the device tree changes?

9

hello mhtechdev,

that’s due to GPIO allocation range changes since kernel-5.10.
you may see-also developer guide, To check a GPIO number for reference, thanks

10

Ok, but if I understand correctly both setups should be correct, since the old one shows GPIO13, and the new one shows PN.01 which both refer to the same physical pin (33 on the 40pin header)?

What else could be the reason that the pps signal doesn´t show on the JP5.0.2 NX?

I am using the same physical setup, a DevKit with pps connected to pin 33, and it works on JP4.4.

dmesg | grep pps (after using insmod to add pps kernel module) now returns:

[ 0.406432] pps_core: LinuxPPS API ver. 1 registered
[ 0.406451] pps_core: Software ver. 5.3.6 - Copyright 2005-2007 Rodolfo Giometti giometti@linux.it
[ 3.163099] pps pps0: new PPS source ktimer
[ 3.163241] pps pps0: ktimer PPS source registered
[ 3.165348] pps_ldisc: PPS line discipline registered
[ 1036.296090] pps pps1: new PPS source pps.-1
[ 1036.296286] pps pps1: Registered IRQ 272 as PPS source

So it looks like it is registered correctly, but it never sees a change on the pps gpio.

/sys/class/pps/pps1/assert is always 0.000000000#0, and ppstest /dev/pps1 times out

11

hello mhtechdev,

could you please try adding below in kernel dtb,
for example,

    pps {
        gpios = <&tegra_main_gpio TEGRA194_MAIN_GPIO(N, 1) GPIO_ACTIVE_LOW>;
        compatible = “pps-gpio”;
        assert-falling-edge;
        status = “okay”;
    };
12

Hi JerryChang,

I have tried adding it both to
hardware/nvidia/platform/t19x/jakku/kernel-dts/tegra194-p3668-0000-p3509-0000.dts
and
/hardware/nvidia/soc/t19x/kernel-dts/tegra194-soc/tagra194-soc-base.dtsi
but with the same effect. /dev/pps1 shows up, but does not register gpio changes.

13

hello mhtechdev,

you meant that you’re able to see sysnode, /sys/class/pps/pps1/.
but, there’s nothing happened whenever interrupt occurs, by checking… $ cat /sys/class/pps/pps1/assert

according to device tree code snippets,

    pps {
        ...
        assert-falling-edge;

it’s assert on the falling-edge of signal, if you want events to generate on rising-edge of signal, please remove the property for confirmation.

14

Hello JerryChang,

I have a continuous PPS signal attached, so including both rising and falling edges, and no events are generated at all.
I have tried both with and without assert-falling-edge, and none of the two cases work.

15

this is a generic linux driver; please make sure that the driver probe is happening and please following the linux documentation.

16

I managed to get one step further (or one step back, I´m not fully sure).

I realised that when decompiling the kernel and adding:

    pps {
          compatible = "pps-gpio";
           gpios = <0xffffffff 0x69 0x01>;
          status = "okay";
 };

and then recompiling again, it does not add /dev/pps1, but the following is printed in dmesg:

[ 0.397145] pps_core: LinuxPPS API ver. 1 registered
[ 0.397157] pps_core: Software ver. 5.3.6 - Copyright 2005-2007 Rodolfo Giometti giometti@linux.it
[ 2.979984] pps pps0: new PPS source ktimer
[ 2.980137] pps pps0: ktimer PPS source registered
[ 2.983027] pps_ldisc: PPS line discipline registered
[ 92.928373] OF: /pps: could not find phandle
[ 92.928515] pps-gpio pps: failed to request PPS GPIO
[ 92.928671] pps-gpio: probe of pps failed with error -22

I have seen other similar threads where this was suggested to be caused by too early initialization of the pps-driver, but I have already added CONFIG_PPS_CLIENT_GPIO=m.

I tried to add the suggested fix of replacing the return -EINVAL; with ret in

static int pps_gpio_probe(struct platform_device *pdev)
{
…
} else {
ret = pps_gpio_setup(pdev);
if (ret)
return ret;

but with no effect.

17

hello mhtechdev,

you may add the flag CONFIG_DYNAMIC_DEBUG into tegra_defconfig and rebuild the kernel.
please see-also Topic 224203 to enable dynamic debug flag of pps driver and debug further.

18

Hello JerryChang,

I have tried to enable CONFIG_DYNAMIC_DEBUG as well as adding the debug prints mentioned in the linked topic (even though it doesn´t seem like it gets to the FETCH, as the GPIO setup fails).

Did:

# cd /sys/kernel/debug/dynamic_debug/
# echo file pps.c +p > control

and then ran insmod pps-gpio.ko, but the output from dmesg | grep pps is the same.

Also now cat /sys/kernel/debug/gpio doesn´t show the pps GPIO anymore

19

hello mhtechdev,

are you kept seeing this failure? is yes, that’s due to your device tree implementation, please review you’re define the pin correctly.

20

Hi JerryChang,

Yes, the issue is the same. And I can´t find the problem with the GPIO definition.

I am still using

gpios = <0xffffffff 0x69 0x01>;

which is also what

gpios = <&tegra_main_gpio TEGRA194_MAIN_GPIO(N, 1) GPIO_ACTIVE_LOW>;

is compiled into as far as I can see.

I also don´t really understand why the old procedure of just creating a dtbo and applying it with jetson-io doesn´t work…

21

hello mhtechdev,

it looks like some issues for using GPIO marco, please try using gpio number directly.
for example, it’s gpio-419 for PN.01.
gpios = <&tegra_main_gpio 419 GPIO_ACTIVE_LOW>;