TX2 development kit : 4K doesn't work (boot fails)

Autonomous Machines Jetson & Embedded Systems Jetson TX2
21

So long as only the “/dev/ttyTHS2” “status” setting for the UART is changed nothing is harmed in debugging. So, it looks like you’re hitting a mode which is valid, but perhaps not supported, and instead of gracefully failing it has other effects.

The next step is to get a finer grained idea of what the video driver itself thinks of the modes. The way to do this is to check the Xorg.0.log after starting with the earlier mentioned change to add an option to the device section of “/etc/X11/xorg.conf”:

Option      "ModeDebug"

Are you able to add this option and get the Jetson booted far enough to look at that log? You had mentioned earlier that it seemed to not even get to a stage capable of this, so here are some ideas. First, remove all of the old logs to be sure nothing stale gets viewed. Next, reboot. Should no logging occur, check the result of this (you may want to monitor “sudo dmesg --follow” during this step), then view for logs again:

sudo systemctl isolate graphical.target
# Or just view status:
sudo systemctl status graphical.target

When manually initiating the X11 server in this way you may get logs which otherwise do not show up. Any messages generated by this (especially Xorg.0.log messages on mode) would be very useful.

22

Hi,

According to your EDID, your monitor is a 4K@60 hdmi. It is a known bug internally. I will help check if it is resolved in next release.

23

Thank you WayneWWW.

Is there a workaround to this? Like disabling the HDMI driver first and re-enabling it later? (since, again, hotplug works, it’s just the init process that breaks).

Otherwise, I have made 2 more experiments (2 more logs) with the stock OS just flashed.

Using the serial console, in both cases I can’t interact with anything (no command line to type commands into). Also, no X log appear afterwards (I had to disable the desktop to make sure it didn’t start next time, because I have no way of accessing the eMMC from the outside, other than booting. EDIT: I guess using U-Boot ls could work).
On next boot:

$ ls /var/log/X*
ls: cannot access '/var/log/X*': no such file or directory
24

It probably won’t be too long before the next release, and if that release fixes things you’re in luck. Since 4k@60 is a known bug, I suspect one workaround would be to set up your “/etc/X11/xorg.conf” to ignore EDID, then manually copy in configuration based on your EDID, except it would only set up for modes other than 4k@60. This isn’t a completely trivial learning curve, so I guess a question is whether you would be willing to use the cable disconnect/connect in the interim, or if you want to go through manual xorg.conf configuration steps (I’m assuming 4k@60 is fixed in the next release…if it is found to not be in the next release you’ll probably want to do this, but I’d wait to see what @WayneWWW finds out before deciding).

25

We have a simple workaround for some test monitor.
You could give it a try.

---

diff --git a/drivers/video/tegra/dc/edid.c b/drivers/video/tegra/dc/edid.c
index c282608..634e81e 100644
--- a/drivers/video/tegra/dc/edid.c
+++ b/drivers/video/tegra/dc/edid.c
@@ -814,7 +814,7 @@
 		}
 	}
 
-#if defined(CONFIG_ARCH_TEGRA_210_SOC) || defined(CONFIG_TEGRA_NVDISPLAY)
+#if defined(CONFIG_TEGRA_NVDISPLAY)
 	/* T210 and T186 supports fractional divider and hence can support the * 1000 / 1001 modes.
 	   For now, only enable support for 24, 30 and 60 Hz modes. */
 	{
diff --git a/drivers/video/tegra/dc/hdmi2.0.c b/drivers/video/tegra/dc/hdmi2.0.c
index 3d92e59..a59741e 100644
--- a/drivers/video/tegra/dc/hdmi2.0.c
+++ b/drivers/video/tegra/dc/hdmi2.0.c
@@ -2531,7 +2531,7 @@
 	if (mode->vmode & FB_VMODE_1000DIV1001)
 		pclk = pclk * 1000 / 1001;
 
-	return pclk;
+	return 533250000;
 }
 
 static long tegra_dc_hdmi_setup_clk(struct tegra_dc *dc, struct clk *clk)
26

I seems I don’t have the same source files.

Using R27.1 sources, the edid.c is located under display/drivers/video/tegra/dc (maybe the “display” is just the repository…)

