In the documents (assuming AGX Orin from the R35.1 URL you mentioned) there will be a “kernel customization” section. I’ll explain some about configuration here, but a related URL (perhaps covering slightly different content) is here:
https://forums.developer.nvidia.com/t/problem-smb-jetson-nano/193640/11
What it comes down to is that the kernel source is not just one program. A kernel is really a framework for executing a lot of drivers and computer management software. Unless every computer has exactly the same hardware arranged in exactly the same way there cannot really be just one “kernel”. A kernel is really an arrangement of many “standardized” modular subcomponents brought together something like a conductor in an orchestra would do for music. At the time you build a kernel that arrangement is in the file “.config”, located wherever your “intermediate” output is.
By intermediate output location I usually mean where someone has specified the “O=/some/where”, separate from the untouched pristine source code. One can build directly in the source code, in which case that would be where .config is found. Any use of “make mrproper” makes source code pristine, and thus this would remove any .config.
One way to get NVIDIA’s factory shipped configuration to that “.config” file is with the “make O=/some/where tegra_defconfig” target. This is not truly “matching” the running kernel, but unless you’ve modified your kernel, then by coincidence this will almost match. I’ll say more about “almost” below. Most of the time using tegra_defconfig gives you a match.
After some base configuration, e.g., tegra_defconfig, then it is safe to use an editor (such as menuconfig or nconfig) to add new features (at least in the form of modules).
On a running Jetson you will see file “/proc/config.gz”. This is not a real file, it exists only in RAM, and is the kernel pretending to be a file. This file is truly “almost” an exact match to the running system. Even if you’ve modified the kernel, then this will still be as close to a match as you can get with one minor exception. If you were to copy “/proc/config.gz” to your empty and pristine intermediate output location, the “O=/some/where” location, then “gunzip config.gz” to decompress it, and finally to rename it to “.config”, then you’d have a near-perfect match:
# The following is not quite correct since this is all on the Jetson, and you
# are probably cross compiling from the PC; just imagine using scp instead
# of cp to make copies to the $TEGRA_KERNEL_OUT of the host PC. You
# might need to first copy config.gz to a non-"/proc" location on the Jetson
# to the PC to start.
cd $TEGRA_KERNEL_OUT
cp /proc/config.gz .
gunzip config.gz
mv config .config
This is because the kernel itself is telling you its actual compiled configuration.
Very subtle and very important: The “almost” part. The actual features the kernel runs with is truly an exact match; either the tegra_defconfig being a feature-wise exact match to a factory setup, or the config.gz being a feature-wise exact match to the running kernel. However, a kernel is a combination of features along with where it looks to find kernel modules. That location depends on the output of the command “uname -r”. This in turn depends on the specific version of the kernel software (e.g., 4.9.140 is one example) along with the suffix from the kernel compile time string assigned to “CONFIG_LOCALVERSION”. Jetsons ship with this string being set to “-tegra”, and thus a 4.9.140 source would produce “uname -r” of “4.9.140-tegra” for that example CONFIG_LOCALVERSION. Should the kernel version and CONFIG_LOCALVERSION match, then the module search location will match.
Kernels with matching configurations can reuse existing modules. If you merely add modules (in addition to what was already specified), then the same kernel can use both old and new modules (all you would need to do is copy the new module file to the original module search location). In some cases one can add a new kernel feature which is integrated (versus module format) and the new kernel can reuse old modules without rebuilding modules (but not in all cases, in which case you’d want to change the “CONFIG_LOCALVERSION” and install all new modules in the new module search location). When you subtract integrated kernel features it is probably best to recompile all modules and change CONFIG_LOCALVERSION (even if you can get away with it you might run into unexpected issues at a later date, so in such a case I just rebuild the kernel Image along with modules).