ELO Monitor Incompatibility

jalmen · December 21, 2020, 6:55pm

I have a 10in touchscreen ELO monitor I am trying to use with the standard Nano board. When booting the board with this monitor hooked up the board looks to partially boot before something happens causing the board to reboot. Attached is what I see on the screen before the restart. The board works fine with a couple other displays, so the issue looks specific to this monitor. What would be the best place to start to try and troubleshoot this issue?

linuxdev · December 22, 2020, 2:03pm

You’d probably want to get a serial console boot log. Serial console functions even in the bootloader stages prior to Linux ever starting, and has almost no requirements. Basically your PC would record the boot logs for you. See:
https://www.jetsonhacks.com/2019/04/19/jetson-nano-serial-console/

jalmen · December 22, 2020, 3:40pm

Looking through the console boot log it looks like a software reset it triggered right as the kernel starts to load. How could this happen from an HDMI connection? I’ll attach the full log of a couple restarts. Any idea on settings to adjust to work around this issue?

Starting kernel ...

[    0.000000] Booting Linux on physical CPU 0x0
[    0.000000] Linux version 4.9.140-tegra (buildbrain@mobile-u64-4428) (gcc version 7.3.1 20180425 [linaro-7.3-2018.05 revision d29120a424ecfbc167ef90065c0eeb7f91977701] (Linaro GCC 7.3-2018.05) ) #1 SMP PREEMPT Tue 
Oct 27 21:02:37 PDT 2020
[    0.000000] Boot CPU: AArch64 Processor [411fd071]
[    0.000000] OF: fdt:memory scan node memory@80000000, reg size 48,
[    0.000000] OF: fdt: - 80000000 ,  7ee00000
[    0.000000] OF: fdt: - 100000000 ,  7f200000
[    0.000000] Found tegra_fbmem: 00800000@92cb4000
[    0.000000] earlycon: uart8250 at MMIO32 0x0000000070006000 (options '')
[    0.000000] bootconsole [uart8250] enabled
[0000.157] [L4T TegraBoot] (version 00.00.2018.01-l4t-c536fca9)
[0000.163] Processing in cold boot mode Bootloader 2
[0000.167] A02 Bootrom Patch rev = 1023
[0000.171] Power-up reason: software reset
[0000.175] No Battery Present
[0000.177] pmic max77620 reset reason
[0000.181] pmic max77620 NVERC : 0x0
[0000.184] RamCode = 0
[0000.186] Platform has DDR4 type RAM
[0000.190] max77620 disabling SD1 Remote Sense
[0000.194] Setting DDR voltage to 1125mv
[0000.198] Serial Number of Pmic Max77663: 0x2f19f0
[0000.205] Entering ramdump check
[0000.208] Get RamDumpCarveOut = 0x0
[0000.212] RamDumpCarveOut=0x0,  RamDumperFlag=0xe59ff3f8
[0000.217] Last reboot was clean, booting normally!
[0000.221] Sdram initialization is successful

boot_error_log.txt (66.4 KB)

jalmen · December 22, 2020, 9:27pm

I had missed this error message when I try to connect the display after the Nano has already booted.

[  108.011524] tegra-dvfs: rate 768000000 too high for dvfs on disp1
[  108.011527] tegradc tegradc.0: hdmi: set dc parent failed
[  108.016615] tegradc tegradc.0: pclk out of range!
[  108.016618] tegradc tegradc.0: tegra_dc_init: tegra_dc_program_mode failed
[  108.016632] tegradc tegradc.0: _tegra_dc_controller_enable: tegra_dc_init failed
[  108.047231] tegra-dvfs: rate 768000000 too high for dvfs on disp1
[  108.047234] tegradc tegradc.0: hdmi: set dc parent failed
[  108.052985] tegradc tegradc.0: pclk out of range!
[  108.052988] tegradc tegradc.0: tegra_dc_init: tegra_dc_program_mode failed
[  108.053002] tegradc tegradc.0: _tegra_dc_controller_enable: tegra_dc_init failed

