In terms of official documentation, see the “kernel customization” section for your specific L4T release (L4T is what actually gets flashed, and is Ubuntu plus NVIDIA drivers; the version can be found with “head -n 1 /etc/nv_tegra_release
”).
This is not a complete answer, but to get a feel for this, here is some information…
The documentation shows cross compile from a Linux host PC. You can also natively compile on the Jetson if you have enough disk space. Installation can be easier than what the official documents suggest since those docs use flash to install the kernel and kernel modules, but in many cases a simple file copy will work. So compiling the kernel with the correct configuration is the first step, and is risk-free; installing is the second step, and you might want to ask about ways to install once you’ve created this software.
Note that the kernel Image
file is the “integrated” actual kernel, but kernel “modules” also exist, and although modules are part of the kernel, they can be dynamically loaded and unloaded. This means that if that feature can be created as a module, then you don’t need to build everything; you’d just build the module and copy it as a file.
Not all features can be built as a module, although most can. That is why we start with a configuration of the new kernel which matches the running system, and then we use an actual kernel configuration editor to make that change to select the new feature as a module…if this is allowed, then the editor will make that change, and will also change any dependencies. If not possible, then you will have to install a new kernel Image
and all of the modules instead of just one module. I don’t know what is required in this case, I have not tried building the bluetooth.
This is a list of each L4T version, and you’d start by looking at the docs for kernel customization at your release page:
https://developer.nvidia.com/linux-tegra
Incidentally, although you’re not asking, kernel configuration uses what is called “Kconfig
”. It’s quite nice and does a lot. That CONFIG_BT_RFCOMM_TTY
is one feature which Kconfig
describes. The kernel itself is very large and has many features you won’t use, e.g., you’re not building a 100 Gb/s backbone router, and Kconfig
makes it easy to build just what you need if you start with a copy of the original configuration. That configuration edit though needs to “propagate” throughout the source code. If you build the entire Image
target, then this is automatic. On the other hand, if you build just a module, you will need to trigger propagation of the config before building the module, e.g., with the modules_depend
target prior to building modules
. I usually suggest building Image
once to propagate because this is the step most likely to tell you if there is a problem.
Note that when you run the command “uname -r
” that the prefix is from the kernel source version (use the L4T URL above to find the kernel source…it is a package within the other sources package), and the suffix is what the feature “CONFIG_LOCALVERSION
” is set to during the build. The default for Jetsons:
CONFIG_LOCALVERSION="-tegra"
Normally, if you are matching configuration, you would manually set “CONFIG_LOCALVERSION=-tegra
” (incidentally, there is more than one way to set this, and it is one of the few configuration items which has no dependencies, so it is easy to set this many different ways).
The significance is that a kernel looks for its modules under a subdirectory of:
/lib/modules/$(uname -r)/kernel
If you need a new kernel Image
, then you want uname -r
to change; if you only need a new module, then you want uname -r
to stay constant.
See what you can find in the documentation, and if you want more information, just ask. Do know that you do not need to flash to install the new content, although this is what the official docs tend to show. Ask when you need to know.