Changing TX2 default video output setting and issues seeing and entering into uboot

Autonomous Machines Jetson & Embedded Systems Jetson TX2
1

Hi all,

When I boot up the TX2, there is a ~7 seconds that kernel console output has not shown up, and due to the default video setting of the tx2 there are strange looking stripes on the monitor. My initial guess is that it is due to uboot waiting timeout, and as soons as Ubuntu loads video will look ok. The attached gif illustrates the issue I am having.

I’ve looked at the git://nv-tegra.nvidia.com/3rdparty/u-boot.git (l4t 32.5) and tried to add either of the following to the /boot/extlinux/extlinux.conf. These did not change anything.
video=HDMI-A-1:1280x800@60
video=HDMI-A-1

I have also tried to remove parameters like TIMEOUT and rootwait, but they also didn’t change anything.

I next consider the possibility of uboot timeout being too long. This is based on an assumption that when Linux kernel loads the stripes disappear and console show up properly (with dmesg). I proceed to connect to uart0 and expect to see uboot output and be able to enter into menu to change timeout option. However, I could not observe any uboot output from the uart0 debug output. The attached uart0_output.txt illustrates this. I also attach the dmesg from the booting system (dmesg.txt) for comparison. I made an assumption that perhaps uboot’s message was hidden due to some setting, and trie clicking on various keys at boot up to enter into uboot menu. All my keystrokes seemed ignored and the system still booted to Ubuntu.

So I have two questions:

  1. Is there a way to set default video output setting to match HDMI output of 1280x800?
  2. Is there a way to show uboot output on console and enter into uboot menu on TX2 so I can change timeout settings?

Lastly, if it’s very obvious that I’m on the wrong track to solve my problem, please enlighten me.

Reference - feedback from monitor vendor:

This is a common issue that is caused when your SBC BIOS initially boots up with a temporary default video output setting (most likely VGA) that is not compatible with the ELI101-IPHW WXGA requirements of 1280 x 800. Since ELI units don’t upscale or downscale video inputs, they often can’t properly display video resolutions that are outside of their expected range or resolution. Since your BIOS is temporarily giving the ELI101-IPHW a VGA resolution signal, and ELI is expecting WXGA resolution, the distortion that you are seeing can possibly occur.

Once the SBC is up and running the OS (Windows or Linux) typically reads the EDID file from the ELI unit and properly sets the video output and timing, so the display is then correct.

If you can change the default boot image settings in your SBC BIOS then you can prevent the issue with the incorrect video setting at power up.

dmesg.txt (67.1 KB)
extlinux.conf.txt (880 Bytes)
bootup
uart0_output.txt (54.4 KB)

2

I can’t answer this. NVIDIA will have to respond, but here is some additional information which might be of use.

Jetsons don’t have a BIOS. Thus much of the clock and power rail and general pin setup are in software which is flashed as a non-rootfs partition (actual partitions in eMMC models, QSPI in SD card models). Sometimes some of the device tree is read there during boot. Sometimes that content is edited before finally passing it on to the Linux kernel (mostly it is verbatim).

For Jetsons the video configuration does have a default, but actual monitor specification is read only via EDID (which is an i2c interface over the DDC wire of HDMI). If the modes supported by your monitor are not supported by the Jetson hardware and software, then that mode will never be picked regardless of device tree. However, if something odd happens, sometimes being in a useful default mode matters (e.g., if you don’t have EDID and you get lucky). The WXGA leads me to believe you’re not using the HDMI+DDC wire interface. You might comment on that.

In your extlinux.conf you might want to remove the token “quiet” to increase logging.