linuxdev · December 23, 2020, 3:03pm

I do not see the above in the “boot_error_log.txt”, but this would simply imply the monitor is using values the GPU cannot achieve.

I will suggest that if you modify the Xorg config file to tell the driver to verbosely comment on all modes, then it will tell use useful details about what might actually be out of range. In file “/etc/X11/xorg.conf”, you will see a Section "Device". Within this you’ll add Option "ModeDebug":

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

Then reboot. The log file “/var/log/Xorg.0.log” (or in some cases “Xorg.1.log”) will then tell us details about each mode from the EDID. Save a copy of that log (you might want to rename the copy with a filename extension of “.txt”), and attach a copy to the forum. Then we’ll know what modes might or might not be used.

Do note that the drivers of a Jetson have more restrictions than those of a desktop PC. For example, extension modes and interlaced will always be rejected.

jalmen · December 24, 2020, 4:29pm

Attached is the full log file. It seems to select a mode=“Null”. What is the proper way to set a default mode for it to try?

[   103.764] (II) NVIDIA(GPU-0): --- Modes in ModePool for ELO ET1093L (DFP-0) ---
[   103.764] (II) NVIDIA(GPU-0): "nvidia-auto-select" : 1280 x  800 @  60.0 Hz  (from: EDID, Detailed)
[   103.764] (II) NVIDIA(GPU-0): "1920x1200"          : 1920 x 1200 @  59.9 Hz  (from: EDID)
[   103.764] (II) NVIDIA(GPU-0): "1920x1200_60"       : 1920 x 1200 @  59.9 Hz  (from: EDID)
[   103.764] (II) NVIDIA(GPU-0): "1920x1080"          : 1920 x 1080 @  60.0 Hz  (from: EDID, CEA)
[   103.764] (II) NVIDIA(GPU-0): "1920x1080_60"       : 1920 x 1080 @  60.0 Hz  (from: EDID, CEA)
[   103.764] (II) NVIDIA(GPU-0): "1920x1080_60_0"     : 1920 x 1080 @  60.0 Hz  (from: EDID)
[   103.764] (II) NVIDIA(GPU-0): "1920x1080_60_1"     : 1920 x 1080 @  59.9 Hz  (from: EDID, CEA)
[   103.764] (II) NVIDIA(GPU-0): "1920x1080_50"       : 1920 x 1080 @  50.0 Hz  (from: EDID, CEA)
[   103.764] (II) NVIDIA(GPU-0): "1280x800"           : 1280 x  800 @  60.0 Hz  (from: EDID, Detailed)
[   103.764] (II) NVIDIA(GPU-0): "1280x800_60"        : 1280 x  800 @  60.0 Hz  (from: EDID, Detailed)
[   103.764] (II) NVIDIA(GPU-0): "1280x720"           : 1280 x  720 @  60.0 Hz  (from: EDID, CEA)
[   103.764] (II) NVIDIA(GPU-0): "1280x720_60"        : 1280 x  720 @  60.0 Hz  (from: EDID, CEA)
[   103.764] (II) NVIDIA(GPU-0): "1280x720_60_0"      : 1280 x  720 @  59.9 Hz  (from: EDID, CEA)
[   103.764] (II) NVIDIA(GPU-0): "1024x768"           : 1024 x  768 @  60.0 Hz  (from: EDID)
[   103.764] (II) NVIDIA(GPU-0): "1024x768_60"        : 1024 x  768 @  60.0 Hz  (from: EDID)
[   103.765] (II) NVIDIA(GPU-0): "800x600"            :  800 x  600 @  60.3 Hz  (from: EDID)
[   103.765] (II) NVIDIA(GPU-0): "800x600_60"         :  800 x  600 @  60.3 Hz  (from: EDID)
(from: EDID)
[   103.765] (II) NVIDIA(GPU-0): "800x500"            :  800 x  500 @  59.5 Hz  (from: EDID, Detailed)
[   103.765] (II) NVIDIA(GPU-0): "800x500_59"         :  800 x  500 @  59.5 Hz  (from: EDID, Detailed)
[   103.765] (II) NVIDIA(GPU-0): "720x576"            :  720 x  576 @  50.0 Hz  (from: EDID, CEA)
[   103.765] (II) NVIDIA(GPU-0): "720x576_50"         :  720 x  576 @  50.0 Hz  (from: EDID, CEA)
[   103.765] (II) NVIDIA(GPU-0): "720x480"            :  720 x  480 @  59.9 Hz  (from: EDID, CEA)
[   103.765] (II) NVIDIA(GPU-0): "720x480_60"         :  720 x  480 @  59.9 Hz  (from: EDID, CEA)
[   103.765] (II) NVIDIA(GPU-0): "720x400"            :  720 x  400 @  70.0 Hz  (from: EDID)
[   103.765] (II) NVIDIA(GPU-0): "720x400_70"         :  720 x  400 @  70.0 Hz  (from: EDID)
[   103.765] (II) NVIDIA(GPU-0): "640x480"            :  640 x  480 @  59.9 Hz  (from: EDID, CEA)
[   103.765] (II) NVIDIA(GPU-0): "640x480_60"         :  640 x  480 @  59.9 Hz  (from: EDID, CEA)
[   103.765] (II) NVIDIA(GPU-0): "640x480_60_0"       :  640 x  480 @  59.9 Hz  (from: EDID)
[   103.765] (II) NVIDIA(GPU-0): --- End of ModePool for ELO ET1093L (DFP-0): ---
[   103.765] (II) NVIDIA(GPU-0):
[   103.767] (--) NVIDIA(GPU-0): ELO ET1093L (DFP-0): connected
[   103.767] (--) NVIDIA(GPU-0): ELO ET1093L (DFP-0): External TMDS
[   103.767] (--) NVIDIA(GPU-0): ELO ET1093L (DFP-0) Name Aliases:
[   103.767] (--) NVIDIA(GPU-0):   DFP
[   103.767] (--) NVIDIA(GPU-0):   DFP-0
[   103.767] (--) NVIDIA(GPU-0):   DPY-0
[   103.767] (--) NVIDIA(GPU-0):   HDMI-0
[   103.767] (--) NVIDIA(GPU-0):   DPY-EDID-d5d6b26f-64f9-73e5-f6fd-87fe7f41ac25
[   103.767] (--) NVIDIA(GPU-0):   HDMI-0
[   103.775] (II) NVIDIA(0): Setting mode "NULL"
[   103.782] (--) NVIDIA(GPU-0): ELO ET1093L (DFP-0): connected
[   103.782] (--) NVIDIA(GPU-0): ELO ET1093L (DFP-0): External TMDS
[   103.782] (--) NVIDIA(GPU-0): ELO ET1093L (DFP-0) Name Aliases:
[   103.782] (--) NVIDIA(GPU-0):   DFP
[   103.782] (--) NVIDIA(GPU-0):   DFP-0
[   103.782] (--) NVIDIA(GPU-0):   DPY-0
[   103.782] (--) NVIDIA(GPU-0):   HDMI-0
[   103.782] (--) NVIDIA(GPU-0):   DPY-EDID-d5d6b26f-64f9-73e5-f6fd-87fe7f41ac25
[   103.782] (--) NVIDIA(GPU-0):   HDMI-0
+0+0 {AllowGSYNC=Off, ViewPortIn=1280x800, ViewPortOut=1280x800+0+0}"
[   103.962] (--) NVIDIA(GPU-0): ELO ET1093L (DFP-0): connected
[   103.962] (--) NVIDIA(GPU-0): ELO ET1093L (DFP-0): External TMDS
[   103.962] (--) NVIDIA(GPU-0): ELO ET1093L (DFP-0) Name Aliases:
[   103.962] (--) NVIDIA(GPU-0):   DFP
[   103.962] (--) NVIDIA(GPU-0):   DFP-0
[   103.962] (--) NVIDIA(GPU-0):   DPY-0
[   103.962] (--) NVIDIA(GPU-0):   HDMI-0
[   103.963] (--) NVIDIA(GPU-0):   DPY-EDID-d5d6b26f-64f9-73e5-f6fd-87fe7f41ac25
[   103.963] (--) NVIDIA(GPU-0):   HDMI-0
[   107.404] (--) NVIDIA(GPU-0): ELO ET1093L (DFP-0): connected

