How to change configuration of UART1 ?

Autonomous Machines Jetson & Embedded Systems Jetson TX2
#1

Hi All,

I am using a custom board and I connected it to my monitor. But there was no GUI output on the screen.
I read several posts in which it was suggested to play around with the UART 1 configuration i.e. enable pull-up and pull-down to fix this issue.
My understanding is- in order to change the configuration of the UART1, the device tree has to be updated.

Could you please let me know how to get started with this?

PS: I come from a bare-metal background and I am just getting started with Linux embedded systems. So please bear with me.

Best
Siddharth.

#2

About the missing display
is your display purely HDMI? If there is any VGA component, then it isn’t possible for automatic configuration to work (you’d have to get lucky with a default mode).

Do you have ssh or serial console access? If so, see what you get from:

sudo -s
cat `find /sys -name 'edid'`
exit

For UART:

You can extract the current running system’s device tree like this:

dtc -I fs -O dts -o extracted.dts /proc/device-tree

If you were to edit this and turn it back into a binary format useful with flash software it would go something like this after editing the extracted.dts:

dtc -I dts -O dtb -o modified.dtb extracted.dts

Steps used to install the tree depend on what release you are using. You might want to check the official documentation. The specific L4T release will have something for you, but the general document page is here:
https://developer.nvidia.com/embedded/downloads

Some documentation specific to the current L4T release is here:
https://developer.nvidia.com/embedded/linux-tegra

Note that UART drivers for a Jetson have both a regular serial driver available, and also a DMA-capable driver. You will see references in the device tree to which drivers are compatible (literally, the “compatible =” entry), and the ones with “-uart” are ordinary drivers, while the DMA-capable ones are “-hsuart” (High Speed UART). Normally one would access all of the 16450/16550 style UARTs as “/dev/ttyS#”, e.g., the serial console is “/dev/ttyS0”. You will see the HS UART equivalent as well, e.g., the dev board connector J17 is “/dev/ttyTHS2”
had this been used as a regular driver you would access it as “/dev/ttyS2”. You will want to use only the THS# entry if possible. The reason the “ttyS0” is used for serial console is to allow for continuity of service when transitioning from bootloader to the Linux kernel (there is no HSUART driver in U-Boot and changing the driver during boot would mean lost console text).

FYI, you can have multiple drivers shown in the “compatible” entry, but it is up to the kernel to pick and use one at a time.

You will find the TRM (Technical Reference Manual is available in the downloads URL I gave above) refers to groups of certain functions as belonging to a single controller. An example is GPIO where a single controller has many GPIO pins. As more GPIO is added, instead of making one bigger GPIO controller, you will get multiple controllers with each controller being an exact duplicate of the other
but the base address determines which group of GPIO is being looked at (the code to use any controller is identical other than the base address). The UARTs are the same, and the device tree entry to determine which UART you are working with in the tree goes by base address. For example, “serial@3110000” is one UART controller.

Within “/sys” you will find controllers have many ways of accessing them, but the base address will be useful there. If you knew you were looking for serial controller at 3110000, then this would give you some clues:

sudo find /sys -name '*3110000*'

(fyi, you need sudo to get root permission before you can go to “/sys”
you can drop into a root shell with “sudo -s”, and then later “exit” the shell)

1 Like
#3

Hi LinuxDev,

Thanks for the answer.Below is the EDID and yes I am using HDMI.

00 ff ff ff ff ff ff 00 22 f0 83 31 01 01 01 01
 25 1b 01 03 80 30 1b 78 2a 43 f5 a7 56 53 9c 26
 10 50 54 a1 08 00 d1 c0 81 c0 a9 c0 b3 00 95 00
 81 80 81 00 01 01 02 3a 80 18 71 38 2d 40 58 2c
 45 00 dc 0c 11 00 00 1e 00 00 00 fd 00 32 3c 1e
 50 11 00 0a 20 20 20 20 20 20 00 00 00 fc 00 48
 50 20 32 32 63 77 61 0a 20 20 20 20 00 00 00 ff
 00 36 43 4d 37 33 37 30 37 32 4b 0a 20 20 01 ed
 02 03 19 b1 49 90 1f 04 13 03 02 12 11 01 67 03
 0c 00 10 00 00 22 e2 00 2b 02 3a 80 18 71 38 2d
 40 58 2c 45 00 dc 0c 11 00 00 1e 02 3a 80 d0 72
 38 2d 40 58 2c 45 00 dc 0c 11 00 00 1e 00 00 00
 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 f7

