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?
bootloader/t186ref/BCT/tegra186-mb1-bct-misc-si-l4t.cfg
and bootloader/tegra186-mb1-bct-misc-si-l4t.cfg
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?
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:
rootfs/boot/extlinux/extlinux.conf
TIMEOUT 30
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…
U-Boot 2016.07-g9c3b9a4 (May 17 2018 - 00:08:48 -0700)
TEGRA186
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=18.1.2.0.0 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?
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…
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?
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.