Jetson AGX Unable to Receive HDMI Input

[steven.hong]

I’m having some issues that my Jetson AGX Xavier cannot receive the input from HDMI cable. When I plug in HDMI cable to Jetson, the monitor did not receive any signal and remained black. The white light next the USB-C cable is always on.
It is similar issue as this post.

Jetson Xavier AGX powers on but does not display output from hdmi and cannot connect via usb

Hey Guys, I have been using my Jetson Xavier in my graduate school research for over a year and it has been performing well without any issues. I booted it up this morning and tried connecting to via ssh as I usually do every morning, but it failed to connect. I figured the jetson just did not connect to the network on boot up like it usually does so I plugged in the HDMI and tried to get in that way. However, that did not work because there was no HDMI output. Additionally, I connected my lapt…

I tried different monitors and power adapters suggested here, and none of them work.

Jetson Nano HDMI no output Signal

Hi, I see from the forum that I there has been some power issue with Jetson Nano, so I am currently using a 5V 4A adapter to power it through the jack instead of the USB. There is no signal from HDMI port whatsoever. I can assure that it is not the the HDMI adapter or wire issue, since it works fine on my computer. Also, I have the image from NVIDIA official website. There are only few posts on this issue and they all fined for Return Authorization. I really hope I don’t have to return it. I h…

I tried to flash Jetson manually with SDK Manager. After system is relashed, I’m able to set up a serial console to debug with gtkterm. However, what should I do here to debug why HDMI screen monitor doesn’t work?

Setting up a serial console for debug

Can someone point me to a guide open how to set up serial console for debugging of my Xavier agx dev kit the user guide says that it is possible but doesn’t give any instructions on how to actually do it. Am I able to use another Xavier dev kit as the host machine? thanks chris

Also I can ssh into Jetson through host machine.

Thank you.

[kayccc]

Are you using devkit or with custom carier board?
Which JetPack SW you’re using?

[steven.hong]

Hello, I’m using devkit with JetPack 5.1.5.

I also notice that the fan almost never spin, and it is spin for 1 sec after start-up. The devkit is very hot after a certain of period.

[WayneWWW]

Hi,

Please share us the dmesg from your Jetson with your ssh access.

[hongsn]

Hello,

This is the dmsg output from my Nvidia. It is a lot of information so I put them in a log file.
jetson_dmsg_output.log (72.0 KB)

[steven.hong]

I do not understand why my other computer browser cannot log out old account and sign in with my new one, but log file from above thread is from my Jetson Xavier AGX.

[WayneWWW]

Hi,

Could you help do this test?

1. Boot up your Jetson but 2. do not connect any monitor

2. After you are sure the system boots up, please connect the HDMI monitor.

3. Please check if HDMI would light up in this case. If it still cannot, dump me the dmesg again.

[hongsn]

Hello,

HDMI did not light up when connecting monitor after Jetson boot up.
Here is the new log file.
jetson_dmsg_output_hdmi.log (72.0 KB)

[linuxdev]

I am wondering, have you changed any of the CPU affinity values to move hardware to a different core? Is this the default kernel? Which L4T release (see “head -n 1 /etc/nv_tegra_release”)? Are there any cable adapters being used? Can you check with another monitor in the same way, and post the output of that second monitor’s dmesg (if possible)? Do you have any device tree modifications, and is this on a developer kit carrier board (or a third party custom carrier board)?

[steven.hong]

Hello,

I did not hcange any CPU affinity values. It is a developer kit carrier board instead of a third party custom board. I tried many other computers in my company, but I did not find any one that works. I tried different HDMI cables, and also with and without docking station through USB-C cable, but none works.

Jeston system image is flashed by Nivida SDK Manager with JetPack 5.1.5. HDMI cable screen was working last month without any issue. I haven’t used it for a month due to busy work, but when last week I came back to work on this Jetson, HDMI port failed. I believe that nobody used it during this period and it was just sitting on my desk.’

L4T release is # R35 (release), REVISION: 6.1, GCID: 39721438, BOARD: t186ref, EABI: aarch64, DATE. The date and time look off.

[WayneWWW]

Hi,

I notice some problem here.

[ 7.617862] tegradc 15200000.display: hdmi: edid read failed
[ 7.618075] tegradc 15200000.display: hdmi: using fallback edid

EDID read from this monitor goes failed. Could you try more HDMI monitors here and see if every of them hit such issue?

[linuxdev]

Added note: The DDC wire is the communications with the i2c protocol to transfer EDID information (EDID is the monitor’s specification which is read by the GPU to set modes; the NVIDIA driver only sets modes via EDID, or else it ends up in a default mode).

