Internal TX2 traffic on UART7 ?

There appears to be some non-user-controlled traffic on UART7, which seems to make it difficult/impossible to use for a custom application, as noted here:

We are observing that sometimes this other (internal) controller responds with error messages to traffic we generate on that UART, which get interleaved with our application’s traffic. This makes UART7 not really usable for bidirectional communications with an external module (in our case, an IMU).

Is there some way to tell that “other” (internal to TX2) device on UART7 to “stop talking” after the boot process has completed, so that UART7 can be used solely for a custom application?


hello morganziy3j,

share below steps to disable bpmp firmware message on UART7.
please take a try, thanks

  1. Convert the DTB to DTS using dtc tool in Linux_for_Tegra
cd Linux_for_Tegra
sudo dtc -I dtb bootloader/t186/tegra186-a02-quill-pxxxx.dtb -o test_bpmp.dts

2. Change the DTS file to disable UART7

sudo vi test_bpmp.dts
change the value of "port" under node serial to 255
  1. Rebuild the DTB file
sudo dtc -I dts test_bpmp.dts -O dtb -o bootloader/t186/tegra186-a02-quill-pxxxx.dtb
  1. flash the DTB partition
sudo ./ -r -k kernel-dtb jetson-tx2 mmcblk0p1

Hello JerryChang,

I get the ttyTHS6 as the topic,

but when I use minicom to test whether if this port is ok, is return stange info

OPTIONS: I18n                                                                
Compiled on Feb  7 2016, 13:35:57.                                           
Port /dev/ttyTHS6, 03:04:48                                                  
Press CTRL-A Z for help on special keys                                      
error: line too long                                                         
command not found                                                            
command not found                                                            
] ]                                     
error: line too long                    
command not found                       
] ]                                     
error: line too long                    
command not found                       
] ] 
error: line too long

how to solve this?

One of the problems with using minicom is that it assumes everything you are talking to is also a modem with the “AT” commands. This is ok and won’t matter if configuration does not do this, but in this case it might be hard to distinguish whether this is a side effect of minicom configuration or if it is a side effect of something else.

So you might try again with a simpler application like this (picoterm example) or gtkterm (these don’t assume it is a modem):

<b>picocom</b> -b 115200 --databits 8 --parity n --stop 1 --flow n /dev/which/ever/tty/device/it/is...

Do the issues show up under any of these as well? (I am assuming this UART is 115200 8N1)

I try to use

picocom -b 115200 --databits 8 --parity n --flow n /dev/ttyTHS6

but the result is same.

This makes me curious considering all else seems correct:


Are you using a different character set or encoding other than en_US? I’m looking for the possibility that more than 8 bits are being sent or that there may be cases of combinations (UTF-16 instead of UTF-8) which the terminal isn’t passing through correctly.

If there is some sort of encoding issue I’m thinking perhaps passing known en_US UTF-8 file content through instead of keyboard might test encoding issues if any of the above differences are found.

Is there updated instruction for this? t186/tegra186-a02-quill-pxxxx.dtb doesn’t match any file in my bootloader folder with Jetpack 3.2.

Or where would we change it in the source dts file so as to preserve it when new dtb built (maybe stupid question - if these are bootloader dtb and not build when kernel dtb built).


This is just in general, I do not know about your particular case. Some general information…

The TX2 uses a tegra18x series, specifically the tegra186, abbreviated t186. The a02 would be a board revision, the “pxxxx” is abbreviated for the numeric designation of either the module or the carrier (so you might need to adjust specifics for your module and carrier). Depending on release, look in the driver package’s “bootloader/t186ref/” subdirectory. Various device tree files will be there, and flash would choose among those depending on what the board is (the numeric designation would have one version for module, a second version for carrier would combine to be a complete description of module on carrier). My TX2 developer kit happens to be described from “p3310-1000”. Different trees may apply to different subsets of module and carrier, whereby different smaller trees might be inserted into the final full tree.

