What follows is just one long alternative way to obtain and configure the “equivalent” of headers. I use this sort of method because full source is almost always better than just headers (only it takes a lot more disk space…but not too much if you don’t build an actual kernel
Image). Consider what follows to be a superset of headers, and more extensive than what the 2GB model source would provide. Keep in mind while looking at this that the key to the difference between 2GB and other modules is a combination of device tree and kernel configuration…the source itself is meaningless unless it is configured to match your running system.
Typically you would just download the full source for the kernel. This includes the headers, and if something wants to point at headers, then pointing at the full source also works. The trick is that the source needs to be configured for that particular config (including
CONFIG_LOCALVERSION, which usually is “
L4T releases are listed here:
For R32.4.4 the URL is here:
For the Nano of that release the URL of source code shows as:
…but this probably does not contain everything the non-Nano sources have. Specifically, the source code of the kernel itself should be the same for the non-Nano versions, and the source for the Nano would be only a subset of what is shown for the Nano. The kernel of the Nano would probably be ok, and there is even a “
.deb” package listed which might do what you want, but I suggest looking at this (the non-Nano source):
This is a tar archive, and the package path within this archive for “
source->public->kernel_src.tbz2” would be the correct content once configuration is set to match the Nano’s configuration. Notice that you’d unpack the full
kernel_src.tbz2 since for some NVIDIA components, when configured in the “
kernel->kernel-4.9/”, that the config will require a relative path referring to the other subdirectories (most third party configurations would never need this).
If you have a running Nano, then you should see “
/proc/config.gz”. If you save a copy of this somewhere (permanent for future use), and then edit just the “
CONFIG_LOCALVERSION” (this would be set ‘
="-tegra"’ in the file because “
-tegra” is the suffix of the output of “
uname -r”), then this should be an exact match to your running system and also be the correct “
.config” to use with “
make prepare” and “
make modules_prepare”. Those prepare statements should make the kernel configure to the exact running system if the “
.config” is in place, and this in turn should make it possible to treat the full source as if it were the headers only.
Once you have this, point a symbolic link from “
/lib/modules/$(uname -r)/build” to the “
source->kernel->kernel-4.9/” location and it should work as if it were headers. Example, assuming native build on the Jetson:
cd /lib/modules/$(uname -r)
sudo ln -sf /where/ever/it/is/source->kernel->kernel-4.9 build
# Then verify source exists at "ls /lib/modules/$(uname -r)/build/*".