Something important before mentioning those specific kernel modules: What do you see for “uname -r”? If you compiled the kernel, and wanted to use the old modules, then you must have the same “uname -r” on both old and new kernels. “uname -r” is the result of the base kernel version, along with a suffix from the option “CONFIG_LOCALVERSION”, and many people skip setting “CONFIG_LOCALVERSION”. The default is:
CONFIG_LOCALVERSION="-tegra"
Modules are searched for at:
/lib/modules/$(uname -r)/kernel
(if this changes, but you did not install modules to the new location, then modules will appear to be missing)
Basically you compile the kernel Image target, and also you compile the kernel modules target, then install both if the modules differ. There are times you cannot reuse the old modules, and would actually want “uname -r” to change, but here are some hints about module “.ko” files…
If you look at “/lib/modules/$(uname -r)/kernel”, then you will find subdirectories match subdirectories of the actual kernel source. If you were to correctly set up kernel module configuration and build modules, then a module would appear in the kernel source tree where it’s source is located. As a contrived example, USB HID content is in the source at “drivers/hid/”, and any compiled module would also be in “drivers/hid/” (many “*.ko” files would be found here after module build). As a result, when installed, those files would be copied to the running system at:
/lib/modules/$(uname -r)/kernel/drivers/hid/*.ko
I would expect the two NVIDIA drivers to still be present if “uname -r” did not change. If this did change, then I would expect they’d need install to that new location. Even if they did not change, if the kernel itself had some new detail which makes the old modules incompatible, then those modules would fail to load (which is different than the files missing).
It is important to know that when you build a kernel the target “make Image” will also propagate various configuration items correctly throughout the source. This means one could then just “make modules”. However, if you did not first “make Image”, then the configuration would not propagate, and you’d need to run the command “make modules_prepare” before “make modules”. And of course you would have had to have configured correctly before any of those make commands, or else configuration being propagated would be nonsense.
If you set the modules install location to an empty/blank temporary location, then “make modules_install” will copy the result content there and separate out the source. I’ll recommend trying it to explore what files are put in place there. If you simply run “make modules_install” without first setting up for a temp location, then it will directly install to what it thinks the running system uses. I do not recommend this latter install location on a Jetson since it does not give you a chance to see if it is correct.
An example for modules going to an alternate location, run as a regular user:
mkdir -p "${HOME}/build/modules"
export TEGRA_MODULES_OUT="${HOME}/build/modules"
# ...configure steps, including setting "CONFIG_LOCALVERSION"...
# Then either of "`make Image`" or "`make modules_prepare`".
# Then the install of modules to a temp location:
make INSTALL_MOD_PATH=$TEGRA_MODULES_OUT modules
(then examine all that is in “${HOME}/build/modules”)
There are actually other things to do in addition to this, but that is the gist of seeing how and where modules are built and installed.