FYI, USB video is not supported. I’d be surprised if it worked on a Jetson.

Normally, if the monitor is detected during boot, then EDID is read at start-up. HDMI and DisplayPort are hot plug, and so a hot plug-in of the HDMI or DisplayPort cable should also trigger the reading of EDID. An attempt to read EDID tends to say hot plug detect worked. One of these will likely be failing (and all can be affected by the device tree):

• i2c bus power not reaching the monitor (the GPU powers the i2c in the monitor so that the GPU can detect and configure for a monitor even if power is off).
• The DDC data wire is failing.

Any cable adapter is always suspect, but you tried other cables, so if it is possible, then you should now check with other monitors. If you can use serial console or ssh to log in to the Jetson, and monitor “dmesg --follow”, and if you unplug and replug the HDMI and see a log added to dmesg (the “--follow” makes continuous log reading and shows log lines as they occur), then it means hot plug detect worked, and an attempt to read EDID over the DDC wire has occurred. Should another monitor also fail, then you might need to try flashing again (you could clone first if flashing and you want to preserve something).

Even if a monitor does not have a specification which the Jetson can configure for the EDID read should succeed. The attempt to read from another monitor is twofold: (A) Check the DDC wire for proper i2c protocol success, and (B) use the resulting EDID information to configure.

[steven.hong]

I tried dmesg --follow and plugged/unplugged HDMI cable. I did not see a log added to dmesg.

When I boot Jetson without HDMI plugged in and hot wired, I received this error.

When I boot Jetson with HDMI plugged in, I received this error

So this means that it is possible if i2c bus power is not working or DDC data wire is failing? This can only be fixed from hardware side?

[WayneWWW]

Please test more to confirm that is a behavior for all monitors you got there.

There is no software fix for such issue. Actually, our software already tried to fix something for you.

You could see that we give you a “fallback edid” there but looks like it still fails to work.

[linuxdev]

It is possible it is a hardware issue, but it doesn’t say if the issue is from the Jetson, the monitor, or the cable. Can you try another monitor you know to work? Specifically, completely boot, monitor “dmesg --follow”. Ignore any thing logged up to and including disconnecting the monitor. Watch the current end of log. Now plug in that other monitor and note what occurs in the log as a result of that plug-in event.

It is important to try a different monitor. Also, if there is anything unusual about a given monitor, please let us know (e.g., is it a miniature monitor with a small 5 inch x 7 inch screen, or is it a television not normally used as a monitor, is it an LVDS monitor with an HDMI adapter, so on).

Regarding the current situation, here are some observations needing clarity:

• If it is a cable problem, then signal quality can cause read failure even if otherwise everything works. Even someone stepping on a cable, or bending the cable too much, could cause a previously working cable to change how it handles those higher frequency square waves without actually appearing to have completely failed.
• If the monitor’s actual i2c circuitry has failed, then applying power (via the GPU sending 3.3V to the i2c power wire) won’t actually trigger an i2c read. The cable could cause this too, e.g., something as trivial as a small voltage drop can cause the signal to also lower voltage and not be enough under current conditions to properly read the i2c.
• The DDC wire itself can fail, or the signal quality can go down for a number of reasons such that it works in some cases but not other cases.

Showing only the plug-in log for a different monitor could reveal a lot depending on whether this is a change in error or the exact same error.

[steven.hong]

Thank you for your help. I tried several other monitors but it did not work. I suspect it might be i2c circuitry failure.

I think I’ll close this problem. I can still use Jetson machine through ssh from another host machine or remote desktop. It will be ideal to fix the HDMI monitor but take too much effort to debug it.

[linuxdev]

If modes are incorrectly detected or missing there is a strong chance that either i2c is being triggered or else that the modes are incompatible. Having tried many monitors I’d say it leans away from just being incompatible modes.

You might consider finding the Xorg log:
ls -ltr /var/log/Xorg.*.log | tail -n 1
…and then attaching that to the forum. Maybe we can see something there.

[hongsn]

This is my log file from Xorg.0.log

Xorg.0.log (14.6 KB)

[linuxdev]

The Xorg log looks normal in the beginning, and even loads the keyboard and a lot of Xorg extension modules. The early log lines noting a monitor are somewhat normal, but at that point it hasn’t actually tried to use the monitor or find its EDID. Some of the errors or warnings at this point don’t actually matter and can be ignored. It is at the end of the log file it gets really interesting. It should not have stopped here (the first two lines of that excerpt just show it is working normally):

