Enabling HTE timestamping on Jetson AGX Orin

[madhu.dhanasekaran]

Hi,

I am trying to enable HTE on Jetson AGX Orin devkit with Jetpack 6.2 (tegra 36.4.3) and enable GPIO timestamping. I am trying to use pins 29 (PAA.01) as input and 31 (PAA.00) as output. I am interested only in GPIO timestamping and hence have not included the lic irq timestamping here. I have modified the device tree (tegra234.dtsi) to enable the hte test driver like below.

#define GPIO_OUT  TEGRA234_AON_GPIO(AA, 0)
#define GPIO_IN TEGRA234_AON_GPIO(AA, 1)

tegra_hte_test {
    status = "okay";
    compatible = "nvidia,tegra194-hte-test";
    in-gpios = <&gpio_aon GPIO_IN GPIO_ACTIVE_HIGH>;
    out-gpios = <&gpio_aon GPIO_OUT GPIO_ACTIVE_HIGH>;
    timestamps = <&hte_aon GPIO_IN>;
    timestamp-names = "hte-gpio";
};

I also modified the pinmux configuration using the spreadsheet and flashed into the jetson. I could see that the AON pin has been made as output (but still shows as unused) when checked using gpioinfo. Is this expected?

I further used the tegra kernel source for v36.4.3 to build the hte-tegra194-test.ko and copied it to the jetson to load using insmod. When I load the kernel module and do dmesg, I can see a warning message that no symbol version for module_layout Can you please tell me what does it mean exactly and can I ignore this warning for now?

I already went though this discussion Hardware Timestamp Engine but still quite unsure on what is required to enable hardware timestamping.
I also checked this post How to set GPIO AON pinmux configuration? but I see my GPIO pins are still marked as unused.

I am using framos-jetson-drivers GitHub - framosimaging/framos-jetson-drivers at l4t-r36.4.3 for modifying and building my device tree changes as it is easier to build and install. And I do not have to worry about other factors that might affect my usage of camera drivers. Hope this approach should not be a problem.

My list of questions:

1. Is modifying the device tree file tegra234.dtsi with the above content and installing via framos drivers is sufficient to enable the hte test driver?

2. How can I verify if my AON GPIO is assigned as GPIOs only and not the special functions?

3. I am creating a pulse signal using Jetson.GPIO at 10 Hz on pin 31 and connected it to pin 29 to perform hardware timestamping. Is this okay?

4. I can confirm that I have the following in my pinmux.dtsi and gpio.dtsi as explained here How to set GPIO AON pinmux configuration? - #4 by ManuelLeiva

   

   Should this be fine for using AON GPIO (pin 31) as output?

5. I want to use at least 4 AON pins at the same time as inputs and enable hardware timestamping. Can I achieve this with the exisiting driver when it is enabled?

6. Using the flash script to flash the modified pinmux.dtsi and gpio.dtsi actually flashes the entire OS. Can I somehow avoid this and flash only the kernel and keep the OS as it is?

I have tried quite some things already and I hope it should not take much of your time. Please let me know what I am missing here to enable the timestamps. Looking forward to your support.

Best regards

Madhu

[KevinFFF]

Hi madhu.dhanasekaran,

@madhu.dhanasekaran

Is modifying the device tree file tegra234.dtsi with the above content and installing via framos drivers is sufficient to enable the hte test driver?

I would suggest adding them in tegra234-p3737-0000+p3701-xxxx-nv-common.dtsi instead.

@madhu.dhanasekaran

• How can I verify if my AON GPIO is assigned as GPIOs only and not the special functions?

Please configure them in pinmux spreadsheet to use them as GPIO and confirm no other kernel driver is using them. (i.e. please confirm mttcan@c310000 is disabled in device tree for your use case)

@madhu.dhanasekaran

I am creating a pulse signal using Jetson.GPIO at 10 Hz on pin 31 and connected it to pin 29 to perform hardware timestamping. Is this okay?

@madhu.dhanasekaran

I am creating a pulse signal using Jetson.GPIO at 10 Hz on pin 31 and connected it to pin 29 to perform hardware timestamping. Is this okay?

should be fine.

@madhu.dhanasekaran

Should this be fine for using AON GPIO (pin 31) as output?

LGTM. It seems you’ve configured PAA.00(PIN31 of 40-pins header) as Output/Drive 0.