So according to your answer, if I have to enable the pull-ups or pull-downs I will have to modify the device tree. Right?

#4

I can’t answer some of your specific questions, I have not worked on a custom board. I can only suggest to post a copy of your current device tree, rename it with a “.txt” suffix, and attach it here (you can add an attachment to an existing post by hovering your mouse over the quote icon in the upper right of the post, noting the “paper clip” icon which then shows, and clicking on the “paper clip”).

If you know which base address corresponds to your UART, then someone should be able to tell you what changes are needed in that device tree, and whether pull-up/down options exist within that tree (or if it has to be a hardware solution).

FYI, your monitor seems fairly “plain vanilla” and the EDID is valid. Is this the default unflashed Jetson? What is “head -n 1 /etc/nv_tegra_release”? Are all files “ok” when running:

sha1sum -c /etc/nv_tegra_release
#5 
sha1sum -c /etc/nv_tegra_release

gives all “ok”

The release is- R28 (release), REVISION: 2.0, GCID: 10567845, BOARD: t186ref, EABI: aarch64, DATE: Fri Mar 2 04:57:01 UTC 2018

I have attached the device tree from /proc/device-tree.

devicetree.txt (390 KB)

#6

R28.2 should be good with respect to most video issues. If you add this to increase logging for the GUI the driver will explain what it thinks of each mode the monitor is capable of
put this in the ‘Section “Device”’ of “/etc/X11/xorg.conf”:

Option    "ModeDebug"


then reboot and paste a copy of “/var/log/Xorg.0.log” here (you could rename it to be “.txt” file extension).

Can someone who knows custom board setup look at the device tree in the previous post and see what it might need for the UART?

#7

Thanks for the prompt response linuxdev. I have attached the logs. I have done this step before, when I was trying to go through the suggestion you have made on other threads. My output is similar to them i.e. at the end of the logs it says “Failed to set the display configuration.”

logs.txt (268 KB)

#8

Here is an excerpt of the log showing many valid modes:

16.509] (II) NVIDIA(0): Virtual screen size determined to be 1920 x 1080
[    16.509] (II) NVIDIA(0): Adding implicit MetaMode: "HDMI-0: 1920x1080_60_0"
[    16.509] (II) NVIDIA(0): Adding implicit MetaMode: "HDMI-0: 1920x1080_60_1"
[    16.509] (II) NVIDIA(0): Adding implicit MetaMode: "HDMI-0: 1920x1080_60_2"
[    16.509] (II) NVIDIA(0): Adding implicit MetaMode: "HDMI-0: 1920x1080_50"
[    16.509] (II) NVIDIA(0): Adding implicit MetaMode: "HDMI-0: 1920x1080_50_0"
[    16.510] (II) NVIDIA(0): Adding implicit MetaMode: "HDMI-0: 1680x1050"
[    16.510] (II) NVIDIA(0): Adding implicit MetaMode: "HDMI-0: 1600x900"
[    16.510] (II) NVIDIA(0): Adding implicit MetaMode: "HDMI-0: 1440x900"
[    16.510] (II) NVIDIA(0): Adding implicit MetaMode: "HDMI-0: 1280x1024"
[    16.510] (II) NVIDIA(0): Adding implicit MetaMode: "HDMI-0: 1280x800"
[    16.510] (II) NVIDIA(0): Adding implicit MetaMode: "HDMI-0: 1280x720"
[    16.510] (II) NVIDIA(0): Adding implicit MetaMode: "HDMI-0: 1280x720_60_0"
[    16.510] (II) NVIDIA(0): Adding implicit MetaMode: "HDMI-0: 1280x720_60_1"
[    16.510] (II) NVIDIA(0): Adding implicit MetaMode: "HDMI-0: 1280x720_50"
[    16.510] (II) NVIDIA(0): Adding implicit MetaMode: "HDMI-0: 1024x768"
[    16.510] (II) NVIDIA(0): Adding implicit MetaMode: "HDMI-0: 800x600"
[    16.511] (II) NVIDIA(0): Adding implicit MetaMode: "HDMI-0: 720x576"
[    16.511] (II) NVIDIA(0): Adding implicit MetaMode: "HDMI-0: 720x480"
[    16.511] (II) NVIDIA(0): Adding implicit MetaMode: "HDMI-0: 720x400"
[    16.511] (II) NVIDIA(0): Adding implicit MetaMode: "HDMI-0: 640x480"
[    16.511] (II) NVIDIA(0): Adding implicit MetaMode: "HDMI-0: 640x480_60_0"
[    16.511] (II) NVIDIA(0): Adding implicit MetaMode: "HDMI-0: nvidia-auto-select { ViewPortIn = 1366 x 768, ViewPortOut = 1920 x 1079 + 0 + 0 }"