Flash logs on my particular TX2 under R28.2 shows:

copying bpfdtbfile(/home/dan/Documents/embedded/L4T/R28.2/x2/Linux_for_Tegra/bootloader/t186ref/<b>tegra186-a02-bpmp-quill-p3310-1000-c01-00-te770d-ucm2.dtb</b>)... done.

The first dtc operation, with “-I dtb”, takes the binary file as input, and the output format is source, via the “-O dts”. File name output can be arbitrary, and in that example, “-o test_bpmp.dts”. You can view, manipulate, edit, and place this extracted file back into binary format and use it to replace the one used in the “bootloader/” subdirectory during flash.

Note that within the “Linux_for_Tegra/” subdirectory, where the driver package exists, that the log above shows the original file in “bootloader/t186ref/tegra186-a02-bpmp-quill-p3310-1000-c01-00-te770d-ucm2.dtb” (and other dtb files) can be copied from other locations for staging before flash. Subdirectories of the “bootloader/” directory are worth exploring after looking at “copy” logs from a flash.

copying bpfdtbfile(/home/troll/Jetpack-32/64_TX2/Linux_for_Tegra/bootloader/t186ref/tegra186-a02-bpmp-quill-p3310-1000-c04-00-te770d-ucm2.dtb)… done.

Seems to infer the proper dtb to modify is tegra186-a02-bpmp-quill-p3310-1000-c04-00-te770d-ucm2.dtb similar but slight difference as listed by your flash log.


If you flash and save a log of your particular Jetson using the particular release currently running, then you should be able to verify which files are needed (my module or carrier revision may differ from yours).

So with R28.2 at least (and newer likely):

Requires having build the kernel from source it appears, since the dtc file is found in the images output folder under scripts/dtc, in my case sources/images/scripts/dtc/

Looking at the output as per linuxdev above I found the dtb used:

copying bpfdtbfile(/home/troll/Jetpack-32/64_TX2/Linux_for_Tegra/bootloader/t186ref/tegra186-a02-bpmp-quill-p3310-1000-c04-00-te770d-ucm2.dtb)... done.

Working in <jetpack_folder>/64_TX2/Linux_for_Tegra

  1. Convert the DTB to DTS using dtc tool in Linux_for_Tegra
cd Linux_for_Tegra
sudo sources/images/scripts/dtc/dtc -I dtb bootloader/t186ref/tegra186-a02-bpmp-quill-p3310-1000-c04-00-te770d-ucm2.dtb -o test_bpmp.dts

2. Change the DTS file to disable UART7

sudo vi test_bpmp.dts
change the value of "port" under node serial to 255
  1. Rebuild the DTB file
sudo sources/images/scripts/dtc/dtc -I dts test_bpmp.dts -O dtb -o bootloader/t186ref/tegra186-a02-bpmp-quill-p3310-1000-c04-00-te770d-ucm2.dtb
  1. This part is a guess - I flashed in entirety due to some other changes. Flash the bpmp DTB partition
sudo ./ -r -k bpmp-fw-dtb jetson-tx2 mmcblk0p1

viola, clean UART7

Btw, the dtc application itself, although being shipped with the kernel source, is more or less architecture independent and works across a very large range of device trees regardless of platform. This program is available as a regular package on Ubuntu, Fedora, and many other flavors of Linux without requiring the one which ships with kernel source.

I’m try using UART7. Transmit from Tegra is good, but receive is wrong.
I change tegra186-a02-bpmp-quill-p3310-1000-c04-00-te770d-ucm2.dtb in this place: (after decompiling, of course)

serial {
port = <0xff>; #port = <0x7>;

Then I try flash Tegra, I see message:

NOTICE: BL31: v1.2(relase):e1e4477
NOTICE: BL31: Built : 00:08:30, May 17 2018
NOTICE: Trusty image missing.
ERROR: Error initializing runtime service trusty_fast

and flash process finish with error.

What else can I do for normal use UART7?