Xorg_Log.txt (228.0 KB)

linuxdev · December 24, 2020, 6:53pm

It is interesting that you have a lot of valid modes. EDID is obviously working, and the monitor itself is compatible. However, in the log I did not see any pick of horizontal or vertical scan rates being picked, and I am only guessing, but this seems to be why the monitor is not working…lack of using valid scan rates from valid modes in the mode pool.

HDMI is “hot plug”, so as an experiment, if you continue to monitor “tail -f /var/log/Xorg.0.log”, and then unplug and replug the monitor, what shows up as a result of the plug-in (you can ignore log text from unplug, only the replug will matter).

Also, try something similar while monitoring logs…boot with a known working monitor, unplug that monitor, and then plug in the non-working monitor.

I’m hoping that a hot plug from an up and running system will get past something which is failing when always connected.

If you have serial console or ssh login, and you can leave the monitor running (or attempting to run) in GUI mode, then you could use your ssh or serial console login for manual mode setting attempts. In that terminal you would run this command first:
export DISPLAY=:0

Then (with DISPLAY exported) you could use “xrandr” to display what modes should be possible. Post what you see. We can then try manual mode setting from the non-GUI terminal.

jalmen · December 28, 2020, 3:12pm

I have gone through a lot of the modes that come up, but they are all showing up with an error. Is the 768000000 rate the clock setting it is trying to use? This does not seems to change at the different refresh rates. Is there a way to manually adjust this down to test?

