Hello,
We have created a custom carrier for the Xavier NX and are having trouble getting HDMI to work.
We are using JetPack 4.6. The HDMI port is connected to the DP1 pins, and the HPD pin is pulled low when the monitor is connected. Nothing is connected to DP0. The only USB port we have accessible is USB0.
We first flashed using the stock device tree. The flash completed and we got to the screen showing up on the HDMI monitor asking to confirm the license agreement, although the resolution was not correct for the monitor. We then changed usb0 to host mode in the device tree and flashed with -k kernel-dtb. This let us proceed with creating a user account.
However, now when we boot we get the following behavior: We see the nvidia logo, then some lines of text from the kernel, then another nvidia logo, and then the screen goes black and powers down (no signal). On the devkit we can see the login screeen but on our custom board we do not. xrandr shows that X is running at the correct resolution, but no video is output. We have tried a variety of things such as manually unblanking the display and disabling head1 in the device tree but nothing helps.
What could be causing this? And what can we do to debug further?
dmesg.txt (63.3 KB)
xorg.0.log.txt (17.9 KB)
I don’t see any error in dmesg.
What would be the hotplug case? Please do not connect anything during the boot. Wait for about 30 sec after you press the power button.
Hotplug the cable the share the dmesg and xorg.0.log.
Hi @WayneWWW,
Hotplugging does not work either. dmesg output and Xorg.0.log attached. Also when we plug in the HDMI cable we get the following output to the debug UART:
[ 466.108947] edid invalid
ÿâWARNING: pll_d2 has no dyn ramp
xorgHotplug.txt (18.5 KB)
dmesgHotplug.txt (65.9 KB)
Looks like xorg and dmesg both didn’t report error.
I can only suggest you to check the hardware design guide and review your hardware.
We have checked everything a million times, and have tried with several of our carriers and several Xavier NX modules, and the behavior is consistent. The hardware is capable of displaying video, as we can see the splash screen and the kernel messages without issue. On the software side, it is the stock jetpack install. I assume the screens we can see are using the framebuffer directly. X11 is what appears to be the problem. There has to be something else going on that would cause this that is hardware related but unrelated to the HDMI port wiring. Perhaps another pin on the module that is not in the correct state at bootup? Can you help us debug this further? Is there a way to get more info from the gpu driver?
What was the setup when you were doing this?
We first flashed using the stock device tree. The flash completed and we got to the screen showing up on the HDMI monitor asking to confirm the license agreement, although the resolution was not correct for the monitor.
I mean what is changed in this case and current case?
And what is that “license agreement”? The steps to ask you to configure user account?
Nothing changed. Same som, same carrier, same flash. Yes I’m talking about the initial bootup screen where you have to configure the user account. We can get through that much after setting usb0 to host mode, but then instead of seeing the login screen the monitor goes dark.
Ok, so this module is flashed with same jetpack from sdkmanager without any customization from you?
Even no dtb change?
Correct. Except that once we get to the configure user account screen we need to change the device tree to set usb0 to host mode. But, we’ve also tried setting up the som on the devkit and then moving it to our carrier and get the same result, so I don’t think the usb0 setting has anything to do with it.
i.e. we can take a fresh som, flash it with the stock jetpack with NO dtb change, set up the user account, and move it to our carrier and get the same behavior - splash screen and kernel messages show up, but screen goes dark when we should see the login screen.
Hi,
I am a little not sure about the process here.
Maybe we can forget about the usb0 host mode at this moment. This one sounds only creating extra effort. We shall not do this.
Few questions here
-
If you flash default jetpack to the module+ devkit, configure the user account on the devkit, will you see the monitor GUI after user configuration?
-
If (1) is fine, what will happen if you just move this module from devkit to your board? You can use devkit to do all the work so that no usb change is required in dtb. For example, set auto login first on devkit so that it will not need to enter pwd when it is on your custom board.
This was actually the first thing we tried.
- We flashed the module on the devkit and configured the user account. Everything works fine, we can see the login screen and log in and use the module normally.
- We moved the module onto our carrier. We see the splash screen, kernel messages, and then the screen goes dark. No errors in dmesg or Xorg.0.log. We have not tried with autologin yet, but we tried killing gdm and running startx and still just had a black screen.
Hi,
Another method to check whether this issue is related to X or not…
You can run our gstreamer sample with nvoverlaysink or mmapi sample 08, which is using DRM. (Remotely running)
These two do not need X and X has to be disabled.
If those samples are able to run, and you can see rendering over the monitor, then it indicates the kernel side is fine.
BTW, what do you see on the monitor when you disable gdm? Does it go blanked or you will see console?
Sure, I can try that. How do I run those samples?
Here’s what I tried:
sudo systemctl stop gdm
sudo kill -9 Xorg_pid
ctrl-alt-f1 through f12 (could not see a console on the display)
gst-launch-1.0 videotestsrc ! nvoverlaysink (it ran, but nothing shown on the display)
Hi @hoenigal
Overlaysink can also work even when you didn’t disable gdm and xorg. Please try this case again.
If the monitor still goes blank, please try this before running overlaysink.
sudo -s
cd /sys/class/graphics/fb0 # could also be fb1 or fb2, depends on how many monitors are in use.
echo 4 >blank
echo 0 > blank # this will unblank the monitor. If no GUI running, it shall be a black one but monitor should be powered-on.
Hi @WayneWWW,
There is no unblank node under /sys/class/graphics/fb0, only blank. We tried echoing 4 and 0 to the blank node and nothing happened. The monitor still says “no signal” even when running nvoverlaysink. It seems once X starts running, the HDMI stops outputting a signal and nothing we’ve tried will bring it back until rebooting.
Interestingly, when echoing 0 to /sys/class/graphics/fb0/blank, we see EDID activity with a logic analyzer on the HDMI I2C lines.
We also tried with fb1, nothing happened. fb1 should not be connected to anything.
Hi @hoenigal ,
Sorry for my typo. It is blank node.
Could you take a video of what you will see on the monitor when booting up?
Could you also share the schematic of your hdmi part?
I will ask but I don’t think we have permission to share video or the schematic. Is there any way to enable more logging? Could something unrelated to the hdmi wiring cause this? What is X doing that the kernel fb driver isn’t doing?
Hi,
For xorg, you can refer to my old post.
https://elinux.org/Jetson_TX2/r28_Display_debug
There is one “Error log from X11” section to enable more logs from xorg log. But I don’t think this would provide useful info.
I am also wondering… have you tried different monitors? But if same monitor can work fine on NV devkit, then there is no need to change.