HDMI Display issues - Jetson Nano B01

Robotics & Edge Computing Jetson & Embedded Systems Jetson Nano
1

Hi, I’m having issues running a particular display device that comes with a HDMI - MIPI converter. The particular display works as expected when connected by HDMI to my ubuntu laptop, but fails from the jetson nano. The nano is currently flashed from jetpack 4.6.5 via the sdk manager. Conventional HDMI native monitors that I’ve tested are working properly, it’s just this particular display that I’d like to get working.

Curiously, if I install from sd-card image, the display works correctly during install (while setting username and such), but immediately goes black afterwards. The display also shows the nvidia logo during boot, before going black.

dmesg output when the HDMI is connected:

[  304.990576] Reserved SVD code 0
[  304.994217] Reserved SVD code 0
[  304.997595] Reserved SVD code 0
[  305.000873] Reserved SVD code 0
[  305.004096] Reserved SVD code 0
[  305.007236] Reserved SVD code 0
[  305.010419] Reserved SVD code 0
[  305.013639] tegradc tegradc.0: blank - powerdown
[  305.014007] tegradc tegradc.0: unblank
[  305.024027] tegradc tegradc.0: nominal-pclk:257970000 parent:257968750 div:1.0 pclk:257968750 255390300~281187300
[  305.024113] tegradc tegradc.0: hdmi: tmds rate:257970K prod-setting:prod_c_hdmi_150m_300m
[  305.025274] tegradc tegradc.0: hdmi: get YCC quant from EDID.
[  305.058166] Reserved SVD code 0
[  305.058179] Reserved SVD code 0
[  305.058190] Reserved SVD code 0
[  305.058200] Reserved SVD code 0
[  305.058209] Reserved SVD code 0
[  305.058211] Reserved SVD code 0
[  305.058213] Reserved SVD code 0
[  305.065984] extcon-disp-state extcon:disp-state: cable 47 state 1
[  305.065988] Extcon AUX1(HDMI) enable
[  305.088266] extcon-disp-state extcon:disp-state: cable 51 state 1
[  305.088269] Extcon HDMI: HPD enabled
[  305.088293] tegradc tegradc.0: hdmi: plugged
[  305.451803] tegradc tegradc.0: blank - powerdown
[  305.508933] extcon-disp-state extcon:disp-state: cable 47 state 0
[  305.508935] Extcon AUX1(HDMI) disable
[  305.529381] tegradc tegradc.0: unblank
[  305.539390] tegradc tegradc.0: nominal-pclk:148500000 parent:148500000 div:1.0 pclk:148500000 147015000~161865000
[  305.539468] tegradc tegradc.0: hdmi: tmds rate:148500K prod-setting:prod_c_hdmi_75m_150m
[  305.540490] tegradc tegradc.0: hdmi: get YCC quant from EDID.
[  305.572134] Reserved SVD code 0
[  305.572135] Reserved SVD code 0
[  305.572136] Reserved SVD code 0
[  305.572137] Reserved SVD code 0
[  305.572138] Reserved SVD code 0
[  305.572139] Reserved SVD code 0
[  305.572140] Reserved SVD code 0
[  305.578207] extcon-disp-state extcon:disp-state: cable 47 state 1
[  305.578209] Extcon AUX1(HDMI) enable
[  305.600350] tegradc tegradc.0: unblank
[  305.600688] tegradc tegradc.1: blank - powerdown
[  305.711616] tegradc tegradc.0: blank - powerdown
[  305.775151] extcon-disp-state extcon:disp-state: cable 47 state 0
[  305.775154] Extcon AUX1(HDMI) disable
[  305.794769] tegradc tegradc.0: unblank
[  305.804773] tegradc tegradc.0: nominal-pclk:257970000 parent:257968750 div:1.0 pclk:257968750 255390300~281187300

(this repeats many times)
the output of xrandr when the display is connected:

Screen 0: minimum 8 x 8, current 2880 x 1440, maximum 16384 x 16384
HDMI-0 connected primary 2880x1440+0+0 (normal left inverted right x axis y axis) 0mm x 0mm
   2880x1440     60.01*+
   640x350       85.08  
DP-0 disconnected (normal left inverted right x axis y axis)

In case it’s relevant, this is the output of get-edid | parse-edid when the display is working on my ubuntu machine:

Section "Monitor"
	Identifier "YongXing     "
	ModelName "YongXing     "
	VendorName "LZT"
	# Monitor Manufactured week 12 of 2017
	# EDID version 1.3
	# Digital Display
	# Display Physical Size not given. Normal for projectors.
	Gamma 2.20
	Option "DPMS" "false"
	Horizsync 15-240
	VertRefresh 23-75
	# Maximum pixel clock is 340MHz
	#Not giving standard mode: 248x155, 60Hz
	#Not giving standard mode: 248x155, 60Hz
	#Not giving standard mode: 248x155, 60Hz
	#Not giving standard mode: 248x155, 60Hz
	#Not giving standard mode: 248x155, 60Hz
	#Not giving standard mode: 248x155, 60Hz
	#Not giving standard mode: 248x155, 60Hz
	#Not giving standard mode: 248x155, 60Hz

	#Extension block found. Parsing...
	Modeline 	"Mode 8" 257.97 2880 2930 2938 2953 1440 1448 1450 1456 -hsync -vsync 
	Modeline 	"Mode 0" 257.97 2880 2930 2938 2953 1440 1448 1450 1456 -hsync -vsync 
	Modeline 	"Mode 1" 
	Modeline 	"Mode 2" 
	Modeline 	"Mode 3" 
	Modeline 	"Mode 4" 
	Modeline 	"Mode 5" 
	Modeline 	"Mode 6" 
	Modeline 	"Mode 7" 
	Modeline 	"Mode 9" 257.97 2880 2930 2938 2953 1440 1448 1450 1456 -hsync -vsync 
	Modeline 	"Mode 10" 257.97 2880 2930 2938 2953 1440 1448 1450 1456 -hsync -vsync 
	Modeline 	"Mode 11" 257.97 2880 2930 2938 2953 1440 1448 1450 1456 -hsync -vsync 
	Option "PreferredMode" "Mode 8"
EndSection
2

Does the adapter actively pass through the DDC wire (which provides EDID data)? If the monitor’s EDID does not pass through due to the adapter, then there is no way for video to be correctly configured. The Jetson driver will ignore most of what you might customize in the Section "Monitor" and will only succeed via the EDID (DDC wire).

3

I believe the adapter board is where the EDID is stored, and yes, it passes it over HDMI. When I plug the HDMI cable into my laptop, I can use the display and read the EDID data. The section monitor part is not something I’ve customised in xorg.conf or anything - that’s the EDID data when connected to my laptop, parsed using parse-edid.

If the jetson isn’t reading the EDID, how is the correct resolution displayed in the xrandr output? But I don’t understand the repeated powerdown and re-enabling in the dmesg output - I’ve only attached a small part, but this repeats many times, maybe indefinitely. Could it be a power issue?

4

I forgot to add - using xrandr on the jetson, I can select the second option of 640x350, and the screen will show on the display, albeit small and in triplicate

5

If you monitor “dmesg --follow” (preferably remotely from ssh or serial console), and then unplug and replug the HDMI (remotely since it works even without a monitor), what shows up as a result of the plug-in event?

If you do not perform the unplug/replug (you might need remote ssh or serial console access to do this as desired), which Xorg log do you see from:
ls -ltr /var/log/Xorg.*.log | tail -n 1

Can you state the name of that log, and post a copy by attaching it to the forum?

6

The dmesg output is exactly as in the opening post, the first messages are the reserved svd code 0’s - I can see using follow that it repeats every 3 seconds. The log is Xorg.0.log, attached here
Xorg.0.log (15.7 MB)

7

I’m happy to see the ModePool information (I don’t normally see people enabling this, but it is quite useful). The driver itself says these modes are valid:

[   226.243] (II) NVIDIA(GPU-0): --- Modes in ModePool for LZT YongXing (DFP-0) ---
[   226.243] (II) NVIDIA(GPU-0): "nvidia-auto-select" : 2880 x 1440 @  60.0 Hz  (from: EDID, Detailed)
[   226.243] (II) NVIDIA(GPU-0): "2880x1440"          : 2880 x 1440 @  60.0 Hz  (from: EDID, Detailed)
[   226.243] (II) NVIDIA(GPU-0): "2880x1440_60"       : 2880 x 1440 @  60.0 Hz  (from: EDID, Detailed)
[   226.243] (II) NVIDIA(GPU-0): "640x350"            :  640 x  350 @  85.1 Hz  (from: EDID)
[   226.243] (II) NVIDIA(GPU-0): "640x350_85"         :  640 x  350 @  85.1 Hz  (from: EDID)
[   226.243] (II) NVIDIA(GPU-0): --- End of ModePool for LZT YongXing (DFP-0): ---

However, the log does not seem to complete. It says it is setting up, but it does not actually pick a mode. I am not at all certain that what I’m thinking is correct, but it looks like the adapter is not actually responding the way it should and it is hanging.

I realize it would take expensive test equipment, but do you have any ability to look at the MIPI side and see if configuration results in signal output as expected? Also, does the display do anything at all, even if it is just a flash (or anything to see it is trying to do something), when using xrandr to try to set one of those modes of the mode pool? If you use xrandr to name one of those modes within the accepted mode pool, then it is quite likely the Jetson side is going to correctly attempt to talk to that adapter (at least at the start).