rustuser@rustuser-desktop:~$ xrandr
Screen 0: minimum 8 x 8, current 800 x 600, maximum 16384 x 16384
HDMI-0 connected primary 800x600+0+0 (normal left inverted right x axis y axis) 220mm x 140mm
   1280x800      60.00 +
   1920x1200     59.89
   1920x1080     60.00    59.95    50.00
   1280x720      60.00    59.94
   1024x768      60.01
   800x600       60.32*   56.25
   800x500       59.50
   720x576       50.00
   720x480       59.94
   720x400       70.04
   640x480       59.94    59.94
DP-0 disconnected (normal left inverted right x axis y axis)
  1280x720_50.00 (0x1cc) 60.500MHz -HSync +VSync
        h: width  1280 start 1328 end 1456 total 1632 skew    0 clock  37.07KHz
        v: height  720 start  723 end  728 total  744           clock  49.83Hz 4
[ 1961.236351] tegra-dvfs: rate 768000000 too high for dvfs on disp1--rate 59.94
[ 1961.236354] tegradc tegradc.0: hdmi: set dc parent failed
[ 1961.241055] tegradc tegradc.0: pclk out of range!
[ 1961.241059] tegradc tegradc.0: tegra_dc_init: tegra_dc_program_mode failed
[ 1961.241071] tegradc tegradc.0: _tegra_dc_controller_enable: tegra_dc_init failed
[ 1961.272567] tegra-dvfs: rate 768000000 too high for dvfs on disp1
[ 1961.272582] tegradc tegradc.0: hdmi: set dc parent failed
[ 1961.278928] tegradc tegradc.0: pclk out of range!
[ 1961.278931] tegradc tegradc.0: tegra_dc_init: tegra_dc_program_mode failed
[ 1961.278942] tegradc tegradc.0: _tegra_dc_controller_enable: tegra_dc_init failed
rustuser@rustuser-desktop:~$ xrandr
Screen 0: minimum 8 x 8, current 1280 x 720, maximum 16384 x 16384
HDMI-0 connected primary 1280x720+0+0 (normal left inverted right x axis y axis) 220mm x 140mm
   1280x800      60.00 +
   1920x1200     59.89
   1920x1080     60.00    59.95    50.00
   1280x720      60.00    59.94*
   1024x768      60.01
   800x600       60.32    56.25
   800x500       59.50
   720x576       50.00
   720x480       59.94
   720x400       70.04
   640x480       59.94    59.94