@madhu.dhanasekaran

I want to use at least 4 AON pins at the same time as inputs and enable hardware timestamping. Can I achieve this with the exisiting driver when it is enabled?

It sounds like you need some customizations for this use case. Please verify one GPIO_IN and one GPIO_OUT first.

@madhu.dhanasekaran

Using the flash script to flash the modified pinmux.dtsi and gpio.dtsi actually flashes the entire OS. Can I somehow avoid this and flash only the kernel and keep the OS as it is?

pinmux/gpio dtsi are loaded in early boot stage(MB1), which is included in QPSI.
You can flash QSPI only with the following command.

$ sudo ./flash.sh -c bootloader/generic/cfg/flash_t234_qspi.xml jetson-agx-orin-devkit internal

[madhu.dhanasekaran]

Hi @KevinFFF

Thanks for your quick response. I managed to add the changes to the device tree in the file that you mentioned. I built and installed using the framos jetson drivers as usual.

I also verified that the mttcan@c310000 is disabled or not. Does this look okay or should I set the status explicitly to disabled?

Also, mttcan@c310000 is available in other overlay files in my framos drivers source (in other files they are like above). Should this be a problem. Kindly let me know.

And then loaded the kernel module using this command..

sudo insmod hte-tegra194-test.ko

When I load the module, I still see this in the kernel logs.

Then, I started the pulse generation on pin 31 (PAA.00) and this is shorted with pin 29 (PAA.01) using a jumper wire. But, I still see no timestamps in the kernel logs. Please let me know if you see any ambiguities in any of the above steps.

Also, to be sure that my framos drivers are not interfering with my changes, can you recommend a suitable way to use a separate kernel source to make the device tree changes, building, and flashing it into the jetson?

Can I also write an overlay instead of modifying the DT source directly?

Thank you.

[KevinFFF]

@madhu.dhanasekaran

Does this look okay or should I set the status explicitly to disabled?

I would suggest updating the status of mttcan@c310000 as disabled.

@madhu.dhanasekaran

sudo insmod hte-tegra194-test.ko

I’m not clear about your exact steps to build this kernel module.
Maybe you can refer to Kernel Customization — NVIDIA Jetson Linux Developer Guide to build kernel and dtb.
You can build it into kernel image instead of building it as kernel module and I believe you won’t hit that error more.

[madhu.dhanasekaran]

I have built the kernel in the meantime using these steps and copied the .ko to jetson. But still I see the same error after loading the module. I doubt that the changes made to the tegra234-p3737-0000+p3701-xxxx-nv-common.dtsi is not getting reflected.

Can I also do the device tree changes using an overlay? If so, can it be done something like this? Then I need not build the framos drivers at all and include only this overlay and the kernel module from the host. Does it seem correct?

To keep it simple, please let me know from the host machine if I modify the dtsi file, should I build the whole kernel or just the dtbs? And how can I safely flash only the dtb changes? I believe if I build both the kernel and DTBs I can also expect the .ko to be built and can be safely copied to jetson. Am I right?

[KevinFFF]

@madhu.dhanasekaran

I doubt that the changes made to the tegra234-p3737-0000+p3701-xxxx-nv-common.dtsi is not getting reflected.

Could you run the following command and share extracted_proc.dts for further check?

$ sudo dtc -I fs -O dts -o extracted_proc.dts /proc/device-tree

@madhu.dhanasekaran

Can I also do the device tree changes using an overlay? If so, can it be done something like this? Then I need not build the framos drivers at all and include only this overlay and the kernel module from the host. Does it seem correct?

Both approaches should be fine, please confirm the related configurations are visible under /proc/device-tree on your board.

@madhu.dhanasekaran

To keep it simple, please let me know from the host machine if I modify the dtsi file, should I build the whole kernel or just the dtbs? And how can I safely flash only the dtb changes? I believe if I build both the kernel and DTBs I can also expect the .ko to be built and can be safely copied to jetson. Am I right?

I would suggest updating both kernel image and DTB and refer to the steps from that page to update them.
Then you should perform a full flash to apply the change.

[madhu.dhanasekaran]

Please find the extracted_proc.dts file here.

extracted_pro.tar.gz (50.7 KB)

[madhu.dhanasekaran]

Let me know if I should be adding my changes inside this block