In your “/etc/X11/xorg.conf” (or if looking at the source of flash, the “Linux_for_Tegra/rootfs/etc/X11/xorg.conf”, you might want to edit the section “Device” to provide verbose driver comment on what it thinks of supplied EDID video modes (only applies if you have the DDC wire):

Section "Device"
    Option "ModeDebug"
...
EndSection

During startup of the GUI your system will produce log file “/var/log/Xorg.0.log” (the number might differ, just use the one with the most recent timestamp: “ls -ltr /var/log/Xorg.*.log | tail -n 1”). I’ll advise posting that log plus the serial console boot log with the “quiet” removed.

4

@linuxdev thanks for your feedback. Attached please find some files and I’ll be happy to try more of your suggestion based on those logs.

  • The serial debug output at startup
  • A short video of the startup
  • The Xorg.0.log (listed by “ls -ltr /var/log/Xorg.*.log | tail -n 1”)

What I noticed is that once TX2 is powered up, there is still 3~4 seconds before serial debug port outputs anything. According to the video the timestamps is as below:

0:01 - Connect power
0:05 - Minitor turns on and stripes start to appear
0:13 - Serial debug start to output
0:15 - Monitor starts to output
0:23 - Serial debug shows login
0:31 - Monitor shows login

Just to re-iterate my main problem: I want to get rid of the stripes showing on the screen, which is pretty much from 0:05 ~ 0:13 in the video.

The content of Xorg.0.log actually shows quite a few modes and at the end (line 3030) seems to suggest something failed. However, what bugs me is that throughout the entire Xorg.0.log, the timestamp is from 11.112 to 12.952. In the video I captured, at the moment when monitor (not serial debug) start to show console logs, the timestamp from serial log is around 3~4 (around line 491 in serial_debug_log.txt that says “tegradc 15210000.nvdisplay: hdmi: tmds rate:73020K prod-setting:m”). If Xorg.0.log is relevant, why did the log happen so much later (7~8 seconds late) than the point the screen turned on?

@kayccc I saw you tagged this under Ubuntu. Any suggestions for me to try as well?

serial_debug_log.txt (54.8 KB)
Xorg.0.log (201.9 KB)

5

Hi,

Just some points here

  1. Actually, the earliest one that will initiate display is cboot and we didn’t enable display in uboot. There is no “BIOS” in jetson TX2’s boot stage. Only these two bootloaders have chance to enable display.

  2. Although you told us you attached a “serial_debug_log” or “uart0_output.txt”, actually that one is just another dmesg. Not the log with bootloader.
    I don’t know how you dumped your log. But looks like that one is not from UART console.

6

Hi @WayneWWW thanks for your input. I’m clear that there’s no BIOS in Jetson TX2. Like I mentioned before, I want to get rid of the stripes showing on the screen, which is from 0:05 ~ 0:15 in the video (apologies if my previous message says 13s, it’s actually 15s, because while serial debug is outputting, monitor still do not show console output and only show stripes).

  • So between 0:05~0:15, is it uboot, or cboot, or something else (nvboot?) working? What would you suggest to modify in order to not have stripes during this time? Whatever that is, it should kick in at 0:05 in order to avoid stripes showing.
  • Based on the X.org.log, is there anything you think we can try so TX2 can recognize this monitor properly?

Regarding your comment that you don’t trust “serial_debug_log” or “uart0_output.txt” as actual uart console. If you look at the end of both files, you will see the last lines saying ttyS0. I’ve done another recording to illustrate how I’m able to get the uart0 output. I basically connected uart1 from another TX2 to the target TX2’s uart0 and used minicom to connect, and I copied the received data.

“”"
Ubuntu 18.04.5 LTS adsf-desktop ttyS0

adsf-desktop login:
“”"

Lastly, I’ve also connected the TX2 to a dell monitor, which does not have this “stripes” issue. I am attaching the serial output log, the Xorg.0.log, and also a video recording for this setup. In the beginning of this setup I also briefly shows how I connected the serial port from one TX2/Spacely to another TX2/Spacely. At the end of the video you should see left monitor showing TX2 output and a console window on the right monitor showing serial debug output. I’m hoping this can help for comparison/clarification.

dell_monitor_serial_debug.txt (54.9 KB)
dell_monitor_Xorg.0.log (225.1 KB)
prove_I_am_getting_serial_output

7

Hi,

Sorry that I don’t think this information can provide any help at this moment.

You can look into how other users dumped their log from our devkit and how those logs look like first.

Honestly, we don’t know anything about the board you are using. It is also possible that you are using a customized BSP from vendor that disables the bootloader log already.

Xorg log is only for kernel side. dmesg is also for kernel side so there is nothing I can help at this moment unless you provide the bootloader log. Also, I am not sure if you really know yourself is doing. For example, you said you are also debugging uboot issue, but how did you check that without seeing that log? Just “feel” it?

8

A note about the Xorg.0.log: The only valid mode is:

[    11.278] (II) NVIDIA(GPU-0):   Validating Mode "1280x800_60":
[    11.278] (II) NVIDIA(GPU-0):     Mode Sources: EDID, Detailed
[    11.278] (II) NVIDIA(GPU-0):     1280 x 800 @ 60 Hz
[    11.278] (II) NVIDIA(GPU-0):       Pixel Clock      : 73.02 MHz
[    11.278] (II) NVIDIA(GPU-0):       HRes, HSyncStart : 1280, 1375
[    11.278] (II) NVIDIA(GPU-0):       HSyncEnd, HTotal : 1435, 1461
[    11.278] (II) NVIDIA(GPU-0):       VRes, VSyncStart :  800,  816
[    11.278] (II) NVIDIA(GPU-0):       VSyncEnd, VTotal :  831,  833
[    11.278] (II) NVIDIA(GPU-0):       H/V Polarity     : -/-
[    11.278] (II) NVIDIA(GPU-0):     Mode "1280x800_60" is valid.
...
[    11.831] (II) NVIDIA(GPU-0): --- Modes in ModePool for FDI ELI101-IPHW (DFP-0) ---
[    11.831] (II) NVIDIA(GPU-0): "nvidia-auto-select" : 1280 x  800 @  60.0 Hz  (from: EDID, Detailed)
[    11.831] (II) NVIDIA(GPU-0): "1280x800"           : 1280 x  800 @  60.0 Hz  (from: EDID, Detailed)
[    11.831] (II) NVIDIA(GPU-0): "1280x800_60"        : 1280 x  800 @  60.0 Hz  (from: EDID, Detailed)
[    11.831] (II) NVIDIA(GPU-0): --- End of ModePool for FDI ELI101-IPHW (DFP-0): ---

The video looks like a normal boot.

Emphasizing something @WayneWWW mentions, that is not a serial console log. The dmesg log is indeed contained at the trailing edge of a serial console log, but dmesg does not include any logging from before the Linux kernel is loaded. This means none dmesg cannot help debugging what happens before Linux starts. Serial console can help debug those parts of boot which a traditional PC would consider the BIOS, plus bootloader. Any kind of video is very hard to follow, whereas full serial console log is easy to read. I saw minicom was listed as the source, which is correct, and means it is from the serial console…but the log did not start until Linux was running. Was that minicom log started only after power was started? If this was instead a log which began prior to applying power, then it is unusual that boot stages were entirely missing in the log.

1 Like
9

@linuxdev @WayneWWW ,

I agree with your concerns about not seeing U-Boot messages. I’ve switch the setup to a TX2 dev kit, which also shows the strips issue mentioned in OP. Please see attached video. As usual, I’ve also logged the boot log from the dev kit. Timestamps as follows:

0:03 - Turn on power. I see logs from uart0 right away
0:05 - Monitor turns on and stripes start to appear
0:07 - Timeout for autoboot shows up (seems to start at 2 seconds)
0:11 - “Starting kernel” appears
0:13 - Monitor starts to output. Stripes disappears.
0:19 - Serial debug shows login
0:31 - Monitor shows login

Not sure if this is helpful but I have tried to enter into the U-Boot menu and do a printenv. I’ve attached the printout. While in the uboot menu. The monitor will continue to show stripes.

What do you think should be the next step? Again I want to prevent stripes showing at boot up with this particular monitor. I have also connected the dev kit to another desktop monitor and do not see this stripe issue. I’m guessing I need to change default video setting (1280x800_60) at U-Boot level for TX2. Am I on the right track? Would you mind show me the full commands? There are quite a few commands I have try to find and not sure if they are actually appropriate for TX2 (ref1) (ref2).

Note: I again tried to add either of the following to the /boot/extlinux/extlinux.conf, and same as before did not change anything.
video=HDMI-A-1:1280x800@60
video=HDMI-A-1

For the command to change the default video setting in U-Boot. Would you mind show me the full command?

2022.12.09_bootlog.txt (20.2 KB)
2022.12.09_uboot_printenv.txt (3.9 KB)

10

actually I think we need to disable the hdmi initialization in cboot first. I don’t think uboot would do anything to your panel.

11

@WayneWWW thanks for your prompt response. Is the cboot configuration/modification something that your team can provide? Or could you provide any lead for me to try disabling hdmi initialization in cboot?

12

Hi,

This requires to rebuild the device tree. Please add below to the corresponding sor node.

bootloader-status = “disabled”

13

@WayneWWW thanks for the lead. I am unfamiliar to this area so I have tried based on other information I found in different forum discussions. In short, what I did didn’t resolve the problem.

What I have done is first identify the dts being used

nvidia@nvidia-desktop:/boot$ dmesg | grep .dts
[    0.164181] DTS File Name: /dvs/git/dirty/git-master_linux/kernel/kernel-4.9/arch/arm64/boot/dts/../../../../../../hardware/nvidia/platform/t18x/quill/kernel-dts/tegra186-quill-p3310-1000-c03-00-base.dts
[    0.429296] DTS File Name: /dvs/git/dirty/git-master_linux/kernel/kernel-4.9/arch/arm64/boot/dts/../../../../../../hardware/nvidia/platform/t18x/quill/kernel-dts/tegra186-quill-p3310-1000-c03-00-base.dts
[    0.433008] tegra-pmc c360000.pmc: scratch reg offset dts data not present

Unfortunately I could not find tegra186-quill-p3310-1000-c03-00-base.dts on both dev kit and the Linux_for_Tegra folder. I then confirm there is a tegra186-quill-p3310-1000-c03-00-base.dtb in the /boot directory on the TX2 DevKit, and run for following to get the dts file.

sudo dtc -I dtb tegra186-quill-p3310-1000-c03-00-base.dtb -o src.dts

The modified dts file is attached. Line 9097 and 9102 has the addition bootloader-status = “disabled”; The reason for two locations is because you mentioned another location here.

sor {
	compatible = "nvidia,tegra186-sor";
	reg = <0x0 0x15540000 0x0 0x40000>;
	nvidia,sor-ctrlnum = <0x0>;
	nvidia,dpaux = <0x93>;
	nvidia,xbar-ctrl = <0x0 0x1 0x2 0x3 0x4>;
	clocks = <0x10 0x61 0x10 0x27 0x10 0x267 0x10 0x128 0x10 0x20b 0x10 0x10d 0x10 0x88 0x10 0x66 0x10 0x58 0x10 0x62>;
	clock-names = "sor0_ref", "sor_safe", "sor0_pad_clkout", "sor0", "pll_dp", "pllp_out0", "maud", "hda", "hda2codec_2x", "hda2hdmi";
	resets = <0x10 0x27 0x10 0xf 0x10 0x10 0x10 0x11>;
	reset-names = "sor0", "hda_rst", "hda2codec_2x_rst", "hda2hdmi_rst";
	status = "disabled";
	nvidia,ddc-i2c-bus = <0x94>;
	nvidia,active-panel = <0x95>;
	nvidia,hpd-gpio = <0x1b 0x78 0x1>;
	linux,phandle = <0x91>;
	phandle = <0x91>;
	bootloader-status = "disabled";

	hdmi-display {
		compatible = "hdmi,display";
		status = "disabled";
		bootloader-status = "disabled";
		generic-infoframe-type = <0x87>;
		linux,phandle = <0x1d0>;
		phandle = <0x1d0>;

I then created the dtb file again.
dtc -I dts src.dts -o tegra186-quill-p3310-1000-c03-00-base.dtb

I then copied to the following locations. Sorry, I’m not really clear where I should copy the file, so I did all of them.
/JetPack_4.5_Linux_JETSON_TX2/Linux_for_Tegra/bootloader/t186ref/ (ref)
/JetPack_4.5_Linux_JETSON_TX2/Linux_for_Tegra/kernel/dtb/ (I thought this could be the location)
/JetPack_4.5_Linux_JETSON_TX2/Linux_for_Tegra/bootloader (I thought this could be the location)

I then run the following command with the assumption that this could be relevant to my dtb update.
sudo ./apply_binaries.sh

Finally, I deleted the /bootloader/system.img file and ran the following to flash to the TX2 DevKit.
sudo ./flash.sh jetson-tx2 mmcblk0p1

Once I flashed, the image, I followed the instruction to set up account/etc, and did a clean software reboot. I then tried power cycling the system.

The result is the same. I still see the same stripes described in OP. From this newly flashed devkit image, I also extracted the tegra186-quill-p3310-1000-c03-00-base.dtb to dts and verified the line is there (and the dtb timestamp matches the time when I flash the devkit).

What could be missing?
src.dts (494.9 KB)

14

Hi,

  1. Every time you change anything, share out your log instead of only telling us the symptom. Telling 100 kinds of symptoms won’t provide as much info as your serial console log.

  2. Please download the source code from the website and follow the document to build the kernel. Put your new dtb to JetPack_4.5_Linux_JETSON_TX2/Linux_for_Tegra/kernel/dtb/. Delete the old one under /JetPack_4.5_Linux_JETSON_TX2/Linux_for_Tegra/bootloader.

1 Like
15

@WayneWWW thanks for the feedback. I have downloaded the source file for kernel. From what I could find, the tegra186-quill-hdmi-primary-p3310-1000-c03-00.dts referenced tegra186-quill-hdmi-primary-p3310-1000-a00-00.dts, inside which I found the following sor and sor1 nodes, and I have added under each bootloader-status = “disabled”;

host1x {
	sor {
		status = "disabled";
		bootloader-status = "disabled";
		dp-display {
			status = "disabled";
		};
		hdmi-display {
			status = "disabled";
		};

		panel-s-edp-uhdtv-15-6 {
			smartdimmer {
				status = "disabled";
			};
		};
	};

	dpaux@155c0000 {
		status = "disabled";
	};

	sor1 {
		status = "okay";
		bootloader-status = "disabled";
		nvidia,active-panel = <&sor1_hdmi_display>;
		hdmi-display {
			status = "okay";
		};
		dp-display {
			status = "disabled";
		};
	};

I then compiled the kernel, copied the related resource files, and flashed the TX2 DevKit. From my new captured video, you can see monitor is not turned on until kernel has started, which immediately brings it to console. Is this what you are expecting? Bootlog also attached.

I want to do a quick step back from my OP. I asked “Is there a way to set default video output setting to match HDMI output of 1280x800?” Is the answer “NO”? Right now we are just keeping monitor off in cboot until kernel is loaded to avoid stripe lines, but if the default HDMI output was correct, then there won’t be stripes lines to begin with. There may also be the added benefit of having splash on boot you mentioned elsewhere. If I can change default video output to 1280x800 @60Hz, how do I do that?

bootlogtxt (20.7 KB)

17

Sorry that could you just confirm if the result is good now if we disable the cboot to initalize the display?

If you just want a yes or no answer to if you can configure mode in cboot, then the answer is probably no.

Cboot can only supports some common mode. However, this software is open source, so maybe you can directly hack into the driver and configure the timing and see if it can work.
I cannot guarantee if this would work or not.

18

@WayneWWW from visual inspection, this does indeed remove the stripes that used to show on screen. I’ll do more test with my custom board later but we can mark this as resolved.

Thanks for your feedback on cboot. I’m still interested to see if this can work. Is this something you can provide some lead on, or I’m pretty much on my own? If I pursue this path should I open a new question?

20

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