8

using xrandr, I can set the mode to 640x350, which “works”, but obviously not ideal. Changing to 2880x1440 sends the display back to black. I do have an oscilloscope - I’ll see if I can probe the MIPI later in the day

9

Just to explain why I’m going to say the monitor seems to be the failure point, I’ll say a bit about the EDID data.

Starting with the “digital” DVI (there is also analog) an extra wire was added to the monitor and cable. That wire is an i2c communications device that is actually powered by the graphics card, not the monitor. Whenever you turn on your computer, or when you plug in HDMI or DisplayPort (they are “hot plug”), the plug-in even is detected and the i2c hardware is powered (thus it does not matter if the monitor is turned on or off or unplugged…the monitor can report what it is). The i2c query occurs, and the DDC wire returns the data (which is actually EDID2 these days, though I just say EDID). That data is everything that describes the monitor’s capabilities, and is the equivalent of what in the old days was a “driver disk” for a monitor on VGA (the driver disk was really a database of capabilities, and was not actually a driver). This is how automatic configuration works.

Most GPUs are on PCI, and are “discrete” GPUs (dGPU). Jetson GPUs are integrated directly to the memory controller (an iGPU). Discrete GPUs allow configuration via either the EDID data or via external configuration files. The iGPU accepts only the EDID data (there are some details that can be configured in files, but the monitor’s specifications must come from the monitor’s EDID).

Your DDC wire is responding with modes, and the system is working correctly. The problem is that those modes are not really from your monitor, they are from an adapter, and the adapter is reporting the wrong modes. It seems like the 2880x1440 mode, which the iGPU supports, is not actually supported by the monitor.

Take a close look at this subset of the accepted modes specification:

[   226.243] (II) NVIDIA(GPU-0): "2880x1440"          : 2880 x 1440 @  60.0 Hz  (from: EDID, Detailed)
[   226.243] (II) NVIDIA(GPU-0): "2880x1440_60"       : 2880 x 1440 @  60.0 Hz  (from: EDID, Detailed)

Both of those modes specify not only the resolution, but also a 60.0 Hz refresh rate. Both are the same mode, but two different aliases are given. They lead to 60.0 Hz.

Are you certain that this monitor is capable of 2880x1440 resolution? If yes, then it means that the refresh rate is wrong. Those are the two parts of the specification on this mode. If the monitor must do something like slow down at higher resolutions (which is reasonable and typical), then the monitor will fail when trying to run at those speeds. I think the signal is correct for 2880x1440 @ 60.0 Hz, but that the monitor is black because it cannot scan at that rate.

10

The thing is, I can connect the adapter to my laptop’s HDMI port, and it does work at 2880x1440, with xrandr giving 2880 x 1440 @ 60.0 Hz as the mode. I think I am going to order an alternative display however, and see how I go with that

11

I wish I knew more about the modes, but I suspect there is some slight difference in how that mode is being implemented on the Jetson versus on your laptop’s HDMI. Anything you might be able to measure, e.g., actually looking at clock or other lines to compare the Jetson and HDMI of the laptop might be of interest. Perhaps it is as little as a slight clock difference.

12

The jetson is definitely clocking it slightly faster. Is it possible to rebuild the kernel to try hardcode a slower rate mode? Or is it too closely tied to the hardware to make such changes easily? Otherwise I’ll probably close the topic for now and see how I go with the new display.

13

It isn’t really practical to hard code it. There is a way to set a default to something, but the driver still has to support it.

What I’m going to suggest is that perhaps the EDID being sent isn’t quite right, or else maybe someone from NVIDIA has a way to get the exact timings the driver is actually using, and check if there is a discrepancy between what the EDID is requesting versus what is being implemented for that EDID. If you can get that data, for the exact timings of the mode, both from the working laptop and from the Jetson, then such a comparison might provide a reason why the actual clocks differ (timings have a lot of different times in them, it isn’t just one or two numbers).

I don’t know if this is a good starting point or not, but on the laptop, and on the Jetson, log the output of “xrandr --verbose”. Example:

  • xrandr --verbose 2>&1 | tee log_jetson.txt
  • xrandr --verbose 2>&1 | tee log_laptop.txt

(this would give you two logs labeled for Jetson and laptop; it is unknown if this will be the correct information)

Also, do you have the exact EDID the adapter is set to? What was the method by which you found the EDID to program the adapter to? If you can get that EDID, then you can post that here as well. It might be interesting to see what it says about the EDID here:
http://www.edidreader.com/

14

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.