Hi All, I intend to use the UART on J21 on a TX2 as a standard data exchange vs Console/Debug. I used the following two links and had partial success, however, I am now stuck.
(1) Use UART1 (J21) on TX2 by disabling U-Boot console (JetPack 4.4 - L4T R32.4.3)
(2) How to use TX2 J21 as normal UART
My next step is to Disable Console over UART.
Need help to fully Disable Console over UART. The command ‘cat /proc/cmdline’ still shows ttyS0 as console.
The output for ‘head -n 1 /etc/nv_tegra_release’ is ‘R32 (release), REVISION: 4.3’
Usually that kernel parameter is in “/boot/extlinux/extlinux.conf”. You could edit that out of any line it occurs in. Do beware though that boot stages might also use the serial console, and to stop that you might end up recompiling some of the boot software. If you only care about the UART once booted, then that shouldn’t be a problem. Sometimes people use that UART that way though and find boot halts…this would be because of sending data to that UART during boot stages could be misinterpreted as a keyboard key stroke.
After the TX2 is turned on and it on for a while, I run a python code on TX2 which reads from ‘/dev/ttyS0’ and it communicates to a putty application on host computer. I send about 15 chars using the putty to the TX2 which is printed by the python code. After 15 chars, The Putty puts a message ‘login’ and the standard two way communication breaks. I use the UART from J21 for this setup.
Please note the followings:
I have my image that is flashed onto the TX2 set up such that the file ‘/boot/extlinux/extlinux.conf’ has the following content right out of the box.
APPEND ${cbootargs} quiet root=/dev/mmcblk0p1 rw rootwait rootfstype=ext4 console=tty0 fbcon=map:0 net.ifnames=0 isolcpus=1,2
Please note that the ‘console=ttyS0’ is no longer present as default setting. The output to "cat /proc/cmdline’ is as follow:
console=ttyS0,115200 androidboot.presilicon=true firmware_class.path=/etc/firmware root=/dev/mmcblk0p1 rw rootwait rootfstype=ext4 console=tty0 fbcon=map:0 net.ifnames=0 isolcpus=1-2 video=tegrafb no_console_suspend=1 earlycon=uart8250,mmio32,0x3100000 nvdumper_reserved=0x2772e0000 gpt tegra_fbmem2=0x800000@0x9607d000 lut_mem2=0x2008@0x9607a000 usbcore.old_scheme_first=1 tegraid=18.1.2.0.0 maxcpus=6 boot.slot_suffix= boot.ratchetvalues=0.2031647.1 bl_prof_dataptr=0x10000@0x275840000 sdhci_tegra.en_boot_part_access=1 quiet root=/dev/mmcblk0p1 rw rootwait rootfstype=ext4 console=tty0 fbcon=map:0 net.ifnames=0 isolcpus=1,2
In addition, the output of ‘ls -l /dev/ttyS*’ is as follow.
crw–w---- 1 root tty 4, 64 Jul 10 15:35 /dev/ttyS0
crw-rw---- 1 root dialout 4, 65 Jul 10 14:37 /dev/ttyS1
crw-rw---- 1 root dialout 4, 66 Jul 10 14:37 /dev/ttyS2
crw-rw---- 1 root dialout 4, 67 Jul 10 14:37 /dev/ttyS3
I do the same exact set up using J17 and get a continuous communication. For some reason, I have failed to disable /dev/ttyS0, since it is configured to tty.
I noticed that for some reason the following messages show up on the Putty application on the host after 15 chars are exchanged between the applications. Please note that my python code does not initiate that:
Ubuntu 18.04.6 LTS dummy-desktop ttyS0
dummy-desktop login:
Hi fa.arad,
I have to note that the debug UART is a combined UART, which means it output log from several firmwares. As linuxdev mentioned, many firmwares(e.g. MB1, MB2, bpmp, spe..etc) may output log to this port and you can not disable them completely. If your UART use case can work after boot up, you can try the following methods to disable it from kernel.
quiet to above kernel command line$ sudo systemctl stop nvgetty.service
$ sudo systemctl disable nvgetty.service
Please check if above methods can help you using this UART interface after boot up.
If you still hit any issue, please share the full dmesg and device tree for further check.
Thank you for the feedback. The steps below are taken and the results stayed the same. About 15 chars into the communication between my python code on TX2 and Putty on the host, some service from the TX2 sends a login request as presented above.
quiet to above kernel command line$ sudo systemctl stop nvgetty.service
$ sudo systemctl disable nvgetty.service
I ran the additional command and the results are provided. Highlighted the interesting points.
[ 0.000000] Kernel command line: console=ttyS0,115200 androidboot.presilicon=true firmware_class.path=/etc/firmware root=/dev/mmcblk0p1 rw rootwait rootfstype=ext4 console=ttyS0,115200n8 console=tty0 fbcon=map:0 net.ifnames=0 isolcpus=1-2 video=tegrafb no_console_suspend=1 earlycon=uart8250,mmio32,0x3100000 nvdumper_reserved=0x2772e0000 gpt tegra_fbmem2=0x800000@0x9607d000 lut_mem2=0x2008@0x9607a000 usbcore.old_scheme_first=1 tegraid=18.1.2.0.0 maxcpus=6 boot.slot_suffix=_b boot.ratchetvalues=0.2031647.1 bl_prof_dataptr=0x10000@0x275840000 sdhci_tegra.en_boot_part_access=1 quiet root=/dev/mmcblk0p1 rw rootwait rootfstype=ext4 console=tty0 fbcon=map:0 net.ifnames=0 isolcpus=1,2
[ 1.019557] console [ttyS0] disabled
[ 1.019593] 3100000.serial: ttyS0 at MMIO 0x3100000 (irq = 36, base_baud = 25500000) is a Tegra
[ 1.019627] console [ttyS0] enabled
**serial@3100000** {
compatible = "nvidia,tegra20-uart", "nvidia,tegra186-hsuart";
clocks = <0x10 0x37 0x10 0x10d>;
nvidia,adjust-baud-rates = <0x1c200 0x1c200 0x64>;
console-port;
clock-names = "serial", "parent";
sqa-automation-port;
nvidia,tolerance-low-range = <0x0>;
nvidia,tolerance-high-range = <0x4>;
status = "okay";
interrupts = <0x0 0x70 0x4>;
dma-names = "rx", "tx";
phandle = <0x103>;
nvidia,memory-clients = <0xe>;
reg = <0x0 0x3100000 0x0 0x40>;
iommus = <0x11 0x20>;
dmas = <0x25 0x8 0x25 0x8>;
reg-shift = <0x2>;
linux,phandle = <0x103>;
};
Any feedback is appreciated. I am reading through the Jetson’s TX2 forum for additional things to look at.
You can see the actual final kernel command line via:
cat /proc/cmdline
You should only need to issue the systemctl stop nvgetty.service and systemctl disable nvgetty.service once. If you’ve done this, reboot, and in addition to noting what cmdline shows, run this command:
systemctl status nvgetty.service
Incidentally, unless someone is shipping a unit to the customer, I advise always removing “quiet” from extlinux.conf.
Thank you @linuxdev for your feedback. My issue of disabling TX2’s UART on J21 persists. It is partially working, since Puttyy on the host can exchange about 15 chars with a python code on TX2, however some service/server on TX2 sends a ‘login’ message and interrupts the desired communication. Actual message is below:
Ubuntu 18.04.6 LTS dummy-desktop ttyS0
dummy-desktop login:
I think that we got a winner. Red in some documentation to stop/disable serial-getty@ttyS0.service as well.
$ sudo systemctl stop nvgetty
$ sudo systemctl disable nvgetty
$ sudo systemctl stop serial-getty@ttyS0.service
$ sudo systemctl disable serial-getty@ttyS0.service
I was able to send a few hundred messages back and forth for now. Will continue to test.
Good catch, I have not noticed that before. It makes me wonder what changed this as serial-getty!
Another question regarding the TX2’s UART on J21. It’s default baud rate is 115200, so it works fine with that rate. which means that I can do data exchange between the putty (baud rate of 115200) on host and python (baud rate of 115200) on TX2. However, after I change the code to configure the /dev/ttyS0 to 921600 both on the putty (host) and my python (TX2), the data exchange hangs after a while.
You may need to configure its parent clock to be compatible for other baud rate.
Please add a bit of more detail on the ‘configure its parent clock to be compatible for other baud rates’. Found an example in Changing UARTC parent clock frequency.
TX2 has a bug within the baud rate generator, which exceeds the allowable 4% tolerance.
Don’t go over 115200 bps.
Use two stop bits for better fault tolerance.
Please check the following node:
# cat /sys/kernel/debug/bpmp/debug/clk/uartc/parent
# cat /sys/kernel/debug/bpmp/debug/clk/uartc/rate
# cat /sys/kernel/debug/bpmp/debug/clk/uartc/max_rate
Or you can just refer to the info in the link you provided.
This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.