From /proc/device-tree/bus@0/ I can only find hardware-timestamp@c1e0000. And it does not suit these values.

This is what I see inside extracted_proc.dts but even these values do not match when I do
$ cat /proc/device-tree/bus@0/

[madhu.dhanasekaran]

Hi @KevinFFF

I was finally able to view the timestamps successfully in the kernel logs.

What I did was

1. Check the /proc/device-tree/bus@0

sudo -i
cd /proc/device-tree/bus@0/

Here, I could not find my “hte_tegra_test” node that was added. So, confirmed that the device tree was not included correctly.

2. Then, built the device tree in the host machine with the necessary device tree changes. The built dtb file kernel_tegra234-p3737-0000+p3701-0005-nv.dtb was in <Linux_for_Tegra>/bootloader. I also decompiled this file and made sure the tegra_hte_test changes are visible using the following command.

dtc -I dtb -O dts -o final_dt_host.dts kernel_tegra234-p3737-0000+p3701-0005-nv.dtb

3. Once, it’s confirmed copied the dtb to the /boot/dtb/ folder in jetson.
4. Add the following line in /boot/extlinux/extlinux.conf file under LABEL primary
   FDT /boot/dtb/kernel_tegra234-p3737-0000+p3701-0005-nv.dtb
   Then reboot the jetson.
5. Now check the device tree

cat /proc/device-tree/bus@0/tegra_hte_test

This confirms that the device tree changes are intact.

[madhu.dhanasekaran]

Now, I have a few more follow-up questions though :-D

1. Is this a correct approach? However I felt adding a device tree overlay would be much easier as it avoids building the dts files and copying manually. But i could not add an overlay successfully, as I faced compilation issues due to wrong tree structure. Could you point me to some threads where I can write them in a proper way?
2. Also, I would like to access these through an user-space application to access the hardware timestamps that are logged. Is there a documentation somewhere for this?
3. Lastly as I asked before to use this driver for 4 GPIO inputs simultaneously to timestamp 4 different signals. Can you please tell me what kind of customizations are necessary for this?

Thank you for your continued support.

[KevinFFF]

@madhu.dhanasekaran

I was finally able to view the timestamps successfully in the kernel logs.

It seems you’ve enabled it correctly and verified HTE working.

@madhu.dhanasekaran

Is this a correct approach? However I felt adding a device tree overlay would be much easier as it avoids building the dts files and copying manually. But i could not add an overlay successfully, as I faced compilation issues due to wrong tree structure. Could you point me to some threads where I can write them in a proper way?

You can refer to To Create and Apply a DTB Overlay File for this use case.
Please specify OVERLAYS in extlinux.conf and just note that there should be all hex values in overlay dtb.

@madhu.dhanasekaran

Also, I would like to access these through an user-space application to access the hardware timestamps that are logged. Is there a documentation somewhere for this?

It seems you have to write custom application for this use case.

@madhu.dhanasekaran

Lastly as I asked before to use this driver for 4 GPIO inputs simultaneously to timestamp 4 different signals. Can you please tell me what kind of customizations are necessary for this?

You may also need to customize hte-tegra194-test.c for more GPIO inputs.

[madhu.dhanasekaran]

Hi @KevinFFF

Thank you for your answers. I would like to know a couple of things.

1. For enabling timestamps for 4 inputs simultaneously, in addition to the driver code (hte-tegra-test.c) should I also update the below line with multiple input pins?

in-gpios = <&gpio_aon GPIO_IN GPIO_ACTIVE_HIGH>;

If so, can I add them in the same line?

2. I have a scenario where I need to also timestamp one output pin. Will this be possible by the HTE? I have to generate one single pulse to trigger an external IMU in this case.

[KevinFFF]

@madhu.dhanasekaran

For enabling timestamps for 4 inputs simultaneously, in addition to the driver code (hte-tegra-test.c) should I also update the below line with multiple input pins?

I think so. You need to add more in-gpios properties like in1-gpios, in2-gpios, in3-gpios, in4-gpios in device tree and you also need to update the hte-tegra-test.c to handle them.

@madhu.dhanasekaran

I have a scenario where I need to also timestamp one output pin. Will this be possible by the HTE? I have to generate one single pulse to trigger an external IMU in this case.

Could you elaborate on this use case?
As my understanding, the current driver implements the timestamp for input signal only.