tx2 hangs with some HDMI monitors

Autonomous Machines Jetson & Embedded Systems Jetson TX2
1

We have a tx2 eval board and our own similar board.
With both boards, if we connect the customer’s monitor,
the boot process hangs very early on

[    0.000000] Boot CPU: AArch64 Processor [411fd073]
[    0.000000] earlycon: Early serial console at MMIO32 0x3100000 (options '')
[    0.000000] bootconsole [uart0] enabled
(HANGS HERE)

If we let them boot without the monitor, it isn’t recognized.
If we boot with a different monitor, then switch to the customer’s
monitor it will work.

I can read the edid from the monitor when connected to a (Centos-7) laptop.

a) Any idea how I can make it not hang in the boot process so I can debug?

b) Any idea why the monitor isn’t being recognized?

Thanks in advance,

Cary

2

It must be the most discussed topic on this forum! ;-)
If you are using the L4T 28.1 kernel, try the following patches to see if they help you to get it going:
[url]HDMI issue - question for WayneWWW... - Jetson TX2 - NVIDIA Developer Forums

-albertr

3

For the monitor which is an issue you may want to connect it after boot (with no previous monitor) and post the content from:

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

Before plugging in the monitor you might want to run “dmesg --follow” and see what shows up (using ssh login or serial console).

4

Please paste some debug message according to this wiki page.
https://elinux.org/Jetson_TX2/r28_Display_debug

#Print out display kernel related message
dmesg |grep tegradc
#Print current mode in dc
sudo cat /sys/kernel/debug/tegradc.X/mode  #X=0,1,2.
#Print current mode in fbcon
sudo cat /sys/class/graphics/fb0/mode  #if more than one fb, just change the fbX to whatever you want.
#Capture edid
sudo cat /sys/kernel/debug/tegradc.X/edid  #X=0,1,2.

Since you cannot boot up, please boot up device first without hdmi connection, then hotplug hdmi.

Are you using rel-28.1 or rel-28.2 DP?

5

We’re ok for now, but I’ll outline what we ended up doing.

a) I applied the patch provided by WayneWWW found here,

it prevented the boot hangup.

b) The monitor vendor suggested that we replace the edid in the monitor
with a known good edid. We got an adapter/emulator that let us do this
and now the nvidia video system and x driver can see the modes (i.e xrandr --verbose)
shows all the modes. Not sure I agreed with this but we were in a hurry.

c) The problem was made more complex because I believe we have some marginal
wiring or cabling. The monitor is now solid on lower resolutions, but erratic
on higher resolutions.

d) I did attempt to move to the 28.2 release. There wasn’t any hang at boot but
the resolution was stuck on very low (vga) resolution, xrandr didn’t show any
other resolutions, so we gave up on that approach for now.

I did capture the EDID information for the monitor that was giving us problems.

# cat /sys/kernel/debug/tegradc.0/edid
 00 ff ff ff ff ff ff 00 1c 83 80 10 00 00 00 00
 29 1b 01 03 80 00 00 78 e6 2e e4 a4 57 4a 9c 25
 11 50 54 ff ff 80 d1 c0 81 80 61 4f 8b c0 a9 c0
 45 40 01 01 01 01 94 43 80 90 72 38 26 40 80 d0
 13 00 e0 20 11 00 00 1e 00 00 00 10 00 00 00 00
 00 00 00 00 00 00 00 00 00 00 00 00 00 10 00 00
 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 10
 00 00 00 00 00 00 00 00 00 00 00 00 00 00 01 2d
 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 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

Thanks, for the help. I will try and post anything more we find.

Cary

6

If you want to explore this again you may want to add this to the Section “Device” of “/etc/X11/xorg.conf”:

Option   "ModeDebug"

…then reboot and get a copy of “/var/log/Xorg.0.log”. The driver will tell you all EDID modes it knows about and why the other EDID modes are rejected.