[    29.143] (II) event5  - NVIDIA Jetson AGX Xavier APE Headset Jack: is tagged by udev as: Keyboard Switch
[    29.143] (II) event5  - NVIDIA Jetson AGX Xavier APE Headset Jack: device is a keyboard
[    30.459] (--) NVIDIA(GPU-0): NVIDIA (DFP-0): connected
[    30.459] (--) NVIDIA(GPU-0): NVIDIA (DFP-0): External TMDS

No EDID detect is attempted. It just stops. The dmesg log shows EDID attempt, but it is Xorg which should be causing that query and the note of failure. So I wonder why Xorg itself does not even mention EDID? Here is something from dmesg:

[    7.094439] tegradc 15200000.display: dc_poll_register 0x41: timeout
[    7.094593] tegradc 15200000.display: timeout waiting for win assignments to promote
[    7.094751] tegradc 15200000.display: tegra_nvdisp_head_enable, failed head enable
[    7.326476] tegra_cec 3960000.tegra_cec: Can't find physical address.
[    7.326631] tegra_cec 3960000.tegra_cec: tegra_cec_init Done.
[    7.613277] tegradc 15200000.display: hdmi: edid read failed
[    7.613494] tegradc 15200000.display: hdmi: using fallback edid
[    7.613642] tegradc 15200000.display: blank - powerdown
[    7.623765] tegradc 15200000.display: unblank
[    7.678431] tegradc 15200000.display: dc_poll_register 0x41: timeout
[    7.678435] tegradc 15200000.display: dc timeout waiting for DC to stop
[    7.730431] tegradc 15200000.display: dc_poll_register 0x41: timeout
[    7.730435] tegradc 15200000.display: dc timeout waiting for DC to stop
[    7.782438] tegradc 15200000.display: dc_poll_register 0x41: timeout
[    7.782443] tegradc 15200000.display: timeout waiting for postcomp init state to promote
[    7.834435] tegradc 15200000.display: dc_poll_register 0x41: timeout
[    7.834439] tegradc 15200000.display: timeout waiting for win assignments to promote
[    7.834442] tegradc 15200000.display: tegra_nvdisp_head_enable, failed head enable
[    7.834460] tegradc 15200000.display: update windows ret = -14
[    7.834477] tegradc 15200000.display: sync windows ret = -14
[    7.836938] extcon-disp-state external-connection:disp-state: cable 53 state 1
[    7.837143] Extcon HDMI: HPD enabled
[    7.838139] tegradc 15200000.display: hdmi: plugged

Some other errors from a previous boot would have caused this, or else disk failure:

[    8.729441] Found dev node: /dev/mmcblk0p1
[    8.879074] EXT4-fs (mmcblk0p1): 3 orphan inodes deleted
[    8.879910] EXT4-fs (mmcblk0p1): recovery complete
[    8.886515] EXT4-fs (mmcblk0p1): mounted filesystem with ordered data mode. Opts: (null)
[    8.893789] Rootfs mounted over mmcblk0p1

Something must have gone really wrong with the i2c circuit which runs the EDID query over the HDMI/DisplayPort; I say “really” wrong because it does not show failure, it just locks up the Xorg server and it neither fails out nor continues.

I suspect that the hardware is ok, but the damage to the filesystem which resulted in orphan nodes has hit something important. Maybe power failure or removing the power without proper shutdown caused this; even a lock up forcing manual power off could cause this. Normally such a recovery of nodes does not result in complete failure, but I’m guessing you got unlucky.

If a flash did not solve this, then normally I would think that the wrong device tree was used (one intended for a different carrier board). You said this is a dev kit, and so NVIDIA’s JetPack/SDK Manager should have solved that and it would be the correct device tree. If the carrier board is not from NVIDIA, then it would be the wrong tree and this could cause a failure of EDID.

This is a very important question: The earlier posted log from dmesg or serial console boot contains an edid log message. When you have the Xorg log, the one which just “stops” and doesn’t continue, is this from the same flash which has the edid dmesg? If dmesg or serial console boot log did not actually contain a hint of edid in it for the Xorg log which stopped, then my debugging would be completely wrong. I’m establishing that EDID query was attempted where the o/s knew, but the Xorg locked up before logging.

I am assuming that under the circumstances you may have had to have tried to boot and cycle power when you couldn’t get in, and so orphan node recovery may be unrelated to the original failure. It could still be an issue. Any time you can get in with ssh or serial console I suggest trying to shut down with “sudo shutdown -h now”. If not, don’t worry about it too much.