Greetings,
For the past few days I have been attempting to use the ttyS0 port for regular UART commnication. The issue is the fact that unlike ttyTHS2, this port is reserved for serial debugging console.
Before doing anything, when i was connecting the RX and TX pins to each other and sending a “hello world” message over this network, i was getting garbage messages alongside what I had initially sent. Also, the RX and TX pins being connected to each other during system startup was causing the system to hang with black screen instead of booting normally. “cat /proc/cmdline” was also containing a message that was stating that ttyS0 is serial debugging port.
Here are some of the fixes I have attempted:
- Disabling getty and nvgetty, this has not helped with anything.
- I messed with some configuration files and changed the “console=ttyS0,115200n8 console=tty0” lines I found with with “console=tty0” in my Linux_for_Tegra folder. Afterwards, I flashed with “sudo ./flash -r -k kernel-dtb jetson-tx2i mmcblk0p1”. Initially I thought this had fixed the issue. I am no longer seeing garbage messages with the “hello world” messages I am sending through this network, which is when Linux is up and running. Additionally “cat /proc/cmdline” is no longer containing traces of ttyS0. However, when the RX and TX pins are connected to each other, the system still hangs at startup with black screen… Since I intend to use it for a headless system that is meant to operate without human intervention, it is out of question for me to make the connections after the boot process.
- I’ve had a look at the 3rd last message here: UART1 acts as default debug port on TX2, R28.1 - #12 by JerryChang . However, I could not understand well how to carry out the changes outlined. What software would I need for them? Is it something other than the regular flashing procedure? Would they be useful on newer L4T?
I think I have alse read up about something regarding re-compiling the device tree. What relevant guide can I follow to de-activate serial debugging console this way? Might it have something to do with 3rd party BSP (I assume this to be unlikely).
Platform: Jetson TX2i
L4T Version: 32.2.3
Carrier Board: Connect Tech Orbitty Carrier
Thank you in advance.
The issue you are running into is that there are two separate programs which use the serial console, not one. The program you know about and have adjusted for is the Linux kernel. The part you missed is that the bootloader software which runs prior to Linux is its own separate program, and whatever you change in Linux won’t have any effect on the bootloader which runs before it.
The documentation may differ depending on which L4T release you use (see “head -n 1 /etc/nv_tegra_release”). You can find the “Developer Guide” for your specific release. Releases are listed here:
https://developer.nvidia.com/linux-tegra
An example where disabling serial console is found:
https://docs.nvidia.com/jetson/archives/l4t-archived/l4t-3243/index.html#page/Tegra%2520Linux%2520Driver%2520Package%2520Development%2520Guide%2Fkernel_boot_time.html%23wwpID0E0YB0HA
Is the last link you have sent regarding how to disable serial console during bootloader, the one I have not managed to disable yet? It talks about making modifications in the “p2771-000.conf.common” file, which resides somewhere in my Linux_for_Tegra folder, which is on my host computer and not on my TX2i system. After carrying out the mentioned change, what needs to be done next? Do I flash again, if yes, using which command line? If no, what needs to be done so that the mentioned changes take effect?
Or is the method for disabling ttyS0 during bootloader dependent on L4T version and is in the Developer Guide that you have linked, and I will have to dig deep into it in order to find what I want?
Edit: I think I have found the relevant guide to follow, this is what I need to follow in order to make the changes in the “p2771-000.conf.common” file take place, yes? https://docs.nvidia.com/jetson/l4t/index.html#page/Tegra%20Linux%20Driver%20Package%20Development%20Guide/uboot_guide.html#
Yes. See " Disable Console over UART".
I believe the p2771 is the TX2 series module, and probably applies to a TX2i as well. The other numbers, if non-zero, would imply a particular carrier board. So the “p2771” content is used when configuring some boot content when a TX2 module is involved. This means that for the changes to take place from an edit you would indeed have to flash.
Most of the disabling of ttyS0 is the same for quite some time, but there is some difference at times with different L4T release versions, and also with different variants of a give Jetson module. That particular information is probably correct for most any semi-recent L4T release, but you are always advised to use the information given with your particular L4T release. The gist is that to change bootloader behavior you probably do have to flash, and this is what the documents describe doing.
The URL you mention is for the most recent R32.5. Quite likely it has mostly the same information so far as serial console disable. I would start with that URL using the search “Disable Console over UART”.
I have done the following things, and here are their results:
- I have replaced the “console=ttyS0,115200n8 console=tty0” text in the config file with “console=tty0” and flashed the board using the command “sudo ./flash.sh -r jetson-tx2i mmcblk0p1” existing system.img is being used. This has changed the fact that during start-up I am no longer seeing the text, I am directly being forwarded to the user log-in screen straight-away. However, this is unfortunately still not preventing the boot from hanging-up when RX and TX of ttyS0 are connected together.
- I have completely removed the “console=***” part instead of replacing it with something else, the boot screen with white text on black background does show up in this case.
- After I backed up my existing system.img, I tried flasing using “sudo ./flash.sh jetson-tx2i mmcblk0p1”, in other words, without the “-r” option. This option has bricked the system, making it unable to boot, so I rolled back by restoring system.img to its proper place and using “sudo ./flash.sh -r jetson-tx2i mmcblk0p1” again.
What would you suggest me to try/do next? Did I miss something or do something wrongly?
Note: The guide tells me to make modifications on “p2771-000.conf.common”, however, there is only “p2771-0000.conf.common” instead, I just assume it is a typo on the guide.
Just to explain how this might or might not do what you really want I’ll comment on the “-r” option. During normal flash the software will create a rootfs image based on a combination of what is in “Linux_for_Tegra/rootfs/” and command line arguments. Basically, some minor options which go in “extlinux.conf” would be edited based on flash command line arguments, and then the actual image generated and placed within “Linux_for_Tegra/bootloader/”. When you use “-r” this implies that whatever image was already in “bootloader/” will be used and not regenerated. If it happens that on a previous flash the image there had the undesired “console=ttyS0,115200n8”, then this gets flashed again. If you flash multiple systems in a row and plan on the same rootfs, then this is a big time saver, but if you wanted to avoid your Jetson’s rootfs flashing, this won’t work.
If before using “-r” you had already performed a flash which had the unwanted “console=ttyS0,115200n8”, then you would have succeeded and done what you wanted. The acid test is that after booting you don’t see the “console=ttyS0,115200n8” in a “cat /proc/cmdline”, then by whatever method you used worked.
Note that if “console=ttyS0,115200n8” is in the device tree’s “chosen->bootargs” node, and if you did not override that with an FDT key/value pair in extlinux.conf, then this will show up again since earlier boot stages will use the partition’s tree for this and only flash would update the partition version of the device tree.
When you change a “.conf” file, then this should also change in the device tree. If this is correctly done, then when you look at the device tree’s “chosen->bootargs”, then you will find the “console=ttyS0,115200n8” is missing from:
cat /proc/device-tree/chosen/bootargs
(FYI, in extlinux.conf, this is what fills the environment variable “${cboot}”)
So questions are:
- Did you really want to use “
-r” to keep your old rootfs? If so, then this won’t work as you want unless the old rootfs is an exact match to the previously flashed rootfs.
- Does your change show up as valid when comparing to:
cat /proc/device-tree/chosen/bootargs
cat /proc/cmdline
- Do you have an “
FDT” entry naming your device tree in “extlinux.conf”?