This is just spot checking and some things to beware of. No particular order.
On the Jetson, when it comes to knowing about kernel features, you can get a list of the running kernel’s config as it was compiled:
zcat /proc/config.gz
You can search for a particular item in the config via this example for ‘CRYPTO’:
zcat /proc/config.gz | grep CRYPTO
You can “page” this to make it easier to scroll around:
# All:
zcat /proc/config.gz | less
# Just that tag:
zcat /proc/config.gz | grep CRYPTO | less
Within “less” you can search with a “/” and the tag, e.g., “/AES” for “AES”. To search again for that tag just tap the “n” key, or for previous match, shift-n.
When you see that kernel config tag is “=y”, then the feature is always present, and is integrated directly into the kernel Image. If you see “=m”, then the feature is present as a module, and should automatically load upon demand. At times you can manually load a module if setup is not complete.
The result of the command “uname -r” is a combination of the base version of the kernel, plus the “CONFIG_LOCALVERSION” during the compile. Within the “/proc/config.gz” the “CONFIG_LOCALVERSION” is left blank and is the only feature which keeps config.gz from being a 100% exact match to what that kernel was compiled with. If your CONFIG_LOCALVERSION=“-tegra” during the build, then the command for a “4.9.140” kernel would be “4.9.140-tegra”.
Modules are searched for at:
/lib/modules/$(uname -r)/kernel/
If you “cd /lib/modules/$(uname -r)/kernel/”, then you will change to that directory because the “$(uname -r)” is a macro expansion of the actual command. Modules not in some subdirectory of this will not be found.
You need user space software to perform some setup of filesystems. I have no experience with the encrypted system you are working on, but most likely much of this would allow setup and encryption via those tools even if the kernel features are not enabled (not always, but much of the time).
To actually use one of those features it is very likely that you need that kernel feature. I do not know for sure which CONFIG items you need, but if you compare your “/proc/config.gz” to what documents say, then you can report here which symbols are missing and we can go from there to add those symbols in (FYI, “symbol” and “feature” and “config” are pretty much the same thing in this context).
Some details will change depending on which L4T release is involved. To find this use “head -n 1 /etc/nv_tegra_release”.
You should always copy your original “/proc/config.gz” somewhere as a reference before you work on a kernel. This is the key to starting with what you already have, or reproducing exactly what you had if something goes wrong. You may see references to “make tegra_defconfig”, and for the most part these will match on a fresh system…but this is not guaranteed, and if you really want an exact match (and you do), then start with “config.gz”.
A “config.gz” file can be copied somewhere (the original is not a real file…it is a read-only simulated file produced by the kernel), and decompressed with “gunzip config.gz”. If you were to then edit this file and make CONFIG_LOCALVERSION like this, then you have a 100% match (assuming “uname -r” has suffix “-tegra”):
CONFIG_LOCALVERSION="-tegra"
Placing a copy of this as name “.config” in the correct part of kernel source code prior to a compile or menu config editor puts you way ahead of someone trying to configure from scratch.
Note that if you compile a feature as a module, then you only need a copy of the file to the right place under “/lib/modules/$(uname -r)/kernel/” to complete install. If you compile as an integrated feature, then things require a different file copy. Should module install go wrong, it isn’t a big deal. Should a kernel integrated Image file go wrong, then the system will be unbootable at times, and there are precautions to take. Not everything can be built as a module, and not everything can be built integrated, but if you can build as a module, then life is simplified for you.
Even if you will not install a new kernel Image I advise compiling this at least once to look for errors just as a sanity check. Then compile the modules. For modules which are already installed and for cases where you only add configuration to a new Image which ends up with the same “uname -r”, then you are probably ok to only add new modules and reuse old modules.
Note that this is not something you edit directly:
Even if you are an expert I would normally advise using a menu editor application which is what reads a Kconfig. Most of these require package “libncurses5-dev”, which you get from “sudo apt-get install libncurses5-dev”. Then, at the top level of the kernel source, you can use any of the many possible editors, and this will read the existing “.config” if there is one. Examples, and my favorite is “nconfig” due to symbol search:
make nconfig
make menuconfig
make xconfig
Note that it is a bad idea to compile directly within your kernel source. You can clean the source first with “sudo make mrproper”. Then create some temporary area with no content, e.g., “mkdir ~/kernel_stuff”, copy the “.config” to “~/kernel_stuff/”, and from the source of the kernel refer to the other location for all output:
cd /where/ever/it/is/kernel
make O=~/kernel_stuff nconfig
If you start by finding out which kernel features (config items) are needed, and compare it to the running system’s “/proc/config.gz”, the we can give more specific information.