When I use patch from display/ directory, it finds the file but fails to apply the patch (lines mismatch).

patch -p1 < ../workaround_hdmi.patch 
patching file drivers/video/tegra/dc/edid.c
Hunk #1 FAILED at 814.
1 out of 1 hunk FAILED -- saving rejects to file drivers/video/tegra/dc/edid.c.rej
patching file drivers/video/tegra/dc/hdmi2.0.c
patch unexpectedly ends in middle of line
Hunk #1 FAILED at 2531.
1 out of 1 hunk FAILED -- saving rejects to file drivers/video/tegra/dc/hdmi2.0.c.rej

Here is edid.c from R27.1 sources from line 814 (also note the mismatch between #ifdef variables):

(814)#if defined(CONFIG_ARCH_TEGRA_21x_SOC) || defined(CONFIG_ARCH_TEGRA_18x_SOC)
	/* T210 and T186 supports fractional divider and hence can support the * 1000 / 1001 modes.
	   For now, only enable support for 24, 30 and 60 Hz modes. */
	{
		const int max_modes = 50;

The patch initially meant to replace line 816 (copied from WayneWWW’s answer):

#if defined(CONFIG_ARCH_TEGRA_210_SOC) || defined(CONFIG_TEGRA_NVDISPLAY)

by

#if defined(CONFIG_TEGRA_NVDISPLAY)

If I understand correctly, the point of the patch is to disable the whole #ifdef block, so I’m trying to comment it out.

Also, in hdmi2.0.c (located in the same directory), there is a line mismatch. The “return pclk” statement is in line 2279 instead of 2535. But I’m wondering if the patch will work since we have different trees.

27

With the static clock at 533250000 (in hdmi2.0.c), I tried 2 different things:
1 - commenting out #ifdef section in edid.c : same result as before (vrr_setup failed after ~2.8secs of boot)
2 - commenting out just the “ifdef” and “endif” lines to activate the block unconditionally: many more boot logs, but booting still fails after ~4 seconds.
3 - with same kernel as (2), boot without HDMI and plug HDMI afterwards. Jetson does not react and TV shows “invalid format”, interestingly.

So this patch does not work for me.

28

Hi Maxbns,
Please try rel-28.1 flash for this problem.

29

Hi Maxbns,

Sorry that I find your issue is filed for TX2. The patch gave to you was for TX1. I cannot get useful error message from the logs above.

According to your previous comment, you don’t see a Xlog under /var/log. Do you flash tx2 with jetpack rootfs?

30

Yes I flashed the whole system using Jetpack/latest release (was R27.1 at the time).

Thanks for the replies. I will try with R28.1 (and with patched TX1 R24.x as well if I have time).

31

Flashed with R28.1 (using Dell UP3216Q), and booting works into 4K directly, but only at 30fps.

I tried two things:
1. adding ModeDebug to the default xorg.conf
Xorg log does not talk about 3840x2160_60 anywhere (only the same modes listed in xrandr: several modes between 24 and 30Hz), and boots as if nothing changed.

2. Using xorg.conf file from this post:
https://devtalk.nvidia.com/default/topic/1008518/x11-configuration-xrandr-refresh-rates/
(with ModeDebug option added in)
This conf file forces HDMI modes.

The Xorg log now has lines like this:

[ 11701.152] (WW) NVIDIA(GPU-0):   Validating Mode "3840x2160_60":
[ 11701.152] (WW) NVIDIA(GPU-0):     Mode Source: X Configuration file ModeLine
[ 11701.152] (WW) NVIDIA(GPU-0):     3840 x 2160 @ 60 Hz
[ 11701.152] (WW) NVIDIA(GPU-0):       Pixel Clock      : 711.63 MHz
[ 11701.152] (WW) NVIDIA(GPU-0):       HRes, HSyncStart : 3840, 4152
[ 11701.152] (WW) NVIDIA(GPU-0):       HSyncEnd, HTotal : 4576, 5312
[ 11701.152] (WW) NVIDIA(GPU-0):       VRes, VSyncStart : 2160, 2161
[ 11701.152] (WW) NVIDIA(GPU-0):       VSyncEnd, VTotal : 2164, 2235
[ 11701.152] (WW) NVIDIA(GPU-0):       H/V Polarity     : -/+
[ 11701.152] (WW) NVIDIA(GPU-0):     Mode is rejected: Only modes from the NVIDIA X driver's
[ 11701.152] (WW) NVIDIA(GPU-0):     predefined list and modes from the EDID are allowed
[ 11701.152] (WW) NVIDIA(GPU-0):     Mode "3840x2160_60" is invalid.

The full contents of my xorg.conf file is:

Section "ServerFlags"
    Option      "DefaultServerLayout" "Layout0"
EndSection

Section "Module"
    Disable     "dri"
    SubSection  "extmod"
        Option  "omit xfree86-dga"
    EndSubSection
EndSection

Section "Device"
    Identifier  "Tegra0"
    Driver      "nvidia"
    Option      "AllowEmptyInitialConfiguration" "true"
    Option      "ExactModeTimingsDVI" "true"
    Option      "Monitor-HDMI-0" "Rec0"
    Option "ModeDebug"
EndSection

Section "Monitor"
    Identifier  "Rec0"
    HorizSync    30.0 - 83.0
    VertRefresh  56.0 - 75.0
    Option      "IgnoreEDID" "true"
    Option      "UseEdidFreqs" "false"
    # 3840x2160 60.00 Hz (CVT) hsync: 134.22 kHz; pclk: 713.00 MHz
    Modeline    "3840x2160_60.00cvt" 713.00 3840 4160 4576 5312 2160 2163 2168 2237 -HSync +VSync

    # 3840x2160 59.94 Hz (CVT) hsync: 134.08 kHz; pclk: 712.25 MHz
    Modeline    "3840x2160_59.94cvt" 712.25 3840 4160 4576 5312 2160 2163 2168 2237 -HSync +VSync

    # 3840x2160 @ 60.00 Hz (GTF) hsync: 134.10 kHz; pclk: 712.34 MHz
    Modeline    "3840x2160_60.00gtf" 712.34 3840 4152 4576 5312 2160 2161 2164 2235 -HSync +Vsync

    # 3840x2160 @ 59.94 Hz (GTF) hsync: 133.97 kHz; pclk: 711.63 MHz
    Modeline    "3840x2160_59.94gtf" 711.63 3840 4152 4576 5312 2160 2161 2164 2235 -HSync +Vsync
EndSection

Section "Screen"
    Identifier  "Screen0"
    Device      "Tegra0"
    Monitor     "Rec0"
    DefaultDepth 24
    SubSection "Display"
        Depth      24
        Modes      "3840x2160_60.00cvt" "3840x2160_59.94cvt" "3840x2160_60.00gtf" "3840x2160_59.94gtf"
    EndSubSection
EndSection

Section "ServerLayout"
    Identifier     "Layout0"
    Screen         "Screen0"
EndSection

Following instructions from the other thread, it seems it can be fixed in the kernel source. But what bumps me up is that modes already exist for 2160p60 in modedebug.c (which is not exactly in the same location as the other thread says).

I will try using one of the predefined modes in the kernel (provided I can convert it to X format) but it takes time.

Any ideas?

PS: my edid is now

00 ff ff ff ff ff ff 00 10 ac d6 40 50 34 34 32
 0c 1b 01 03 80 46 28 78 ea ef 95 a3 54 35 b5 26
 0f 50 54 a5 4b 00 d1 00 d1 c0 b3 00 a9 40 81 80
 81 00 71 4f e1 c0 04 74 00 30 f2 70 5a 80 b0 58
 8a 00 ba 89 21 00 00 1e 00 00 00 ff 00 34 4e 43
 44 30 37 33 4b 32 34 34 50 0a 00 00 00 fc 00 44
 45 4c 4c 20 55 50 33 32 31 36 51 0a 00 00 00 fd
 00 1d 4b 1f 8c 1e 00 0a 20 20 20 20 20 20 01 e5
 02 03 2b f1 50 10 1f 20 05 14 04 13 12 11 03 02
 16 15 07 06 01 23 09 1f 07 83 01 00 00 6d 03 0c
 00 10 00 00 3c 20 00 60 01 02 03 04 74 00 30 f2
 70 5a 80 b0 58 8a 00 ba 89 21 00 00 1e 02 3a 80
 18 71 38 2d 40 58 2c 45 00 ba 89 21 00 00 1e 01
 1d 80 18 71 1c 16 20 58 2c 25 00 ba 89 21 00 00
 9e 01 1d 00 72 51 d0 1e 20 6e 28 55 00 ba 89 21
 00 00 1e 00 00 00 00 00 00 00 00 00 00 00 00 de
32

What shows up in the Xorg.0.log if you comment out these xorg.conf lines:

#    Option      "ExactModeTimingsDVI" "true"
#    Option      "Monitor-HDMI-0" "Rec0"

The ModeDebug won’t do much good unless it is using EDID. The EDID you posted is valid, but your customizations may cause EDID to be ignored.

I do not know what the edits/patches were for NVIDIA’s recent related patches.

You said “The Xorg log now has lines like this:”, and the an excerpt. The list is probably long, but could you post all of that? Or even the entire log once the xorg.conf has those lines commented out?

33

Hi,

The X11 driver would reject any of user-defined mode in xorg.conf. If your mode is being rejected, it means there is compatible issue between it and our kernel.

34

How can I know which modes are compatible? It doesn’t even seem clear from modedb.c which modes are authorized. If I know how to make a mode compliant with the kernel, I can use it, but I don’t know how to do that. Xorg “ModeLine” lines are particularly unclear to me.

Is there a list of compatible modes in Xorg format?

Also, if I don’t hardcode modes in xorg.conf, there is nothing about mode rejection (whereas I know for sure that the monitor can do 2160p60 via HDMI, I tested it with other hardware). So it’s not a problem of monitor compatibility, it’s a problem of driver or xorg integration.

35

Hi Maxbns,

I take a look at your EDID and find your preferred mode has following info.

Pixel Clock: 297MHz
Horizontal Active: 3840
Horizontal Blanking: 560
Vertical Active: 2160
Vertical Blanking: 90
Horizontal Sync Offset: 176
Horizontal Sync Pulse: 88
Vertical Sync Offset: 8
Vertical Sync Pulse: 10
Horizontal Display Size: 698
Vertical Display Size: 393
Horizontal Border: 0
Vertical Border: 0
Interlaced: false
Stereo Mode: 0
Sync Type: 3

This is a 3840x2160@30 mode and I don’t see other 60HZ one in your edid. The tegra driver has simple rule. It only selects the mode from edid. If the preferred mode has somehow failed, it would select another one.

36

It seems weird that other devices can work with this monitor in 2840x2160_60 over HDMI out of the box.

It leaves us with 2 solutions :

  • Either other devices do not respect EDID and output 2160p60 (~594Mhz) although monitor does not advertise to support it
  • Or NVidia EDID driver discards the EDID entries for some reason (I’ve seen comments in the code about discarding EDIDs based on certain criteria).

In both cases, putting a NVIDIA-predefined mode in xorg.conf should still work, because they do get evaluated (as my previous logs show). The reason they are discarded is because they are not part of the predefined list.

37

OK, I think I’m beginning to understand what is going on.

  1. Following WayneWWW’s anwser, I found out that HDMI 2.0 was disabled on Dell UP3216Q by default. I feel dumb because I should have started looking there first. Now the TX2 works fine at 2160p60.

  2. Concerning my initial issue, the R28.1 release did not change anything, but I have enough information now to know that it’s the TV’s falt. Before starting using the Dell, I was using OLED UHD TVs from LG and always got problems with booting when connected to these TVs. Probably it’s a problem of the TVs being non-compliant. Or their particular behavior cause unknown bugs in the kernel/HDMI driver which crash the system at boot. Anyway, I don’t expect any fix on this issue any time soon, because the problem is only present on those TVs and I’m probably the only one in the world to use them with a Jetson.

To summarize:

  • As far as I’m concerned, 2160p60 works out of the box provided compliant EDID.
  • The OLED LG UHD TVs trigger unknown bugs in the kernel, which render them totally unusable with a Jetson (TX1/TX2). It’s unlikely anyone will ever chase such weird and use-case specific bugs.

EDIT: after more careful testing, it turns out that only one TV interrupts boot. On 2 other TVs (maybe the same model); the Jetson boots in 1080p.
In the Xorg log, the 2160p60 mode is rejected (still with “ModeDebug”) because “YUV mode is not supported”.

This reopens the issue of forcing a mode.

I extracted a correct mode with the DELL monitor, which is reported by xorg as follows:

[   580.945] (II) NVIDIA(GPU-0):   Validating Mode "3840x2160_60":
[   580.945] (II) NVIDIA(GPU-0):     Mode Sources: NVIDIA Predefined, EDID, CEA, Detailed
[   580.945] (II) NVIDIA(GPU-0):     3840 x 2160 @ 60 Hz
[   580.945] (II) NVIDIA(GPU-0):       Pixel Clock      : 594.18 MHz
[   580.945] (II) NVIDIA(GPU-0):       HRes, HSyncStart : 3840, 4016
[   580.945] (II) NVIDIA(GPU-0):       HSyncEnd, HTotal : 4104, 4400
[   580.945] (II) NVIDIA(GPU-0):       VRes, VSyncStart : 2160, 2168
[   580.945] (II) NVIDIA(GPU-0):       VSyncEnd, VTotal : 2178, 2250
[   580.945] (II) NVIDIA(GPU-0):       H/V Polarity     : +/+
[   580.945] (II) NVIDIA(GPU-0):     Mode "3840x2160_60" is valid.

I added this line to xorg.conf:

Modeline    "3840x2160_60.00" 594.18 3840 4016 4104 4400 2160 2168 2178 2250 +HSync +VSync

It fails in the same way:

[   580.952] (WW) NVIDIA(GPU-0):   Validating Mode "3840x2160_60":
[   580.952] (WW) NVIDIA(GPU-0):     Mode Source: X Configuration file ModeLine
[   580.952] (WW) NVIDIA(GPU-0):     3840 x 2160 @ 60 Hz
[   580.952] (WW) NVIDIA(GPU-0):       Pixel Clock      : 594.18 MHz
[   580.952] (WW) NVIDIA(GPU-0):       HRes, HSyncStart : 3840, 4016
[   580.952] (WW) NVIDIA(GPU-0):       HSyncEnd, HTotal : 4104, 4400
[   580.952] (WW) NVIDIA(GPU-0):       VRes, VSyncStart : 2160, 2168
[   580.952] (WW) NVIDIA(GPU-0):       VSyncEnd, VTotal : 2178, 2250
[   580.952] (WW) NVIDIA(GPU-0):       H/V Polarity     : +/+
[   580.952] (WW) NVIDIA(GPU-0):     Mode is rejected: Only modes from the NVIDIA X driver's
[   580.952] (WW) NVIDIA(GPU-0):     predefined list and modes from the EDID are allowed
[   580.952] (WW) NVIDIA(GPU-0):     Mode "3840x2160_60" is invalid.

So, obviously, ModeLine workaround can’t work anyway (mode does not come from EDID → is not compared to predefined list → is rejected because “NVidia predefined” is missing from “Mode Sources”).

38

Hi Maxbns,

Yes, most of TVs by default use YUV mode. However, jetson HDMI-out only supports RGB now. The plan for support YUV is still unknown. The workaround for userspace driver (X11) is filtering out the YUV mode from EDID.

I am really sorry about this.

39

Thanks.

I’m pretty sure the TV supports RGB as well (since it works in 1080p).

Things may work if I’m able to force an output mode, regardless of EDID (I have other devices which do that and it works with all TVs). So we’re back to the same old question.

How can a predefined mode be used and not rejected by the NVidia driver? Is there anyone I can contact in order to get the technical indications on how to make it work? (a contact to a driver team)

I’m OK if the mode is hardcoded into the kernel and the resulting kernel only supports one mode. But it’s important that it works.

40

Hi Maxbns,

Few ways are available if you could rebuild the kernel.

  1. Hacking a EDID which you are pretty sure that would work in edid.c.

  2. Use original EDID and try to figure out what is the best mode you want in hdmi driver.