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

I just received the TX2 development kit. It worked fine out of the box, I also flashed it with JetPack to get the latest OS release (R27.1).

When I try plugging it into a 4K TV with a high-speed HDMI cable, here is what happens:

• Nothing happens for about 10 seconds
• The TV wakes up, and shows the boot console (in 4K) stopped at “vrr_setup failed”.

The last lines of boot are :
“Parent Clock set for DC plldZ
dc clk 594000000
tegradc 15210000.nvdisplay: Link compression not supported by the panel
rate get on compclk 594000000
tegradc 15210000.nvdisplay: Window 3 assigned to head 1
tegradc 15210000.nvdisplay: Window 4 assigned to head 1
tegradc 15210000.nvdisplay: Window 5 assigned to head 1
tegradc 15210000.nvdisplay: vrr_setup failed”

Those lines are different from (working) 1080p boot by the HDMI clock (apparently set to 594MHz instead of 148.5Mhz). A lot of boot lines seem missing (normal boot has ~2000 lines after 3 seconds).

Is this a known issue? How can I fix it?

The vrr_setup failed seems to be normal. However, there were issues with the original L4T R27.01 the TX2 arrives with. Reliability is much better in R27.1.

Aside from that, there are times when video fails, but the system is otherwise running ok. If you look at your router, can you see a DHCP request? Can you ping that address from wired ethernet? Can you ssh to the Jetson?

If you can ssh in, what is the content from this (it’s EDID query data from the TV):

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

FYI, the downloads page for the current L4T R27.1 is here:
https://developer.nvidia.com/embedded/linux-tegra

If you are just flashing, you can download driver package plus sample rootfs and flash using any x86_64 Linux PC with the micro-B USB cable. You can also use the front end to flashing and package installs, “JetPack”. If you use JetPack you need an Ubuntu 14.04 PC host (some people make it work with Ubuntu 16.04).

Thanks for the reply.

Here is the output of cat /etc/ng_tegra_release :

# R27 (release), REVISION: 1.0, GCID: [...]

I already flashed the module with JetPack latest version (from Ubuntu 16.04 amd64. It should work well since it’s only copying binaries : either the copy fails -obsolete command in Ubuntu 16.04- or the copy works and copies the right data).

I will try the ssh method shortly.

In the case described first, the board does not connect to the network (so I can’t ssh to it).

But I made more experiments:

