Disable boot log messages - need more details

Hi guys,

this is my second day with a Jetson TX2 board and my task is to switch off all boot messages via UART0 since we connect a device there that may get confused when it receives unexpected data.

Now I read a lot about this topic already in this forum, e.g. here .

So I’d like to test if the .cfg switch “debug.enable_log” has any effect.
But I don’t know exactly what I have to do after I edited the .cfg-file. I believe I do not only have to save the file and flash “everything” with flash.sh.
Do I have to re-compile everything (especially the bootloader) and then flash the binary or do I have to pack the .cfg into some package and flash that?

Can please somebody point me to the appropriate documentation on how to bring changes in the .cfg-files to an effect on the board?

Thank you very much,

You only need to modify the cfg file and run the flash.sh command again.

That was a quick one! Thanks!

Hi again,

it’s obviously not as easy as expected…

I edited the files


to contain

debug.enable_log = 0;
(I don’t know, why there are two files with the same name, but I thought it would be more safe to just edit both…)

and then I flashed my TX2 with

sudo ./flash.sh jetson-tx2 mmcblk0p1

It took a while and after that I re-boot and still got debug messages from UART0.

I also read in one thread, that changing this .cfg-file does not prevent UART0 to put out debug messages. I somehow confirmed it now and wonder how to proceed from here?
Can I somehow check if the setting from the .cfg-file really is applied to the board package?
Do I have to re-compile the bootloader and prevent messages from going out via UART0?


Please also refer to this if you also want to remove the kernel to dump log to uart.


Thanks for the additional information!

Unfortunately, it does not turn off messages via UART0 either.

For completeness, this is my L4T Version:
cat /etc/nv_tegra_release

  • R28 (release), REVISION: 2.1, GCID: 11272647, BOARD: t186ref, EABI: aarch64, DATE: Thu May 17 07:29:06 UTC 2018*

So I looked up the documentation for this release here and it says the same as WayneWWW pointed out.

My extlinux.conf:
DEFAULT primary

MENU TITLE p2771-0000 eMMC boot options

LABEL primary
MENU LABEL primary kernel
LINUX /boot/Image
APPEND ${cbootargs} root=/dev/mmcblk0p1 rw rootwait rootfstype=ext4

So I did remove the line “console=ttyS0” and I switched debug messages off in the above mentioned bootloader *.cfg without no effect. Messages are still there.

Could the older version (28.2) be the cause for my problem?


Can you share what does your full log look like now?

Did you compare each log before and after you applied these changes to the cfg and kernel command line?

Honestly, your software release is really old. I am not able to remember if any steps missing or any difference in the stpes. This is a software that released almost 4 years ago.

Thanks for the quick answer!
I try to get the log printed here (currently I only see the activity with an oscilloscope due to lack of a decent level shifter hardware).

The backstory to my situation is that I have a third party hardware using a TX2 (DJI Manifold 2-G) with a DJI prepared BSP that is based on the L4T version 28.2. Unfortunately there is no newer version available at DJI right now.

So now I’m going to tinker a little hardware that I can provide you with some meaningful texts…

Please also refer to this post.

Thanks again Wayne for your extended help!

Here is the message from my board:

U-Boot 2016.07-g9c3b9a4 (May 17 2018 - 00:08:48 -0700)

Model: NVIDIA P2771-0000-500
DRAM:  7.8 GiB
MMC:   Tegra SD/MMC: 0, Tegra SD/MMC: 1
*** Warning - bad CRC, using default environment

In:    serial
Out:   serial
Err:   serial
Net:   eth0: ethernet@2490000
Hit any key to stop autoboot:  2  1  0 
MMC: no card present
switch to partitions #0, OK
mmc0(part 0) is current device
Scanning mmc 0:1...
Found /boot/extlinux/extlinux.conf
Retrieving file: /boot/extlinux/extlinux.conf
213 bytes read in 81 ms (2 KiB/s)
p2771-0000 eMMC boot options
1:	primary kernel
Enter choice: 1:	primary kernel
Retrieving file: /boot/Image
22051696 bytes read in 571 ms (36.8 MiB/s)
append: root=/dev/mmcblk0p1 rw rootwait console=none OS=l4t fbcon=map:0 net.ifnames=0 memtype=0 video=tegrafb no_console_suspend=1 nvdumper_reserved=0x2772e0000 gpt tegraid= tegra_keep_boot_clocks maxcpus=6 boot.slot_suffix= boot.ratchetvalues=0.2.1 androidboot.serialno=1422920005935 bl_prof_dataptr=0x10000@0x277040000 sdhci_tegra.en_boot_part_access=1 root=/dev/mmcblk0p1 rw rootwait rootfstype=ext4
## Flattened Device Tree blob at 92000000
   Booting using the fdt blob at 0x92000000
   reserving fdt memory region: addr=80000000 size=10000
   Using Device Tree in place at 0000000092000000, end 000000009204903c

