No HDMI monitor after updating to 28.2

Hi,
I’d appreciate some help in figuring out why my monitor doesn’t display anything at all after flashing 28.2 on a TX2 dev board. It doesn’t even show the console during boot.

I can ssh to the TX2 without problem and the EDID of the monitor is detected properly and valid. I’m not very proficient in linux admin, but I tried to follow all of the solutions that looked promising in the forum to no avail. So I’ve re-flashed the TX2 to start with a fresh install.

I’ve attached the : DMESG, xorg.conf, xorg.0.log, EDID (from /sys/kernel/tegradc.0/edid), and the sha1sum

(using the code tags ended up in a truncated message)

Any help appreciated.
DMESG.txt (64.2 KB)
EDID.txt (866 Bytes)
xorg.0.log (17.3 KB)
sha1sum.txt (2.92 KB)

xorg.conf.txt (765 Bytes)

You might want to add this to ‘Section “Device”’, and then post the new xorg.log after a reboot (which will be verbose about all modes seen):

Option   "ModeDebug"

The EDID looks fairly normal, but is there anything unusual about the monitor or cable? For example, hot plugging?

If you have not tried yet, then on a running system try to unplug and re-plug the HDMI cable. Also try booting without the monitor, and then attach HDMI after boot completes. See if anything changes.

Hi linuxdev,
Thanks for taking a look.

I’ve connected a USB>TTL to pins 8-9-10 (J21), and unplugged the ethernet cable because it’s more convenient for me than ssh. Will that be ok? (the TX2 is no longer connected to the internet)

I’ve booted with and without the HDMI cable being connected and with and without the USB peripherals (a hub, with a keyboard and a mouse), and I hotplugged the HDMI (with dmesg --follow):

The only thing to happen is, when I hotplug, the monitor status light changes from amber to green and after a while the monitor displays a “no signal” message. Nothing is displayed in dmesg --follow

I tried changing the cable and the monitor (I have two of the same), and nothing changes. The cable is a basic HDMI cable without any adapters.

I’ve added Option “ModeDebug”, to xorg.conf and attached the xorg.0.log file after rebooting.

xorg.0.log-ModeDebug.txt (16.9 KB)

The serial console is the preferred method of access since it has almost no requirements and shows logging even in U-Boot prior to ever reaching Linux…so you are good there.

The log shows something quite unexpected. You have the EDID as mentioned from earlier posts, but no modes were listed…according to that log, there was no EDID. If there were an EDID, then all modes possible from that EDID would have been explained even if the modes couldn’t be used. Basically the driver does not believe there is a monitor attached.

So let’s back up for a moment and double check that this finds an EDID with the monitor attached during a boot, and then again that this does not find an EDID if no monitor is attached (I’m testing if the i2c query is actually updating):

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

There should be an EDID if the monitor is attached during boot, and there should not be an EDID if the monitor is not attached during boot. If there is an EDID, then the log should be much longer than the one you just attached in the previous post. I am going to guess that it is not possible you presented the wrong log because the log itself shows “ModeDebug”, and thus the only possibility is that the monitor didn’t see the EDID…the only question from there is why it didn’t see an EDID.

Hi, thanks for taking the time to explain things.

I booted twice:

  • With HDMI connected, it finds an EDID
  • Without HDMI, it doesn’t find an EDID

I used this command :

find /sys -name edid -exec cat -n {} \;

For some reason the cmd that you suggested was returning an error:

root@tegra-ubuntu:~# cat 'find /sys -name edid'
cat: 'find /sys -name edid': No such file or directory

I’ve attached the full logs of each session (boot, cat commands, shutdown)
Boot-With-HDMI.log (110 KB)
Boot-Without-HDMI.log (106 KB)