DP-0 disconnected (normal left inverted right x axis y axis)
  1280x720_50.00 (0x1cc) 60.500MHz -HSync +VSync
        h: width  1280 start 1328 end 1456 total 1632 skew    0 clock  37.07KHz
        v: height  720 start  723 end  728 total  744           clock  49.83Hz

linuxdev · December 28, 2020, 7:04pm

The DVFS table is the Digital Voltage and Frequency Scale, and sets minimums and maximums for certain clocks and regulators. If the pixel clock (pclk) is out of range of either the monitor or the driver/GPU, then the mode is refused.

I would be very surprised if the monitor is too fast for the GPU, but I would also surprised if frequencies are so slow the pixel clock rate is out of bounds.

Would someone from NVIDIA be able to suggest a way to research the reason why there are many accepted modes in the mode pool, and yet the pixel clock is out of range? It seems odd that the pixel clock would not be considered when listing accepted modes.

WayneWWW · January 6, 2021, 3:25am

Hi,

I think there is something wrong with this pclk… It is 768Mhz. Even a common RGB 4k@60 monitor requires only 594Mhz…
How is it possible a mode 1280x800@60 requires such pclk?

Could you dump

The edid.

sudo -s
root@tegra-ubuntu:/sys/kernel/debug/tegradc.0# cat edid

Please note that there might be tegradc.0/1/2. Just pick the one that has your HDMI edid.

The mode data

root@tegra-ubuntu:/sys/kernel/debug/tegradc.0# cat mode

We need to check the detail of this mode and see why it requires such large pclk.

WayneWWW · January 13, 2021, 3:03am

Hello,

Any feedback here?

jalmen · January 13, 2021, 9:20pm

The device I was testing on had to go into service with a different brand of monitor we were able to get working. The different monitors would pick up these modes with problems at first, but after a fresh image they worked fine. I have not got the time to setup a new device and hook up the faulty ELO monitor.

WayneWWW · January 14, 2021, 2:58am

Ok, please report the status when you are available.

Topic		Replies	Views
Jetson Nano in the visual interface click Settings restart Jetson Nano ubuntu	9	506	August 23, 2023
Jetson Nano B01, no graphical environment Jetson Nano reflash	82	3678	November 18, 2021
Read custom EDID Jetson TX2	12	3779	October 18, 2021
HDMI Display is not responding when Jetson Tx1 boot ups Jetson TX1	20	2975	October 18, 2021
Jetson nano recognize my monitor which stays black Jetson Nano boot	11	682	November 9, 2022
Try to get a 1024x600 screen (Eleduino Raspberry Pi 7 Inch 1024x600 Pixel IPS HDMI) working for Jets Jetson TK1	5	2360	July 31, 2016
Jetson Nano Fallback EDID Jetson Nano	23	4203	October 14, 2021
Reference to Xorg.conf and Resolution Settings Jetson TX2	26	14035	September 4, 2022
Jetson Nano blank screen during and after boot Jetson Nano boot , nvbugs	118	21789	October 15, 2021
How to get monitor detected as 1280x800? Jetson TX2	28	12781	October 18, 2021

ELO Monitor Incompatibility

Related topics