Keep in mind that the “/proc/config.gz” file is a reflection of the running system and is not a real file. Thus the kernel currently running actually creates this file on the Jetson. When running an unmodified kernel you should copy this somewhere for safe backup…you are going to want to use it in the future even after you’ve updated.
Also write down the output of “uname -r” and remember this is associated with the config.gz you just copied. Probably it will be “4.4.38-tegra”, where “4.4.38” is the kernel version and the “-tegra” is a suffix. It is this suffix you will need to know later…between that suffix and the config.gz file you will be able to create an exact match to the existing environment (any changes are simple from there).
The source_sync.sh script downloads kernel source, you have to take a copy of the “config.gz” file from the first step, gunzip it, and put a copy in correct place. “correct place” depends on whether you use options to place compile output outside and keep the kernel source clean (and you should), or if you are just building directly in the kernel source (you can, but it is not advisable). Regardless of which location it is, then having that config file there by the name “.config” will cause this to be the default when you “make” anything.
I suspect you are going to feel a bit overwhelmed because I am telling you you must build a kernel module, but it isn’t too hard once you are set up. All you are doing is creating a file and then copying it to the correct directory. I will assume you are keeping your kernel source clean and building in an alternate temporary output file location natively from the TX1.
Make sure you have installed “libncurses5-dev” on the Jetson:
sudo apt-get install libncurses5-dev
For the purpose of an example, I assume you copied file “source_sync.sh” to “/usr/local/src/”, but it could be almost anywhere convenient, e.g., in a home directory. This would imply that when you ran source_sync.sh from “/usr/local/src/” it produced this subdirectory, which is the kernel source:
I will assume you set an environment variable (and be careful because this will be empty on any terminal you did not set this), and have the following, but you could just paste the full path in:
(test to see “echo $SRC” says “/usr/local/src/sources/kernel/kernel-4.4”)
You may have to create a temp file output location directory, but just use “mkdir” (or “sudo mkdir”) where needed. My example will be “/usr/local/src/build/”:
(verify “echo $TEGRA_KERNEL_OUT” shows this)
In a similar manner you will create a temporary module output directory (similarly you may create this anywhere you want):
(verify “echo $TEGRA_MODULES_OUT” is this)
From your backup copy of config.gz, after gunzip, rename it “.config” and place it in “$TEGRA_KERNEL_OUT”. I don’t know where your backup is, but it would go something like this (use sudo where needed…I actually change ownership of my TEGRA_KERNEL_OUT and TEGRA_MODULES_OUT to user “ubuntu” and compile as that user…the SRC directory can remain owned by root):
cp /where/ever/it/is/config.gz $TEGRA_KERNEL_OUT
mv config .config
Edit “.config”, find “CONFIG_LOCALVERSION”, and match the current suffix of the “uname -r” (probably “-tegra”). So it will read:
Now you go to the actual source (and keep in mind if you use more than one terminal you need to have exported the TEGRA_KERNEL_OUT and other values in any terminal you use) and configure:
# There is more than one config editor, I just like nconfig:
# Note you can search for symbols if you look at the list of hot keys at the bottom of the
# nconfig menu. Search for "CONFIG_CIFS_SMB2" or just "CIFS_SMB2". When you find it, then
# go there. Highlight it. Press the "m" key to select it as a module. Save and exit. Done
# with configuring. Next build.
Now increase TX1 performance to max for faster build:
Just so you know you do not need “make Image” since you are only adding a module configured to work with the existing kernel. However, I consider this a sanity check. You should do it anyway even if you don’t need it…at least one time. After that if you are confident and doing future module additions you don’t need to “make Image”. For sanity (and this takes time):
# NOTE: That is a capital letter "o", not a zero:
make -j4 O=$TEGRA_KERNEL_OUT Image
There are all kinds of possible warnings, ignore them unless you get an error which terminates early. On success you will find “Image”:
find O=$TEGRA_KERNEL_OUT -name 'Image'
You also do not have to build all modules…but you should for sanity:
make -j4 O=$TEGRA_KERNEL_OUT modules
make O=$TEGRA_KERNEL_OUT modules_install INSTALL_MOD_PATH=$TEGRA_MODULES_OUT
I don’t know the specific module name, but it would have “cifs” in its name:
find $TEGRA_MODULES_OUT -name '*cifs*'
That “.ko” file will be your driver/kernel module. Note that the existing system will have all modules somewhere under “/lib/modules/$(uname -r)/”. The location of any “.ko” file will be a mirror of where it is in the kernel source tree. Note that this directory will exist on the Jetson:
Since this is a file system type I suspect when you “find” the file name in the “$TEGRA_MODULES_OUT” it will be in some “fs/” (file system) subdirectory, and so the location is probably under:
My system already shows “cifs.ko” there, but in theory you are building a different version…maybe its name is “cifs2.ko” (I don’t know, I didn’t actually build it). Most likely the file you just built would go there. If instead the file is found in a “cifs2/” directory (I don’t know if it is or not), then you’d make a “cifs2/” directory next to the “cifs/” directory (and then copy the cifs2 “.ko” file there). You’re fairly safe to put it in the wrong place, though it might or might not work.
To tell the system to update its module knowledge:
sudo depmod -a
You can use commands to then manually load the kernel without reboot, but it will be simplest to just reboot. Then test.
Note: Features as a module (where the module is loaded) can be seen with “lsmod”. Run this before you add the module. Likely the other version of cifs.ko will show up. After done and you reboot see if there is now the other version as well.
Even though this is correct for installing that module it doesn’t guarantee it was the source of the original problem. Maybe it is authentication. Or maybe it is this plus authentication. Perhaps you will now also need some configuration. Just don’t panic if this doesn’t do the job because it is still good to learn and is probably at least a subset of what is needed. From then on this driver will be available and you can rule that out as a cause of failure.
Btw, if you want to start over from scratch, then normally the “cd $SRC; make O=$TEGRA_KERNEL_OUT mrproper” would clean things out. However, there may be some out of tree stuff which is a result of some of the extra directories…feel free to recursively remove the content in “$TEGRA_KERNEL_OUT” to clean things before starting new. This is a big reason why building in a separate output directory is good.
Trivia: You’ll still be running the same kernel. Only the module will differ.