The interesting thing is that if you are just building a module (or I should say only aarch64 architecture) it isn’t too bad on the JTX2. Here’s some info:
Basically, if your kernel source is on the TX2 (traditionally at “/usr/local/src/kernel” or “/usr/src/kernel”), and you configure it using the existing config (copy “/proc/config.gz” to your compile location, then “gunzip config.gz”, and copy to “.config”), you’re almost set. There are some configuration tools you may need to install a package for, e.g., libncurses5-dev is needed for “make menuconfig” or “make nconfig”…there is also libncurses5w-dev for some wide characters in non-western locales (the extra “w” stands for “wide characters”). You might run this before trying to configure:
sudo apt-get install libncurses5-dev
The “.config” file has one other edit before it exactly matches the current kernel. If you run the command “uname -r”, then the suffix to the version shown is the setting used in CONFIG_LOCALVERSION. So if “uname -r” is “4.4.15-tegra”, then the kernel source is 4.4.15, and LOCALVERSION is “-tegra”. You need to set the config to match the “-tegra” part. You can edit the “.config” file directly and set:
Or you might run “make nconfig” (still assumes “.config” was put in place based on “/proc/config.gz”), search for LOCALVERSION, and navigate to that…set it to “-tegra”, and save. If you build this kernel now, you will get an exact copy of the features of the existing system. You can add modules (such as for DVD and ISO9660) and they will drop in and work with this kernel since the configuration matches. Under “make nconfig” you can search for the symbols you are wanting and navigate there, enable as a module (‘m’…this will simplify things because you only add a module and not replace the whole kernel), and when it is all configured you can build the modules:
If you run “sudo make modules_install” from the Jetson it would put everything in that is a module…that’s ok, but not needed since only your additions changed. Copying other modules in which are duplicates is not harmful, it just isn’t useful. If you know the name of the module which is new (when you go to “make nconfig” you can look at the help on the item and it will tell you the module name) you can just copy it to the correct subdirectory of “/lib/modules/
uname -r/”. There is a logical structure of those subdirectories, so you can look at where in the kernel source the module is and have a good idea where to copy it in the modules directory. If this is confusing, just go ahead and instead “sudo make modules_install”.
The “sudo depmod -a” should do any bookkeeping needed so the kernel loads modules without needing help.
The TX2 documentation has a kernel build set of information in it. Some information may be about cross compiling and tool chains…when just building modules directly on the TX2 you don’t need to worry about that. See Documentation at: