Driver Probe Order

Robotics & Edge Computing Jetson & Embedded Systems Jetson AGX Orin
1

I am working on an AGX Orin system with Jetpack 5.1/r35.2.1.

I am trying to use the PPS kernel driver, which tries to register a GPIO early in the boot process. Unfortunately it looks like this is happening before the GPIO driver probes, so the PPS driver fails as well. My question is how do I reorder the boot priority so that the PPS driver doesn’t try to execute before the GPIO driver is ready.

I have already tried rearranging the order of things in the Makefile, and I have the PPS driver listed well after the GPIO driver (this technique worked fine on older Jetpack versions, specifically 4.6 with AGX Xavier).

From my dmesg logs:

[    1.802483] pps_core: LinuxPPS API ver. 1 registered
[    1.807448] pps_core: Software ver. 5.3.6 - Copyright 2005-2007 Rodolfo Giometti <giometti@linux.it>
[    4.610724] pps-gpio pps: failed to request PPS GPIO
[    4.615830] pps-gpio: probe of pps failed with error -22

[    7.985218] gpiochip0: registered GPIOs 348 to 511 on tegra234-gpio
[    7.992392] gpiochip1: registered GPIOs 316 to 347 on tegra234-gpio-aon

Thanks in advance for any help.

3

You could study the init call order of linux kernel driver.

4

Not an answer, but some details which you might be interested in…

The kernel itself is PID 0. init is PID 1. In any semi-recent Ubuntu init is just a symbolic link to systemd, and this is what brings up user space in a particular order. For example, multi-user.target is text-only, and then this transitions to graphical.target, which is the GUI. You can see a list of objects or states systemd uses through the systemctl command:
systemctl list-units

Most of the “standard” setup devices, services, and units are in “/lib/systemd/” or subdirectories. Customizations are usually in “/etc/systemd/” (in particular, “/etc/systemd/system/”, but the $TOP of that directory loads the others as a means of making the file content somewhat logical). If a service or device or target is enabled, and the file is found in “/lib/systemd”, but not in “/etc/systemd”, then this is the file used; if the file is in “/etc/systemd”, then that file is instead used.

The implication is that you can use a symbolic link from the “/etc/systemd” area to the “/lib/systemd” and end up with the default. Or you could copy a file from “/lib/systemd” into “/etc/systemd”, and edit that file while leaving the file name the same, and the service associated with this would be using the modified one. You could also create a completely custom file in “/etc/systemd” and run a device or service or target using that custom name. You’d never put the file in “/lib/systemd” unless it is part of the basic operating system distribution.

If you can find the systemd file related to the content of the PPS driver starting up, then you could also create another file which is set to start after that file starts, and then enable the custom service and it would do what you want.

6

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.