You are correct that building zImage also builds Image.
By default the NVIDIA kernels enable
CONFIG_MODVERSIONS. This works because after the kernel is configured all modules are built against that kernel source and configuration. Versions match.
If you were to retain
CONFIG_MODVERSIONS and configure the matching source with the matching configuration, and then add your module, I would think that you would not have issues with
CONFIG_MODVERSIONS and mismatched modules. It is possible that removing
CONFIG_MODVERSIONS will work correctly, but I would always have to wonder why removing
CONFIG_MODVERSIONS was needed. Perhaps the configuration mostly matches, but the software does not know this, or perhaps there is some tiny mismatch waiting to bite you.
For more of an explanation, consider what it takes to compile an exact match to the existing kernel as shipped by NVIDIA (or as freshly flashed).
- The source code is the same release.
- The configuration is the same, features are not added or removed.
uname -r” responds the same because you also matched
Now consider that if you add a feature as a module, then previous features should not require a change to “
uname -r” (and
Image should not need changing). If you were to add or remove features which were conflicting, then “
uname -r” would need to change and the modules used would need to be rebuilt and placed in the new module search path. Since
CONFIG_MODVERSIONS is normally integrated into the kernel (for which a more invasive replacement of the
Image is needed), I would tend to feel that there should be a change to
CONFIG_LOCALVERSION (and thus module search path component “
uname -r”), along with rebuilding all modules. This doesn’t mean the modules won’t work since we know there were no other changes, but this probably is not a good idea. Having module versions match guarantees compatibility, now you have no guarantees either of working or failing.
As a general comment, if you are just adding a module you’ve built, then there should not have been any change to the
Image file (the integrated features). Instead of replacing the whole kernel it is probably possible that you could configure your source as a match (including
CONFIG_LOCALVERSION), and then compile your new module against that source. Should that succeed, then even with
CONFIG_MODVERSIONS the new module should probably be able to load.
In most cases the kernel config target “
make tegra_defconfig” will match the kernel which ships once you’ve set:
If you have the original kernel running, then you can guarantee an exact match for modules compiled against that source configuration (after updating
CONFIG_LOCALVERSION) if you use “
/proc/config.gz” for your starting configuration, and do nothing more than build a kernel module against this. If you changed the
Image, then this is no longer possible until the original
Image is put back in place.