I was using the back-quote character `, not the single quote character '. They look nearly identical. Back quoted content is executed prior to the rest of the command content…it is macro substitution. Your method is a bit better since it would work with sudo, whereas the one I quoted I drop into an sudo shell first.

Right after these lines in the log is where the mystery starts:

[     9.866] (**) NVIDIA(0): Option "ModeDebug"
[     9.866] (**) NVIDIA(0): Option "AllowEmptyInitialConfiguration" "true"
[     9.866] (**) NVIDIA(0): Enabling 2D acceleration
[     9.867] (--) NVIDIA(0): Valid display device(s) on GPU-0 at SoC
[     9.867] (--) NVIDIA(0):     DFP-0
[     9.867] (II) NVIDIA(0): NVIDIA GPU NVIDIA Tegra X2 (nvgpu) (GP10B) at SoC (GPU-0)
[     9.867] (--) NVIDIA(0): Memory: 8042776 kBytes
[     9.867] (--) NVIDIA(0): VideoBIOS:

Once that is done it should start quoting some information about the monitor, e.g., I have a ViewSonic which starts like this as it begins verbose description (this example is from one my monitors):

[     9.684] (--) NVIDIA(0): VideoBIOS:
[     9.684] (--) NVIDIA(GPU-0): ViewSonic VX2235wm (DFP-0): connected
[     9.684] (--) NVIDIA(GPU-0): ViewSonic VX2235wm (DFP-0): External TMDS
[     9.684] (--) NVIDIA(GPU-0): ViewSonic VX2235wm (DFP-0) Name Aliases:
[     9.684] (--) NVIDIA(GPU-0):   DFP
[     9.684] (--) NVIDIA(GPU-0):   DFP-0
[     9.684] (--) NVIDIA(GPU-0):   DPY-0
[     9.684] (--) NVIDIA(GPU-0):   HDMI-0
[     9.684] (--) NVIDIA(GPU-0):   DPY-EDID-124044e6-4814-6be6-88ed-c05985967430
[     9.684] (--) NVIDIA(GPU-0):   HDMI-0
[     9.684] (II) NVIDIA(GPU-0): 
[     9.684] (II) NVIDIA(GPU-0): --- Building ModePool for ViewSonic VX2235wm (DFP-0) ---
[     9.687] (II) NVIDIA(GPU-0):   Validating Mode "1680x1050_60":
...

That content is entirely from decoding the EDID. Your EDID checksum is good, and so we know the i2c is working correctly and that the EDID being sent is what was truly programmed in. However, there is something wrong with this EDID and the driver is treating the EDID as empty.

Is there anything odd with this monitor (perhaps the EDID has an issue with how it was constructed)? Is the EDID in any way custom? If not, then it may be a driver issue where the driver is dropping the EDID without using it (which is the case of how the EDID is being decoded).

Ahhhh back-quotes…I had completely missed that, thanks for the explanation.

The monitor is an AOC I2369VM :
[url]https://eu.aoc.com/en/products/i2369vm/specs[/url]

I’ve tested plugging the monitor into a laptop running Ubuntu 16.04 LTS. It showed the GRUB, but needed hot-plugging to be detected once booted into the desktop. After that it’s always detected and works properly at each subsequent boot.

I’m not sure how useful this is, but I’ve tried these commands after booting with and without HDMI connected:

sudo cat /sys/kernel/debug/tegradc.0/mode

With HDMI :

pclk: 148500000
h_ref_to_sync: 1
v_ref_to_sync: 3
h_sync_width: 44
v_sync_width: 5
h_back_porch: 148
v_back_porch: 36
h_active: 1920
v_active: 1080
h_front_porch: 88
v_front_porch: 4
flags: 0x0
stereo_mode: 0
avi_m: 0x0
vmode: 0x10600000

Without HDMI:

pclk: 25200000
h_ref_to_sync: 1
v_ref_to_sync: 9
h_sync_width: 96
v_sync_width: 2
h_back_porch: 48
v_back_porch: 33
h_active: 640
v_active: 480
h_front_porch: 16
v_front_porch: 10
flags: 0x3
stereo_mode: 0
avi_m: 0x0
vmode: 0x0
cat /sys/class/graphics/fb0/mode

With HDMI:

U:1920x1080p-60

Without HDMI:

U:640x480p-60
export DISPLAY=:0.0
xrandr

Returns the same with or without HDMI:

Screen 0: minimum 8 x 8, current 640 x 480, maximum 32767 x 32767
HDMI-0 disconnected primary (normal left inverted right x axis y axis)
Screen 0: minimum 8 x 8, current 640 x 480, maximum 32767 x 32767
HDMI-0 disconnected primary (normal left inverted right x axis y axis)

I also tried setting a resolution with:

xrandr --output HDMI-0 --mode 1920x1080

Which just returns

xrandr: cannot find mode 1920x1080

So if I understand correctly the framebuffer seems to see a monitor but can’t display anything on it and the Xserver doesn’t see a monitor at all (and I can’t set a mode with xrandr).

Is there a way for me to test if the graphics driver is functioning properly?

Here is some more official debug documentation:
https://elinux.org/Jetson_TX2/r28_Display_debug

Is it correct that even on a desktop PC the display won’t function correctly without unplug/replug? That would be a useful bit of knowledge. What video card and driver is on the PC where it works or doesn’t?

Are you using the HDMI cable, or is there any kind of VGA or adapter involved?

Keep in mind that the driver will have a default or fallback mode. In the case of a hot plug event being detected with a new EDID which is found valid, then the mode would switch to this. If, following that event, there are other monitor detach and attach events which do not cause knowledge of an EDID change, then the settings would remain the same and not be altered. As an example, if you have a good HDMI monitor capable of some mode, then the system will set to that mode…and if you then unplug this monitor and plug in a VGA monitor capable of running on that mode, then the VGA monitor will work. However, the reason it would work is not due to being supported…it would be a case of good luck due to the prior setting working.

In the case of a new EDID being detected, if for some reason that EDID had no working modes, then I don’t know if the current settings would stay the same or instead go to some fallback setting.

Basically I suspect there is some odd interaction between that EDID and the driver, but I do think the driver is probably working correctly. The provided EDID, for whatever reason, is completely ignored by the driver. Could someone at NVIDIA check this EDID and maybe find out why ModeDebug might throw away all of the modes without even a comment of accept/reject?

00 ff ff ff ff ff ff 00 05 e3 69 23 07 0a 00 00
 22 18 01 03 80 33 1d 78 2a e5 95 a6 56 52 9d 27
 10 50 54 bf ef 00 d1 c0 b3 00 95 00 81 80 81 40
 81 c0 01 01 01 01 02 3a 80 18 71 38 2d 40 58 2c
 45 00 fd 1e 11 00 00 1e 00 00 00 fd 00 32 4c 1e
 53 11 00 0a 20 20 20 20 20 20 00 00 00 fc 00 32
 33 36 39 4d 0a 20 20 20 20 20 20 20 00 00 00 ff
 00 41 42 50 45 38 39 41 30 30 32 35 36 37 01 3a
 02 03 1e f1 4b 10 1f 05 14 04 13 03 12 02 11 01
 23 09 07 07 83 01 00 00 65 03 0c 00 20 00 8c 0a
 d0 8a 20 e0 2d 10 10 3e 96 00 fd 1e 11 00 00 18
 01 1d 00 72 51 d0 1e 20 6e 28 55 00 fd 1e 11 00
 00 1e 8c 0a d0 8a 20 e0 2d 10 10 3e 96 00 fd 1e
 11 00 00 18 8c 0a d0 90 20 40 31 20 0c 40 55 00
 fd 1e 11 00 00 18 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 6d

This looks like it should have modes, and regardless of accepting or rejecting the mode, that mode should at least be visible in a log comment. Absolutely none of those modes are even mentioned even under ModeDebug.

Not exactly. I tried plugging it into a laptop as a secondary monitor. On the first boot it wasn’t detected and I had to reconnect it in order for it to be detected. After that it worked fine, including after rebooting a few times. I think it has an integrated Intel HD Graphics 4600 and an NVIDIA GeForce GT 750M (it’s not nearby, but I can check in the morining).

I’m using an HDMI cable without any adaptors

Two details to post: Output from “head -n 1 /etc/nv_tegra_release”, and also can we verify that “sha1sum -c /etc/nv_tegra_release” has all “ok” on files listed?

Ok, so my thought on this is that the laptop isn’t a good test, but the monitor EDID clearly has some modes the TX2 should be able to function with. This isn’t even the bizarre part…that would be the fact that the EDID is valid, that it has many modes listed, and that the driver is throwing all of them out without even commenting. It is as if the driver never sees the EDID, and yet the EDID is clearly present in “/sys”. “ModeDebug” should comment on 100% of the modes from EDID and does not say anything at all about even a single mode.

Would someone from NVIDIA be able to look at the EDID in #9 and suggest why the driver throws away logging anything at all about the modes? It is almost as if this EDID is causing the driver to think there is no EDID.

Thanks for persisting. I’m away from the TX2 at the moment, however I did run sha1sum earlier on today (not “head -n 1 /etc/nv_tegra_release” unfortunately.

Here’s the output, all seems ok.

nvidia@tegra-ubuntu:~$ sha1sum -c /etc/nv_tegra_release

/usr/lib/aarch64-linux-gnu/tegra/libnvosd.so: OK
/usr/lib/aarch64-linux-gnu/tegra/libnvmmlite_image.so: OK
/usr/lib/aarch64-linux-gnu/tegra/libnvomx.so: OK
/usr/lib/aarch64-linux-gnu/tegra/libnvmedia.so: OK
/usr/lib/aarch64-linux-gnu/tegra/libnvmmlite_utils.so: OK
/usr/lib/aarch64-linux-gnu/tegra/libglx.so: OK
/usr/lib/aarch64-linux-gnu/tegra/libscf.so: OK
/usr/lib/aarch64-linux-gnu/tegra/libnvexif.so: OK
/usr/lib/aarch64-linux-gnu/tegra/libnvrm_gpu.so: OK
/usr/lib/aarch64-linux-gnu/tegra/libnvtx_helper.so: OK
/usr/lib/aarch64-linux-gnu/tegra/libnvfnetstorehdfx.so: OK
/usr/lib/aarch64-linux-gnu/tegra/libnvmm_parser.so: OK
/usr/lib/aarch64-linux-gnu/tegra/libnvrm.so: OK
/usr/lib/aarch64-linux-gnu/tegra/libnvmm_contentpipe.so: OK
/usr/lib/aarch64-linux-gnu/tegra/libnvos.so: OK
/usr/lib/aarch64-linux-gnu/tegra/libnvtnr.so: OK
/usr/lib/aarch64-linux-gnu/tegra/libnvimp.so: OK
/usr/lib/aarch64-linux-gnu/tegra/libnvfnet.so: OK
/usr/lib/aarch64-linux-gnu/tegra/libnvavp.so: OK
/usr/lib/aarch64-linux-gnu/tegra/libnvmmlite_video.so: OK
/usr/lib/aarch64-linux-gnu/tegra/libnvfnetstoredefog.so: OK
/usr/lib/aarch64-linux-gnu/tegra/libnvodm_imager.so: OK
/usr/lib/aarch64-linux-gnu/tegra/libnvjpeg.so: OK
/usr/lib/aarch64-linux-gnu/tegra/libnvtvmr.so: OK
/usr/lib/aarch64-linux-gnu/tegra/libnvidia-egl-wayland.so: OK
/usr/lib/aarch64-linux-gnu/tegra/libnvdc.so: OK
/usr/lib/aarch64-linux-gnu/tegra/libtegrav4l2.so: OK
/usr/lib/aarch64-linux-gnu/tegra/libnvmm.so: OK
/usr/lib/aarch64-linux-gnu/tegra/libnvapputil.so: OK
/usr/lib/aarch64-linux-gnu/tegra/libnvcameratools.so: OK
/usr/lib/aarch64-linux-gnu/tegra/libnvcam_imageencoder.so: OK
/usr/lib/aarch64-linux-gnu/tegra/libnveglstream_camconsumer.so: OK
/usr/lib/aarch64-linux-gnu/tegra/libnvmm_utils.so: OK
/usr/lib/aarch64-linux-gnu/tegra/libnvomxilclient.so: OK
/usr/lib/aarch64-linux-gnu/tegra/libargus.so: OK
/usr/lib/aarch64-linux-gnu/tegra/libnvwinsys.so: OK
/usr/lib/aarch64-linux-gnu/tegra/libargus_socketclient.so: OK
/usr/lib/aarch64-linux-gnu/tegra/libnveglstreamproducer.so: OK
/usr/lib/aarch64-linux-gnu/tegra/libnvll.so: OK
/usr/lib/aarch64-linux-gnu/tegra/libargus_socketserver.so: OK
/usr/lib/aarch64-linux-gnu/tegra/libnvrm_graphics.so: OK
/usr/lib/aarch64-linux-gnu/tegra/libnvcolorutil.so: OK
/usr/lib/aarch64-linux-gnu/tegra/libnvddk_2d_v2.so: OK
/usr/lib/aarch64-linux-gnu/tegra/libnvtestresults.so: OK
/usr/lib/aarch64-linux-gnu/tegra/libnvcamerautils.so: OK
/usr/lib/aarch64-linux-gnu/tegra/libnvcamlog.so: OK
/usr/lib/aarch64-linux-gnu/tegra/libnvparser.so: OK
/usr/lib/aarch64-linux-gnu/tegra/libnvddk_vic.so: OK
/usr/lib/aarch64-linux-gnu/tegra/libnvmmlite.so: OK
/usr/lib/aarch64-linux-gnu/libv4l/plugins/libv4l2_nvvidconv.so: OK
/usr/lib/aarch64-linux-gnu/libv4l/plugins/libv4l2_nvvideocodec.so: OK
/usr/lib/xorg/modules/drivers/nvidia_drv.so: OK
/usr/lib/xorg/modules/extensions/libglx.so: OK

The reason I was interested in seeing “head -n 1 /etc/nv_tegra_release” is that whoever looks in to the driver summarily dropping all EDID information will need to know which version it is.

This is the output from “head -n 1 /etc/nv_tegra_release”

# R28 (release), REVISION: 2.1, GCID: 11272647, BOARD: t186ref, EABI: aarch64, DATE: Thu May 17 07:29:06 UTC 2018

So… there is an EDID file with a valid EDID, but the driver isn’t using it.

Also:

sudo get-edid | parse-edid

Can’t find a valid EDID.

This exact HDMI monitor used to work in version 28.1 so I decided to go back to that version, but the problem remains. I then tried 27.1, but that didn’t help either. I have the exact same issue across all versions of jetpack.

I also tried to install JetPack 4.2 (version 32.1), but that version can’t be installed without a monitor attached and detected.

Could this be a hardware problem? Could someone tell me how to check that?

get-edid doesn’t work on jetsons.
You may use:

sudo cat /sys/kernel/debug/tegradc.0/edid

I see, thanks.

Yes I’ve been using :

sudo cat /sys/kernel/debug/tegradc.0/edid

And I get a valid EDID from that. But the driver just discards it for some reason.

Is there maybe a way for me to force the driver to use a specific EDID?

I have not tried it, but I’ve seen this.

Note it would probably be simpler to try another monitor. As it seems it was working before with same monitor and same L4T, did you change cables between Jetson and monitor ?

Thanks for the link, I might as well give it a go I guess. I’d still like to know why it’s not using the EDID, though.

I have tried two monitors and cables (same model), with the same result. I’ll see if I can get my hands on another one…but it seems unlikely to be the problem.