The instructions for cross compile come with the L4T release page. You’d use an Ubuntu host PC for that. Then you would skip the install instructions and just copy the file (although if a module is needed during boot stages an
initrd instruction would be required, but nothing I know of requires bluetooth to boot; info left in case of other people reading this). Will you cross compile on an Ubuntu host PC? That part is simple. Instructions differ if compiling on the Jetson itself.
Configuration will be the same regardless of if it is native or cross compile. The gist is that you match the running system’s configuration, and then make sure the
CONFIG_LOCALVERSION is a match (more on this in a moment). From there you use a proper config editor to add the feature you want, naming it as a module. Propagate the configuration, and then build. The file will be ready for copy.
This is about configuration:
A bit of a preview is that when you use “
make” to compile the kernel source you always give a target. The “
tegra_defconfig” will almost be an exact match to the default kernel. So unless you’ve already modified your kernel, you can start with that. If natively compiling, then it is as simple as this (although in reality there is another option you would use):
The “almost” part is related to what you see from the command “
uname -r”. If you run that command on the Jetson, then you will find it is a combination of the kernel version (such as
5.15.0) and a suffix, the default suffix being “
-tegra”. The version is of course the kernel source version, and that is built into the code itself. The suffix is what you set “
CONFIG_LOCALVERSION” to, and unless you’ve modified this, it’ll be “
CONFIG_LOCALVERSION matching the suffix of your jetson’s “
uname -r”, and using the source code for that L4T release, you would build a kernel which exactly matches the running system. This is when it is valid to make modifications to add other features.
The official instructions will mention editing a configuration. Usually it is some variation of “
make menuconfig”, but I am going to suggest you substitute “
make nconfig”. Both are dependency-aware, and they look almost exactly alive, but the
nconfig allows for symbol search.
CONFIG_BT_RFCOMM_TTY are “symbols”. The search is already aware of the “
CONFIG_” prefix (and case-insensitive), so when the menu opens up with “
make nconfig” you could search for “
bt_rfcomm_tty”, and it would tell you where to find that.
When you get to
CONFIG_LOCALVERSION you would simply set it to:
When you get to
CONFIG_BT_RFCOMM_TTY, you’d use the “
m” key to set it “
=m”, which says to build it as a module. Not all features can be a module, some must be integrated (which is the “
=y” version). Not all features can be integrated. However, for Bluetooth features, I think you can append this with
=m, module format.
Keep in mind I am still suggesting you read the official docs for build steps, but if you are not building the whole kernel, and you are only building modules, then you must propagate the configuration throughout the source after configuration and before build (building the kernel itself does this for you). So if you are not building everything, then the basic command to propagate is:
Before I give too many details let me know if this will be built from the Jetson versus if it is going to be built on a separate desktop host PC. The documentation with the L4T release gives the build information if cross compiling. It is the configuration step that is missing in documentation (there is configuration information, but it does not talk about matching a configuration in order to edit and install just a single module).