Starting kernel ...

Obviously it’s just the u-boot, meaning the kernel is silenced.
This is more or less what I already feared by browsing this form: the switch in the .cfg file for the bootloader does not switch off the messages.
Somewhere here I found a post, where they were discussing re-compiling the bootloader as last resort.
Is that really the case?



We have multiple stages of bootloader. If you only see uboot and no other log. Which means every steps I shared to you already took effect.

Then thanks for that so far!

Do you have any idea how to silence u-boot then?

Is this then the last solution? re-compiling without CONFIG_LOG (-> If CONFIG_LOG is not set, then no logging will be available.)

See doc/README.silent in the U-Boot source. You can set some CONFIG_ variables in the board’s defconfig to force the console stdout/stderr to the null dev. You may also need to set the ‘silent’ env variable.

But this requires you to build the uboot. And you may not able to interact with uboot console again.

Honestly, I am not sure why you want to disable log on this uart. If any boot issue happened to your board , you may not able to check logs. If you just want to use uart, other uart pin could be alternative.

I’m currently in the process of compiling u-boot and of finding the correct combination of CONFIG_switches that ill finally silent the UART logging.

Compiling already works fine but I still havn’t found the correct switches, because I already (literally) set a handful of them, but still the messages are the same.

We intend to use all the UARTS available on the board to connect devices that may get confused when they receive stuff that is not meant for them. We are aware, that this reduces the possibilities of in field diagnosis but when there are problems in the final product some day, customers would have to send in the system anyway and we will have the means to switch to a bootloader with debug messages.
Since I found a couple of threads regarding the disabling of UART logging here and all around the internet for other devices, we may not be the only ones with that requirement.
Unfortunately, I haven’t found a solution that works as described and hopefully can post a git diff of u-boot here, once I figured it out…

I feel like chasing my own tail…

The good news is that I compiled u-boot to a state that it does not put out anything on UART0:

develop@dronedev:~/manifold2G_image_V0.3.3.2/Linux_for_Tegra/sources/u-boot$ git diff
diff --git a/arch/arm/mach-tegra/board186.c b/arch/arm/mach-tegra/board186.c
index 84995922a3..e5c4590e70 100644
--- a/arch/arm/mach-tegra/board186.c
+++ b/arch/arm/mach-tegra/board186.c
@@ -13,6 +13,8 @@ DECLARE_GLOBAL_DATA_PTR;
 int board_early_init_f(void)
+        gd->flags |= (GD_FLG_SILENT | GD_FLG_DISABLE_CONSOLE);
        return 0;
diff --git a/include/configs/tegra-common.h b/include/configs/tegra-common.h
index d1dac52f7c..8a18fefa1e 100644
--- a/include/configs/tegra-common.h
+++ b/include/configs/tegra-common.h
@@ -131,7 +131,14 @@
+ * disable console output
 /* Misc utility code */

Pretty straight forward if you know it…

So I had a clean boot, no messages from u-boot or kernel.
BUT, my goal is to use ttys0 in my user application so i tested it (via ssh login) with
> echo -e “blabla” > /dev/ttys0
and it didn’t work because I turned off ttsy0 in the extlinux.conf file in order to prevent the kernel boot messages from appearing.

You guess what my next question is:
How can I keep Linux system messages stop appearing during the boot process, but use the UART when the system is up and running?


What you are asking has nothing to do with disabling the kernel log to ttyS0…

Please check some resources over the internet to see if they can help you.


Thanks Wayne!

Turned out my lack in Linux knowledge made the situation more dramatic than it really was:

Since the ttyS0 has not been configured yet by the kernel for displaying its boot messages, my echo command was using an interface that probably did not have the right configuration.

When I type

stty -F /dev/ttyS0 115200
echo -e “test” > /dev/ttyS0

everything works as expected!

Again, thanks for your help and hints so that finally I could solve this task!
Consider this topic to be closed.


1 Like