Disabling combined UART in JetPack 5.1.1 on Xavier NX

Could you try to just disable the node of combined-uart in /boot/dtb/kernel_tegra194-p3668-0001-p3509-0000.dtb?

I flashed the system without making any device tree changes (which boots but is obviously lacking our customizations). I then disabled the combined-uart node in /boot/dtb/kernel_tegra194-p3668-0001-p3509-0000.dtb by setting the status=“disabled”. This boots and the /dev/ttyTCU0 device disappears. Also, the debug UART output stops after the MB1, MB2 and L4TLauncher stages (i.e. the Linux O/S is no longer using it). This is good. Now I just have to figure out why trying the same thing in the device-tree source files didn’t work the same way.

1 Like

It’s great to hear this.
Because bootloader(UEFI) and kernel use the same device tree file, it seems disabling combined-uart for UEFI may cause boot issue.
For your use case, you could also let bootloader and kernel using different dtb file by configure them in board config.

This makes a lot of sense. Thank you. I have never tried using a different dtb in the board config for the bootloader and kernel before but I will definitely look into it. In the meantime, I will try patching the dtb after making all our customizations (except those I had made to try to disable the debug UART) and see if my UART issues disappear.

You could configure them in board configuration file as following.
DTB_FILE is used for kernel
TBCDTB_FILE is used for bootloader(UEFI)

1 Like

I will be doing more testing. Unfortunately, I’ve been off unexpectedly so I am posting just to keep the topic alive.

okay, you could ask more questions about disabling combined UART here or just file another topic for DTB related issue.

So I built our full custom image and disabled the combined UART manually by patching the device tree after flashing. The system boots and the /dev/ttyTCU0 entry is gone. This solves the initial question but unfortunately the serial port is still misbehaving somehow (in terms of communication not being reliable). However, I will mark this request as resolved because the combined UART is successfully disabled. Any suggestions on why the serial port may not be reliable though would be appreciated.

What do you mean about not being reliable?
Do you mean that the data could not be sent or receive somtimes?
Have you tried to measure the waveform for this UART?

Actually, disabling the combined UART and use it as normal UART has not been verified officially and we could not guarantee the performance.

I have tried measuring the waveform. It works fine up to a random point and then suddenly seems to go tristate. I had hypothesized that some low-level process was accessing the port at the same time and confusing the UART, which is why I wanted to get rid of the combined UART which was sharing the port. However, with your help, I’ve been able to get rid of the combined UART but the problem still exists.

It’s important to know that in JetPack 4.6.3 everything works fine and the port is very reliable at 3 Mbaud, so it is not a hardware issue. It is something different between JetPack 4.6.3 and JetPack 5.1.1. Unfortunately, there are a LOT of changes between the two JetPacks, not least being a move from Ubuntu 18 to Ubuntu 20, newer Linux kernel, new bootloader, etc. so it’s hard to know where to look.

Do you know which process cause the unreliable communication?

Have you tried to disable the getty service?

$ sudo systemctl stop nvgetty.service
$ sudo systemctl disable nvgetty.service

I have tried stopping the nvgetty service to no avail, unfortunately. If I knew what was causing the issue that would be a great help.

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.