Jetson TX2 NX UART issue

Autonomous Machines Jetson & Embedded Systems Jetson TX2
,
1

Hello,

We are using a custom carrier for the Jetson TX2 NX modules, running the latest L4T 4.6 and are trying to access the UART interface on pins 203 and 205. The interface however is unavailable which made us turn to these forums.
Some topics on this forum e.g. https://forums.developer.nvidia.com/t/tx2-nx-uart-not-work-jetpack4-5-1/177919 refer to adjusting two .dtb files and reflashing the bpmp and kernel-dtb files.

We have pursued this but the status of serial@c280000 remains disabled at runtime although the .dtb files after decompiling say it’s status is “okay”. We have tried both placing the tegra186-bpmp-p3636-0001-a00-00.dtb file on the host machine in the …/Linux_for_Tegra/bootloader and the …/Linux_for_Tegra/bootloader/t186ref folders.

Is there something we are missing or do we need to adjust something else before this would work?

Best regards

2

Any difference at all from the dev kit carrier means differences in device tree. This includes power rails. I couldn’t help you with a custom carrier device tree, but as a check, export the running device tree and look at the mentioned serial node and any power rail related to it, then compare to see if your changes actually made it in to place (there is more than one way a dtb can be installed, make sure your changes actually took place):
dtc -I fs -O dts -o extracted.dts /proc/device-tree
(if you don’t have dtc there, then “sudo apt-get install device-tree-compiler”)

Additionally, anyone who can actually help you with custom trees will want to see the full serial console boot log. It is very difficult to help without that log (serial console includes logging about power rails and other setup even before the Linux kernel loads…dmesg is quite useful, but it is only a subset of startup logging).

3

Hi,

I forgot that although we have a custom carrier, these device tree modifications have been run on a dev-kit carrier. I just performed an full flash of a TX2 NX module with the adjusted .dtb files and the result are the same. The status of serial@ c280000 remains disabled

When decompiling the entire device tree as you mentioned a few entries can be found:

uartc = "/serial@c280000";

serial2 = "/serial@c280000";

	serial@c280000 {
		compatible = "nvidia,tegra186-hsuart";
		clocks = <0x10 0xd7 0x10 0x10d>;
		resets = <0x10 0x31>;
		nvidia,adjust-baud-rates = <0x1c200 0x1c200 0x64>;
		clock-names = "serial", "parent";
		nvidia,tolerance-low-range = <0x0>;
		nvidia,tolerance-high-range = <0x4>;
		status = "disabled";
		interrupts = <0x0 0x72 0x4>;
		dma-names = "rx", "tx";
		phandle = <0x101>;
		nvidia,memory-clients = <0xe>;
		reg = <0x0 0xc280000 0x0 0x40>;
		iommus = <0x11 0x20>;
		dmas = <0x22 0x3 0x22 0x3>;
		reg-shift = <0x2>;
		reset-names = "serial";
		linux,phandle = <0x101>;
	};

I do realize that the status is disabled which would explain why that serial interface is not working/disabled when running cat status. It just doesn’t make sense to me since I adjusted (and checked) the files on the host machine: tegra186-p3636-0001-p3509-0000-a01.dtb, tegra186-bpmp-p3636-0001-a00-00.dtb and even kernel_tegra186-p3636-0001-p3509-0000-a01.dtb

You may find the entire decompiled .dts in the attachment: extracted.dts (241.3 KB)

Since it might also help, this is the output of the dmesg: dmesg | grep tty [ 0.000000] Kernel command line: console=ttyS0,115200 root=/dev/mmcblk0p1 rw rootwait rootfstype=ext4 console=ttyS0,115200n8 console=tty0 fbcon=map:0 net.ifnames=0 isolcpus=1-2 video=tegrafb earlycon=uart8250,mmio32,0x3100000 nvdumper_reserved=0x1772e0000 gpt rootfs.slot_suffix= usbcore.old_scheme_first=1 tegraid=18.1.2.0.0 maxcpus=6 no_console_suspend boot.slot_suffix= boot.ratchetvalues=0.2031647.1 vpr_resize bl_prof_dataptr=0x10000@0x175840000 sdhci_tegra.en_boot_part_access=1 quiet root=/dev/mmcblk0p1 rw rootwait rootfstype=ext4 console=ttyS0,115200n8 console=tty0 fbcon=map:0 net.ifnames=0 isolcpus=1-2 [ 0.000944] console [tty0] enabled [ 0.942389] console [ttyS0] disabled [ 0.942425] 3100000.serial: ttyS0 at MMIO 0x3100000 (irq = 33, base_baud = 25500000) is a Tegra [ 0.942465] console [ttyS0] enabled [ 0.944572] 3110000.serial: ttyTHS1 at MMIO 0x3110000 (irq = 34, base_baud = 0) is a TEGRA_UART [ 0.945363] 3130000.serial: ttyTHS3 at MMIO 0x3130000 (irq = 35, base_baud = 0) is a TEGRA_UART [ 7.672330] Please complete system configuration setup on the serial port provided by Jetson's USB device mode connection. e.g. /dev/ttyACMx where x can 0, 1, 2 etc.

4

If the above was not changed to “okay”, then I’d expect the port to not work. If you changed it to “okay”, but status remains “disabled”, then I’d think that your device tree modification was never used (and then you’d have to consider installing the tree to a partition versus via the FDT key/value entry pointing at a file). The point is that when you make a change to the device tree, that since there is more than one way to install such a tree, and since one takes precedence over the other, that you need to verify any changes to the tree were actually installed. I suspect something is going on with the loading of the device tree which has not been accounted for.

A full serial console boot log would mention details about device tree loading. You’d have to find out if your tree is being loaded correctly before anyone could comment on the validity of the tree. Note that your “dmesg” is hard to follow due to formatting. If you add a line all by itself just above that log (you can edit your post with the “pencil” icon), and also the same line below the data, then formatting will be preserved and scrollbars will be added (three backquotes, which are the unshifted key which has the tilde at the top left of the keyboard):
```

Better yet, a serial console boot log includes logging from prior to Linux ever loading. Some device tree information is contained in such a log, along with what is essentially the entire dmesg. I’d suggest attaching a serial console boot log.

5

Appearantly, starting of with the L4T that you get when using the NVidia SDK Manager is not the way to go. Today I started with a fresh L4T from the website, adjusted both the bpmp and the kernel dtb files and performed a full flash. To my surprise the status of serial@c280000 is now okay and another ttyTHS device has popped up under /dev.

A full serial console boot log would mention details about device tree loading. You’d have to find out if your tree is being loaded correctly before anyone could comment on the validity of the tree. Note that your “dmesg” is hard to follow due to formatting. If you add a line all by itself just above that log (you can edit your post with the “pencil” icon), and also the same line below the data, then formatting will be preserved and scrollbars will be added (three backquotes, which are the unshifted key which has the tilde at the top left of the keyboard)

I will keep that in mind for new posts, thank you for helping me out!