Hi!
I use Jetson TX2 with Connect Tech Orbitty carrier board and Jetpack 4.2.1.
I need to disable serial console on ttyS0 and I tried to use this: [url]https://devtalk.nvidia.com/default/topic/1025894/jetson-tx2/uart1-acts-as-default-debug-port-on-tx2-r28-1/post/5220368/#5220368[/url], but it is not working.
However, this solution worked with Jetpack 3.1.
How can I disable serial console ttyS0? Please help!
If you include a serial console boot log it would help (this would show where serial is still enabled or not, and might hint at how the third party carrier board differs from the devel board).
A lot has changed since JetPack3.1, you might also find this of interest:
https://devtalk.nvidia.com/default/topic/1030489
Keep in mind that kernel arguments now exist in a device tree, and that the device tree has to be flashed. It is true that there are still some arguments which would be accepted in “/boot/extlinux/extlinux.conf”, but many of them not. Also show a post of this output (which is the full command line and not just extlinux.conf):
cat /proc/cmdline
There is a device tree “chosen” node, and within that “bootargs”. This is what you would have to edit and flash to change most boot arguments. Most of those arguments only apply to the Linux kernel, but there is a possibility that some apply to the earlier boot stages (which is why device tree went to a partition instead of being read as a regular file…earlier stages needed this information, but can’t read an ext4 file system). A reason for including the serial console log is that it will show how much is still be ing printed from boot stages prior to Linux versus the actual Linux serial console content.
Within Linux you might try this, but I don’t know if it will change anything or work (this certainly won’t help remove logging of stages prior to the Linux kernel booting):
sudo systemctl disable nvgetty.service
Thanks for your responding!
Boot logs here:
U-Boot 2016.07-g0eb73f4 (Mar 13 2019 - 00:20:34 -0700)
TEGRA186
Model: NVIDIA P2771-0000-500
DRAM: 7.8 GiB
MC: 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: 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 95 ms (2 KiB/s)
p2771-0000 eMMC boot options
1: primary kernel
Enter choice: 1: primary kernel
Retrieving file: /boot/Image
33980424 bytes read in 853 ms (38 MiB/s)
append: root=/dev/mmcblk0p1 rw rootwait console=ttyS2,115200n8 console=tty0 OS=4
## Flattened Device Tree blob at 80000000
Booting using the fdt blob at 0x80000000
reserving fdt memory region: addr=80000000 size=10000
Using Device Tree in place at 0000000080000000, end 000000008003d177
Starting kernel ...
<hit enter to activate fiq debugger>
/boot/extlinux/extlinux.conf contains this:
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
cat /proc/cmdline shows this:
root=/dev/mmcblk0p1 rw rootwait console=ttyS2,115200n8 console=tty0 OS=l4t fbcon=map:0 net.ifnames=0 OS=l4t net.ifnames=0 video=tegrafb no_console_suspend=1 earlycon=uart8250,mmio32,0xc280000 nvdumper_reserved=0x2772e0000 gpt usbcore.old_scheme_first=1 tegraid=18.1.2.0.0 maxcpus=6 boot.slot_suffix= boot.ratchetvalues=0.983055.1 bl_prof_dataptr=0x10000@0x275840000 sdhci_tegra.en_boot_part_access=1 root=/dev/mmcblk0p1 rw rootwait rootfstype=ext4
The command sudo systemctl disable nvgetty.service did nothing.
By the way, I accidentally listened UART1 and found the serial console logs there. What??
After that I disable this “debug.enable_log=0” in tegra186-mb1-bct-misc-si-l4t.cfg and flash Jetson again and UART1 was clean.
But some boot logs still on UART0.
Was that log on ttyS0? I think it is, and comments will be under that assumption.
The logging shown is from the bootloader, not Linux. You have successfully disabled serial console from Linux ttyS0 (and moved to ttyS2). What remains is that now the bootloader is still on ttyS0.
I’m going to show a URL from changing the serial console port, but this is from a devel carrier board and an earlier release. You will need to change some parts due to carrier board differences, and perhaps also due to release version differences, but the idea will be the same. You’ve already removed serial console from ttyS0 within Linux, so you can ignore those parts. See this for bootloader stage change of serial console port:
[url]https://devtalk.nvidia.com/default/topic/1025894/jetson-tx2/uart1-acts-as-default-debug-port-on-tx2-r28-1/post/5220368/#5220368[/url]
Yeah, I made changes to tegra186-quill-p3310-1000-a00-00-base.dtb file described in
https://devtalk.nvidia.com/default/topic/1025894/jetson-tx2/uart1-acts-as-default-debug-port-on-tx2-r28-1/post/5220368/#5220368
and then flashed the DTB partition with:
sudo ./flash -r -k kernel-dtb jetson-tx2 mmcblk0p1
But no results.
Logs from bootloader still on ttyS0 :(
I have not personally tried to move the serial console, but the basic steps should be correct. Would someone else happen to know, in the case of R32.2/JetPack4.2.1, what device tree or U-Boot changes are needed which are different from [url]https://devtalk.nvidia.com/default/topic/1025894/jetson-tx2/uart1-acts-as-default-debug-port-on-tx2-r28-1/post/5220368/#5220368[/url]?
Hi linuxdev. My problem is the same with the vladushked’s, except that I use an Connect tech Elroy board and trying to install JetPack. I am a bit of a noob so I do not understand how can you change device tree and U-Boot, and also what they are. The solution i in the link you have supplied does not explain how you can change those variables. Do I need to find some files and change them, or use a software to change variables?
Each carrier board has its own device tree provided by the manufacturer. The manufacturer would have to provide the information for that carrier board. I cannot give you enough details to actually do this, but some explanation follows.
Every driver in the kernel will tend to need some specific details about how to set up hardware. Let’s say you have a common chipset for a device. The driver will be the same on all systems, but details, such as the base address, will change depending only on how the device is wired into the board. If those details were part of the driver, then you would need a different driver or code in the kernel source for every single variation in existence. It was decided to instead keep the drivers generic, and pass the information needed to the driver as the driver loads.
The device tree is a unified method of naming arguments to pass to drivers or to the kernel during boot. Keep in mind that U-Boot is itself a kernel, and its only purpose is to overwrite itself with the Linux kernel, but it is still a kernel. One device tree might be for the Linux kernel. There can be a different device tree used in bootloader stages. Sometimes the device tree is loaded directly from Linux, and sometimes earlier boot stages might pass along the device tree (with or without editing).
The device tree and how it is changed depends on whether the bootloader stages need to see it or not, depends on which L4T release you are using, depends on any kind of secure boot options enabled, and probably a lot of other details. The simplest case is that a device tree is put in “/boot” (see the “.dtb” files there), and then the “/boot/extlinux/extlinux.conf” names the device tree to use via the “FDT” key/value pair. If this is the case, then you could place your device tree in “/boot”, and simply name it via the FDT key/value pair.
In many cases it is not this simple. For example, not all releases of L4T had the ability to read an ext4 filesystem type. In that case the dtb must be in binary form in a partition (the driver can read the eMMC even if it can’t use ext4 formatting).
In cases of secure boot features, then not only must the dtb be in a partition, the partition content must also be signed by a key.
Content going into a partition requires using flash software (or “Jedi mind tricks”…in computer that’s “dd” tricks).
If flashing the content, then you’d have to put your dtb in the correct place in the flash software before flashing. Since you have a third party carrier board that information would have to come from ConnectTech. Basically it is the stock JetPack/SDK Manager software with their customizations on top of it.
Keep in mind that also, in some cases, U-Boot has some settings which cannot be controlled by device tree. In that case you would be required to actually edit the feature in the U-Boot source code, build a new U-Boot binary, and put that in place before flashing.