RFCOMM TTY support not available


I want to use Bluetooth serial communication to receive data from my PC.

Therefore, we would like to communicate between ports using RFCOMM.

However, when I try to connect using sudo rfcomm bind 0 00:1A:7D:DA:71:13, it says RFCOMM TTY support not available.

Do I need any settings to connect?

This is my Jetson information.

Module: NVIDIA Jetson Orin Nano (Developer kit)
Release : 5.10.120-tegra
L4T: 35.4.1
Jetpack: 5.1.2

I have no knowledge of RFCOMM. However, what do you see from:
zcat /proc/config.gz | grep -i rfcomm

I am only guessing, but even on an older model of Jetson, I see:


I suspect that you could build CONFIG_BT_RFCOMM_TTY as a module, copy the file, run “sudo depmod -a”, and it would work. At least for the kernel side requirements…there might be more user space configuration or package install involved.

The basic requirement for doing that would be to download the kernel source for this specific R35.4.1 release, configure it to match your running system (including CONFIG_LOCALVERSION), and then use a config editor (such as nconfig) to add that feature in addition to the rest of the config matching, and build.

Incidentally, the L4T release listing is here, and this leads to the source for the kernel (and a lot of other things):

Within the R35.4.1 page you would download the “Driver Package (BSP) Sources” (linked to R35.4.1). From that you would extract the kernel_src (it is a package within a package), extract that, and then work with that (either cross compile on an Ubuntu PC or native compile on the Jetson if you have enough space).

Documentation for cross compile is on that same URL and would work with an Ubuntu 18 or 20 host PC. Just don’t follow the install part of the docs because it would refer to using flash to install rather than a simple file copy.

how can i build CONFIG_BT_RFCOMM_TTY as a module, copy the file?

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):
make tegra_defconfig

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 “-tegra”. With 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_LOCALVERSION and 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:
make modules_depend

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).

I want to have bluetooth communication with ubuntu PC on jetson. To do this, we will use serial communication and will attempt to connect using RFCOMM.

I have not used RFCOMM or Bluetooth for such use, but it sounds like it should work if you have the kernel module/driver. Let me know if you are interested in more information on build or installation. As mentioned earlier, build instructions are fairly good, but installation via just a file copy differs from the flash method in official docs.

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.