I have no experience with the particular driver or hardware, but some information which might help follows…
Normally, when a driver is compiled, it must be compiled using the same headers as the running system. Also, the location of finding modules depends on the output from the command “uname -r”. The two are connected in a subtle way, and I will assume for the sake of example that “uname -r” replies with “4.9.140-tegra” in what follows.
Go to this directory:
cd /lib/modules/$(uname -r)
That location is where a custom (or standard) module build would end up placing the module (depends on “CONFIG_LOCALVERSION” being set correctly, and in this example’s case, that would be set to “-tegra”, the suffix of “4.9.140-tegra”…"uname -r" depends on the base kernel source version and the CONFIG_LOCALVERSION).
Within this module directory the actually modules are within the “kernel/” subdirectory, basically mirroring the location in kernel source where a freshly built module would have appeared.
The part which is subtle is the file “build”. This is a symbolic link and not a real directory. Check the output of this from the “/lib/modules/$(uname -r)” directory:
ls -l build
Note that on a PC this points to headers which are part of a standard Ubuntu package. Check the “ls -l build” on both your PC and the Jetson. Note that Jetsons may not have standard headers due to customization. You could install the full kernel source (which has headers) via downloading from the web site and unpacking, and then point the “build/” symbolic link to the actual source.
I personally download the kernel source for the running release, and (on a Jetson when natively compiling) unpack it at “/usr/src”. This results in new content within “/usr/src”:
sources
├── hardware
│ └── nvidia
└── kernel
├── kernel-4.9
├── nvgpu
└── nvidia
The actual source would now be at “/usr/src/sources/kernel/kernel-4.9”. This is where I aim the symbolic link. Example:
cd /lib/modules/$(uname -r)
sudo ln -sf /usr/src/sources/kernel/kernel-4.9 build
There are other things you could consider, e.g., configuring the full source to match your running system, but technically I think that since you only need headers, that it wouldn’t matter. In reality though you have to make sure your “CONFIG_LOCALVERSION” has the “-tegra” even though you are only building an out-of-tree module. There might be other issues too for configuration, but you can always ask about those as you run into the issues.
If you are cross-compiling from a host PC, then you would not want to alter the PC’s idea of its own “/lib/modules/$(uname -r)/build”. However, even on a PC you could install full kernel source instead of just headers. Whatever location you unpack from you’d have the subdirectory “sources/kernel/kernel-4.9/” to treat as if it were headers. Once again, there may be configuration changes needed based on the configuration of the Jetson (you don’t want to use the PC’s configuration). If you run into issues related to this you can always ask more questions.
Personally I prefer native compile since Jetsons are so powerful, but you do have to be careful about running out of disk space since a kernel build can use up a lot. Sometimes I use a thumb drive mounted somewhere for the kernel temporary output if I am doing something taking a lot of space, but I’ve never had issues with the kernel source itself being too large.