Note that the single nvidia-auto-select mode still ends up failing:

[    16.594] (II) NVIDIA(0): Setting mode "DFP-0:nvidia-auto-select"
[    17.830] (EE) NVIDIA(0): Failed to set the display configuration.

This might be a bug since auto-select is only seeing a mode it rejects despite having several modes to choose from. I can only speculate, but the “ViewPortOut” is scaling to “1920 x 1079” instead of an exact “1920 x 1080”. In the past I’ve heard of cases where some sort of rounding error causing a mode to barely miss. The failure to set the display configuration messages which occur after this all say “x 1080”, not “x 1079”.

For the GUI issue, would someone at NVIDIA comment if the “1920 x 1080” is being chosen in some places (the mode is valid), but then fails to actually set the value due to rounding error (“1920 x 1079” was rejected earlier, and is apparently what nvidia-auto-select chose to use
auto-select would have no reason to look at other valid values because it was told this value is valid).

If possible perhaps someone could also comment on the setup required in reply #5’s device tree for the UART setup of his custom board.

#9

The issues here sound similar to these ones, is it correct?
https://devtalk.nvidia.com/default/topic/1027467
https://devtalk.nvidia.com/default/topic/1031399/

#10

@WayneWWW yes that is correct.
I got similar error messages as in the https://devtalk.nvidia.com/default/topic/1027467 but not like the latter one.

#11

@WayneWWW,

Could you please help me with the fix, my initial question is- how to restore the UART1 to its default state. None of the threads have stated the solution to this problem.

#12

siddharthchawla01,

Sorry that I didn’t catch the current status. The cause of this issue is due to carrier board enable the UART1_TX PIN before the core reset during power-on.

If you don’t want to change your hardware


Make below change to bpmp dtb and reflash
File: tegra186-a02-bpmp-quill-p3310-1000-c01-00-te770d-ucm2.dtb from Linux_for_Tegra/bootloader/ folder
convert to dts :
dtc -I dtb -O dts tegra186-a02-bpmp-quill-p3310-1000-c01-00-te770d-ucm2.dtb > tegra186-a02-bpmp-quill-p3310-1000-c01-00-te770d-ucm2.dts

make change as below
emc-strap {
select = <0x9 0xa 0xa 0xa>;
};

and rebuild the dtb using
dtc -I dts -O dtb tegra186-a02-bpmp-quill-p3310-1000-c01-00-te770d-ucm2.dts > tegra186-a02-bpmp-quill-p3310-1000-c01-00-te770d-ucm2.dtb

and reflash.
Make sure you are flashing this particular dtb. this will come in your host side flashing log.

Full story behind this patch is in this link:
https://devtalk.nvidia.com/default/topic/1009011/jetson-tx2/kernel-4-4-drivers-platform-tegra-mc-isomgr-c-isomgr_init-fails-to-initialize/2

#13

Hi Wayne,

I modified the device tree as you suggested. And it didnt work. The flash logs stated that the device tree being used is c04 instead of c01. I later changed that too, to see if that works. But, it didnt.

I have attached the flash logs from my host.

Question- How should I verify that the changes have been made to Jetson?
flash_os_tx2.txt (415 KB)

#14

siddharthchawla01,

Please take a look at your flash config. The “BPFDTB_FILE” is the one that your bpmp dtb is using.

#15

Could you please help me where are they located?

#16

The flash config is the one you use when running flash.sh.

For example, the one for tx2 is under your jetpack folder-> Linux_for_tegra/jetson-tx2.conf.

#17

Hi Wayne,

I updated the device tree which was listed in the jetson-tx2.conf. However, there is still no GUI output. Also, I tried different methods of flashing the TX2. Initially, I was using the Jetpack Installer to flash the device and later I switched to these steps to reflash it-
https://devtalk.nvidia.com/default/topic/1012364/jetson-tx2/how-to-flashing-jetson-tx2-and-setup-network-correctly-/

Could you help me if there is any other way to verify it? I extracted the device tree from the /proc but I couldn’t find the changes.

#18

siddharthchawla01,

I don’t intend to make this problem more complicated. However, the emc strap change dtb is for bpmp. So it would not show in the /proc/device-tree.

If you confirm that your new dtb put under Linux_for_tegra/bootloader is correct, I think you should review your hardware design.

UART1_TX and UART0_RTS must not be driven or pulled high or low during power-on.

#19