• (described in first post) 4K TV LG OLED 55" (newer): shows beginning of boot process in 4K but hangs (sometimes more things happen, which usually end up in errors and reboot)
• On another 4K TV (Samsung LCD, 48"), the system boots in 4K and everything seems to work.
• On another 4K TV (LG OLED 55", but older than first one): the system boots fine in 1080p, then switching to 4K from the desktop works fine.

So, it seems I could make it work in any case, but I need to:

• Force default resolution to 1080p if possible (even if screen supports 2160p), at a lower HDMI clock
• Change resolution from a script or a program (how?)

Also, it seems I do have the latest version:

# R27 (release), REVISION: 1.0, GCID: 8566447, BOARD: t186ref, EABI: aarch64, DATE: Thu Mar  2 05:14:54 UTC 2017

To force a resolution, I looked at [url]https://devtalk.nvidia.com/default/topic/979180/jetson-tk1/hdmi-out-without-edid-and-i2c/#[/url].

After generating static EDID file (for 1080p), adding CONFIG_DRM_LOAD_EDID_FIRMWARE=y to the kernel config (with dependencies, cf. other thread to find it), adding “drm_kms_helper.edid_firmware=edid/1920x1080.bin” to the command line (generated fw file is /lib/firmware/edid/1920x1080.bin), nothing different happens (the module is never called).

I can’t think of other ways to force a resolution.

If ssh fails you might consider serial console. The TX2 is the same as a TX1 for this, except CTS/RTS wires are not used for TX2 (meaning you set to software flow control instead of CTS/RTS). See:
[url]http://elinux.org/Jetson/TX1_Serial_Console[/url]
[url]http://www.jetsonhacks.com/2017/03/24/serial-console-nvidia-jetson-tx2/[/url]

I captured all the logs.

Logs with ‘nvdisplay’ or ‘rate’:

• Normal boot @1080p:

[    1.019085] iommu: Adding device 15210000.nvdisplay to group 34
[    1.920597] tegradc 15210000.nvdisplay: Display dc.15210000 registered with id=0
[    1.920746] tegradc 15210000.nvdisplay: DT parsed successfully
[    1.927808] tegradc 15210000.nvdisplay: vblank syncpt # 7 for dc 1
[    1.927812] tegradc 15210000.nvdisplay: vpulse3 syncpt # 8 for dc 1
[    1.960554] tegradc 15210000.nvdisplay: probed
[    2.374479] tegradc 15210000.nvdisplay: fb registered
[    2.374479] tegradc 15210000.nvdisplay: fb registered
[    2.382007]  rate get on hub 408000000
[    2.382007]  rate get on hub 408000000
[    2.387501] tegradc 15210000.nvdisplay: Link compression not supported by the panel
[    2.387501] tegradc 15210000.nvdisplay: Link compression not supported by the panel
[    2.387505]  rate get on compclk 148500000
[    2.387505]  rate get on compclk 148500000
[    2.402701] tegradc 15210000.nvdisplay: Window 3 assigned to head 1
[    2.402701] tegradc 15210000.nvdisplay: Window 3 assigned to head 1
[    2.419359] tegradc 15210000.nvdisplay: Window 4 assigned to head 1
[    2.419359] tegradc 15210000.nvdisplay: Window 4 assigned to head 1
[    2.436032] tegradc 15210000.nvdisplay: Window 5 assigned to head 1
[    2.436032] tegradc 15210000.nvdisplay: Window 5 assigned to head 1
[    2.580890] tegradc 15210000.nvdisplay: vrr_setup failed
[    3.548270] sdhci-tegra 3460000.sdhci: Parent select= pll_p rate=408000000
[    3.548547] sdhci-tegra 3460000.sdhci: Parent select= pll_c4_out0 rate=196249804
[    3.584084] sdhci-tegra 3440000.sdhci: Parent select= pll_p rate=408000000
[    3.616256] sdhci-tegra 3400000.sdhci: Parent select= pll_p rate=408000000
[    7.593349] tegradc 15210000.nvdisplay: blank - normal
[    7.602675] tegradc 15210000.nvdisplay: unblank
[56] tegradc 15210000.nvdisplay: hdmi: plugged
[   18.370170] tegradc 15210000.nvdisplay: blank - powerdown
[   18.493133] tegradc 15210000.nvdisplay: unblank
[   18.494312]  rate get on hub 408000000
[   18.497562] tegradc 15210000.nvdisplay: Link compression not supported by the panel
[   18.497565]  rate get on compclk 148500000
[   18.513274] tegradc 15210000.nvdisplay: Window 3 assigned to head 1
[   18.529936] tegradc 15210000.nvdisplay: Window 4 assigned to head 1
[   18.546604] tegradc 15210000.nvdisplay: Window 5 assigned to head 1
[   19.599858] tegradc 15210000.nvdisplay: unblank
[   20.036808] tegradc 15210000.nvdisplay: blank - powerdown
[   20.175378] tegradc 15210000.nvdisplay: unblank
[   20.177155]  rate get on hub 408000000
[   20.190004] tegradc 15210000.nvdisplay: Link compression not supported by the panel
[   20.190012]  rate get on compclk 148500000
[   20.196711] tegradc 15210000.nvdisplay: Window 3 assigned to head 1
[   20.213371] tegradc 15210000.nvdisplay: Window 4 assigned to head 1
[   20.230040] tegradc 15210000.nvdisplay: Window 5 assigned to head 1
[   22.469686] tegradc 15210000.nvdisplay: blank - powerdown
nvidia@tegra-ubuntu:~$ [   22.586729] tegradc 15210000.nvdisplay: unblank
[   22.588467]  rate get on hub 408000000
[   22.591688] tegradc 15210000.nvdisplay: Link compression not supported by the panel
[   22.598139]  rate get on compclk 148500000
[   22.607418] tegradc 15210000.nvdisplay: Window 3 assigned to head 1
[   22.624079] tegradc 15210000.nvdisplay: Window 4 assigned to head 1
[   22.640749] tegradc 15210000.nvdisplay: Window 5 assigned to head 1
[   22.911976] pll_a_out0 = 22579200 Hz, aud_mclk = 11289600 Hz, codec rate = 44100 Hz
[   22.965631] pll_a_out0 = 22579200 Hz, aud_mclk = 11289600 Hz, codec rate = 44100 Hz
[   22.997436] pll_a_out0 = 22579200 Hz, aud_mclk = 11289600 Hz, codec rate = 44100 Hz
[   23.032682] pll_a_out0 = 22579200 Hz, aud_mclk = 11289600 Hz, codec rate = 44100 Hz
[   23.035103] pll_a_out0 = 22579200 Hz, aud_mclk = 11289600 Hz, codec rate = 44100 Hz
[   23.039101] pll_a_out0 = 22579200 Hz, aud_mclk = 11289600 Hz, codec rate = 44100 Hz
[   23.065886] pll_a_out0 = 22579200 Hz, aud_mclk = 11289600 Hz, codec rate = 44100 Hz
[   23.068266] pll_a_out0 = 22579200 Hz, aud_mclk = 11289600 Hz, codec rate = 44100 Hz
[   23.075150] pll_a_out0 = 22579200 Hz, aud_mclk = 11289600 Hz, codec rate = 44100 Hz
[   23.125879] pll_a_out0 = 22579200 Hz, aud_mclk = 11289600 Hz, codec rate = 44100 Hz
[   23.782680] tegradc 15210000.nvdisplay: unblank
[   26.946131] tegradc 15210000.nvdisplay: blank - powerdown
[   27.064252] tegradc 15210000.nvdisplay: unblank
[   27.065384]  rate get on hub 408000000
[   27.068811] tegradc 15210000.nvdisplay: Link compression not supported by the panel
[   27.068816]  rate get on compclk 148500000
[   27.084333] tegradc 15210000.nvdisplay: Window 3 assigned to head 1
[   27.100990] tegradc 15210000.nvdisplay: Window 4 assigned to head 1
[   27.117660] tegradc 15210000.nvdisplay: Window 5 assigned to head 1
[   27.189350] tegradc 15210000.nvdisplay: unblank

Failing log @4k:

[    1.022256] iommu: Adding device 15210000.nvdisplay to group 34
[    1.925203] tegradc 15210000.nvdisplay: Display dc.15210000 registered with id=0
[    1.925391] tegradc 15210000.nvdisplay: DT parsed successfully
[    1.932235] tegradc 15210000.nvdisplay: vblank syncpt # 7 for dc 1
[    1.932240] tegradc 15210000.nvdisplay: vpulse3 syncpt # 8 for dc 1
[    1.963937] tegradc 15210000.nvdisplay: probed
[    2.427834] tegradc 15210000.nvdisplay: fb registered
[    2.427834] tegradc 15210000.nvdisplay: fb registered
[    2.488499]  rate get on hub 408000000
[    2.981448] tegradc 15210000.nvdisplay: Link compression not supported by the panel
[    2.989315]  rate get on compclk 594000000
[    3.006748] tegradc 15210000.nvdisplay: Window 3 assigned to head 1
[    3.023415] tegradc 15210000.nvdisplay: Window 4 assigned to head 1
[    3.040102] tegradc 15210000.nvdisplay: Window 5 assigned to head 1
[    3.170595] tegradc 15210000.nvdisplay: vrr_setup failed

Other logs
Everything is the same at start (apart from a few reordered lines). The last common line is:

[    2.939911] ata1: SATA link down (SStatus 0 SControl 300)

After that, working boot does a bunch of other things (starting with random, then fan, coresight…) whereas failing boot does:

[    2.944842] Parent Clock set for DC plld2
[    2.951549]  dc clk 594000000
[    2.981448] tegradc 15210000.nvdisplay: Link compression not supported by the panel
[    2.989315]  rate get on compclk 594000000
[    3.006748] tegradc 15210000.nvdisplay: Window 3 assigned to head 1
[    3.023415] tegradc 15210000.nvdisplay: Window 4 assigned to head 1
[    3.040102] tegradc 15210000.nvdisplay: Window 5 assigned to head 1
[    3.170595] tegradc 15210000.nvdisplay: vrr_setup failed

Do you have the output from this:

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

Note that HDMI is hotplug (I assume you are using HDMI). In cases where you boot first without connection and then later attach the TV…or where you boot, detach, and re-attach, things in theory would work the same…but the hotplug layer can can sometimes get past certain issues which normal boot may hang on (order of connecting the cable manually may be a workaround in some cases). Experiment with that.

That EDID file listed above should result from the query to your TV when it is connected. The log file “/var/log/Xorg.0.conf” is specific to the video in GUI mode (there is also console mode…different software). You will want to see this after the failure (you can use “cat” in serial console to log if direct file copy fails and the file system still runs). Before doing this you will want to add this to your “/etc/X11/xorg.conf”, within the Section “Device” (this adds messages about modes your TV supports, but which are rejected by the GPU):

Option      "ModeDebug"

Thanks for the reply.

Hotplug works (and puts screen directly in 4K).

The module seems fairly stable with 1080p screens, maybe NVidia did not experiment enough with 4k to find and fix this bug?

Here is the EDID used after hotplug:

00 ff ff ff ff ff ff 00 1e 6d 01 00 01 01 01 01
01 1a 01 03 80 a0 5a 78 0a ee 91 a3 54 4c 99 26
0f 50 54 a1 08 00 31 40 45 40 61 40 71 40 81 80
01 01 01 01 01 01 08 e8 00 30 f2 70 5a 80 b0 58
8a 00 40 84 63 00 00 1e 02 3a 80 18 71 38 2d 40
58 2c 45 00 40 84 63 00 00 1e 00 00 00 fd 00 3a
3e 1e 88 3c 00 0a 20 20 20 20 20 20 00 00 00 fc
00 4c 47 20 54 56 0a 20 20 20 20 20 20 20 01 9f
02 03 4e f1 54 5d 10 1f 04 13 05 14 03 02 12 20
21 22 15 01 5e 5f 62 63 64 29 3d 06 c0 15 07 50
09 57 07 6e 03 0c 00 40 00 b8 3c 20 00 80 01 02
03 04 e2 00 cf e3 06 05 01 e5 0e 60 65 61 66 ee
01 46 d0 00 24 18 09 00 ad 52 44 a9 23 0c 01 1d
80 18 71 1c 16 20 58 2c 25 00 40 84 63 00 00 9e
66 21 50 b0 51 00 1b 30 40 70 36 00 40 84 63 00
00 1e 00 00 00 00 00 00 00 00 00 00 00 00 00 23

Only problem is, I don’t want to have to unplug the TV every time I boot. It’s supposed to be a seamless power-up flow. Is there any way to force the EDID statically?

It seems that the DRM kernel option (CONFIG_DRM_LOAD_EDID_FIRMWARE) is not used by the NVidia HDMI driver (written in /usr/src/kernel/display/drivers/video/tegra/dc/hdmi2.0.c). I couldn’t find any documentation on how to configure boot time display initialization on the module.

A few options remain, but I don’t know how to implement them:

• Use a similar feature as the LOAD_EDID_FIRMWARE coupled with kernel command line (choose EDID from boot config file), if it exsits in the NVidia HDMI driver.
• Disable HDMI at startup completely, and require a user action to activate it (insmod…) so that boot process is not tampered with and hotplug-like scenario happens.

The EDID data is valid. You can paste it in here if you want to see the TV’s capabilities as reported to the video card:
http://www.edidreader.com

You will need to add this to the device section in “/etc/X11/xorg.conf” before X logs will tell you about intentional mode accept/reject (versus a bug):

Option      "ModeDebug"

With that option and posting the resulting “/var/log/Xorg.0.log” it may be possible to further narrow down where the mode is failing (some modes are rejected and might have an edit possible…other causes could be outright bugs needing a fix…unless you get the log with that option enabled it will be very difficult to know what causes the failure). Should logs indicate the driver rejected a mode it won’t be possible to simply add a command line setting to get that mode…a different approach would then be mandatory.

Unfortunately, it seems Xorg does not even start during the failure. I only have log for previous working boot in Xorg.0.log (which I recognized from the model of the monitor mentioned in the log).

Generally, Xorg log indicates first boot timestamps between 16 and 20 seconds, whereas in my case boot is interrupted at 3 seconds (which is why I can’t see any logs).

If I had to guess, some driver function hangs and blocks the kernel init, which does not happen on hotplug (since kernel init is already done). It happens at a fairly early stage (before most devices are probed). I’m pretty sure that tracing all HDMI driver calls would lead me somewhere, but I’m not really a kernel/driver expert.

You will likely need a serial console to see what goes on right up to the last moment. The earlier post mentions the information on serial console:
[url]TX2 development kit : 4K doesn't work (boot fails) - Jetson TX2 - NVIDIA Developer Forums

If you have a serial console (which can log far more than what is captured on eMMC) debugging would probably be simplified (though not necessarily making it “simple”).

I captured logs already (but I didn’t want to spam with the full log here, so I only kept the apparently-relevant parts).

I can also turn on/off certain debug flags if I know which ones to change in the kernel source or command line.

4K failing log:
[url]https://drive.google.com/open?id=0B1LNhjZnzDqJWXZaelVyMW9ncTg[/url]
(using recent LG OLED 4K TV)
1080p working one (althouth any build would be pretty much the same as this - it was just flashed with R27.1):
[url]https://drive.google.com/open?id=0B1LNhjZnzDqJdTY0QVB1S0ViYXc[/url]
(using regular 1080p Samsung panel)

I hadn’t realized that URL was serial console, I guess I was fooled by the formatting (normally it’s just a .txt file). That particular method of posting the file does not allow me to use copy and paste so it is hard to quote.

One thing I noticed is this (not necessarily an issue, but something to keep in mind): The kernel reports it was built using gcc 5.4.0 20160609. The original kernel is built with gcc 4.8.5. So the kernel was re-built, and sometimes compiler matters (probably not an issue for this, but it could be). More important might be to know what config changes were made.

Right before things diverge and where it still seems normal is when it probes i2c and SATA. After this yours has a huge amount of output which is missing (normally serial console would get this, I’d only expect to see it missing on a regular console). The first thing which fails to show up would be this (this is from my own log):

[    2.813963] [OV5693]: probing v4l2 sensor.
[    3.005169] ata1: SATA link down (SStatus 0 SControl 300)
[    3.597277] <b>gspca_main: v2.14.0 registered</b>
[    3.597321] <b>usbcore: registered new interface driver gspca_zc3xx</b>

It looks like the missing “gspca_main” is V4L (possibly linked through USB). Everything before this is ok. This is line 790 in my log. The next line where things show up again in my own logs as matching yours is line 1344. You’re missing approximately 475 lines of boot log which starts around V4L/USB. Things start logging correctly again at:

[   19.552467] Parent Clock set for DC plld2

This line about the clock is startup of the display. The first failure which wouldn’t be an issue if further up in the log does turn out to be an issue when it is here instead…this is what should have occurred:

[   20.660379] tegradc 15210000.nvdisplay: unblank

…this is what happened (again, this is ok at earlier locations, it doesn’t seem to be ok here…I’m quoting from your earlier post which seemed ok, but which is wrong where it actually occurs again…the time stamp should be around 19 seconds in, not 3.1 seconds):

[    3.170595] tegradc 15210000.nvdisplay: vrr_setup failed

Although the vrr_setup failed message seems normal at about 2.6 seconds in…the 3.1 seconds in fooled me because you are missing 700+ lines of logging which should have taken about 16 seconds longer to reach.

Because the initial missing logs are from V4L (possibly associated with USB), what kind of changes have you made to add USB devices and video devices (especially USB Video devices)?

The URL is a text file (I didn’t notice that you couldn’t copy/paste, sorry! but it’s still downloadable).

I made almost no changes.

I recompiled the kernel because it was failing, so exactly the same problem was happening before I recompiled it. The first kernel was fresh from binary release R27.1.

I did not touch the DTB or the kernel source. The config was retrieved from zcat /proc/configs.gz.
The only change I made to config was using CONFIG_DRM_LOAD_EDID_FIRMWARE (as indicated by the post mentioned above), and the command line telling the kernel to use 1920x1080.bin EDID file. Apparently this option is ignored by the NVidia HDMI driver.

• Would it be useful to have a log with the stock version? (just to make sure)
• I had no devices plugged through USB, but the camera expansion board was there, should I remove it and try again?

I captured a log with the stock kernel: log_stock_uart.txt - Google Drive

Only modifications (as indicated in the log) is the DTB which enables ttyTHS2.

Output of uname -a :

Linux tegra-ubuntu 4.4.15-tegra #1 SMP PREEMPT Wed Mar 1 21:09:29 PST 2017 aarch64 aarch64 aarch64 GNU/Linux

I don’t know if CONFIG_DRM_LOAD_EDID_FIRMWARE is compatible with existing hardware/driver combinations (it might work, but I suspect it has undesired interactions). For example, CONFIG_DRM_LOAD_EDID_FIRMWARE is not even mentioned as existing (but disabled) in “/proc/config.gz” (the source code used in the original kernel seems to differ from the kernel source you used). I am suspicious of this this…you may want to disable this until done solving the current issue (if your EDID was correct in the first place, and matches the monitor, then this would not apply even if there are other reasons for EDID failing…this essentially edits bad EDID firmware and does not help with EDID which is valid but rejected).

The DTB changes would be needed for “/dev/ttyTHS2”, but there is normally no device tree named in extlinux.conf. To make those changes you’d have to either modify U-Boot (which passes on the changes), or else name a device tree file in the extlinux.conf FDT key/value pair. If the FDT key/value pair is used (which is what I do), then the proper dtb file to start with is:

/boot/tegra186-quill-p3310-1000-c03-00-base.dtb

In my case my extlinux.conf points at the modified variant of that file via:

FDT /boot/modified_tegra186-quill-p3310-1000-c03-00-base.dtb

Which dtb file did you start with, or did you build it from kernel source? This could definitely cause some strangeness during boot.

Let me summarize what happened:

1 - I tried with the stock OS (stock kernel, no change to DTB or extlinux.conf). With that particular 4K TV booting failed. I had no serial link yet but I kept some pictures (not very good quality): https://drive.google.com/drive/folders/0B1LNhjZnzDqJaERtR3RhTXpqNlE?usp=sharing
The boot log is very similar to what I posted. It varies, depending on whether the TV was already on the right input, whether I hit the reset button or plugged + power button, but always ends up between 2.7 and 3.2 seconds with similar messages.

2 - Then, I tried to put static EDID data to fix the problem. This is why the option CONFIG_LOAD_EDID_FIRMWARE was on (which seems to be completely ignored by the NVidia HDMI driver anyway - it seems to have its own EDID management, cf. hdmi2.0.c). That’s when I captured the first log.

3 - Last, I reinstalled the stock OS (so, no more CONFIG_DRM_LOAD_EDID_FIRMWARE etc), but was also able to setup the additional UART in the meantime. I got the name of DTB from U-Boot log so I used the right one for decompilation/recompilation: […]-c03-00-base.dtb. This gave the second log above. EDIT: using the FDT key/value pair (actually with the same “modified_” prefix).

Flashing and capturing takes some time, so I would like to do it again only if necessary. Is it absolutely necessary to re-capture logs with the stock OS just flashed?

I’d like to verify that this EDID data is unedited and original from this post (without CONFIG_DRM_LOAD_EDID_FIRMWARE):
https://devtalk.nvidia.com/default/topic/1016146/jetson-tx2/tx2-development-kit-4k-doesn-t-work-boot-fails-/post/5177523/#5177523

Assuming that EDID came from the monitor/TV (unedited), then the monitor EDID is valid and editing will just complicate matters…the fault would be somewhere different than the EDID data itself. I strongly suggest removing CONFIG_DRM_LOAD_EDID_FIRMWARE from the mix while testing.

You can recapture logs with the original kernel (but the modified device tree is ok) without flash. The “/boot/Image” file is named in extlinux.conf, and you could put an alternate name in “/boot”, then add an alternate boot entry in extlinux.conf (you can then select which boot entry you want via serial console…if you interrupt the boot loader too early just run the command “boot”, then interrupt again when it lists which boot entries are available). For example, I have this as an extlinux.conf which also has the “/dev/ttyTHS2” device tree patch:

TIMEOUT 30
DEFAULT ths2

MENU TITLE p2771-0000 eMMC boot options

LABEL primary
      MENU LABEL primary kernel
      LINUX /boot/Image
      APPEND fbcon=map:0 net.ifnames=0 console=tty0 OS=l4t console=ttyS0,115200n8 memtype=0 video=tegrafb no_console_suspend=1 earlycon=uart8250,mmio32,0x03100000 gpt tegraid=18.1.2.0.0 tegra_keep_boot_clocks maxcpus=6 android.kerneltype=normal androidboot.serialno=0335115020673 vpr_resize root=/dev/mmcblk0p1 rw rootwait

LABEL ths2
      MENU LABEL ths2
      FDT /boot/<b>modified_</b>tegra186-quill-p3310-1000-c03-00-base.dtb
      LINUX /boot/Image
      APPEND fbcon=map:0 net.ifnames=0 console=tty0 OS=l4t console=ttyS0,115200n8 memtype=0 video=tegrafb no_console_suspend=1 earlycon=uart8250,mmio32,0x03100000 gpt tegraid=18.1.2.0.0 tegra_keep_boot_clocks maxcpus=6 android.kerneltype=normal androidboot.serialno=0335115020673 vpr_resize root=/dev/mmcblk0p1 rw rootwait

The above defaults to my ths2 label using the stock kernel and “/boot/modified_tegra186-quill-p3310-1000-c03-00-base.dtb” as my FDT entry. This just required adding the dtb to the “/boot” directory, and edit of extlinux.conf. No flash required. Original entry is still there to select via serial console if I want to see the original. Had I renamed a custom kernel I would have probably named it something like “Image-4.4.15-tegra_modified”.

In the end you’ll need to get boot messages from serial console using the original kernel (or rather I should say a kernel without modifications having an effect on the monitor and video). There are literally hundreds of lines of missing log, so we have to narrow it down to existing bugs or bugs introduced by the kernel change…we can’t check the former unless the kernel change is removed. Lines of log which would have been missing on a monitor directly attached to the Jetson would quite likely show up under a serial console (serial console does not require drivers for the most part…without serial console we are using a video device to view log lines from a broken video device…I’m reminded of a dog chasing his own tail).

Yes. I guess I’m giving too much information at a time :)

You have almost what you want (WITH dtb change) in the second log I sent on top of page #2: log_stock_uart.txt - Google Drive

On this run, the original kernel is used. Only the DTB changed (“status”=“okay” for the UART, when compared to /boot/tegra186-quill-p3310-1000-c03-00-base.dtb).

I can fairly easily revert the DTB U-Boot parameter to use the original DTB (as you said), but I won’t be able to test it before tomorrow around 2PM CEST.