Black consoles on L4T 64 bits R24 rev 2.1

Hi,

I’ve installed a TX1 board from JetPack 2.3.1 without problem, but now I face one problem : the consoles (ctl-alt-F1 to F6) are not working properly…Well, I can login and do some commands, but in blind mode as the screen remains all black.

I really need to work without the GUI to save some memory for my cuda application, but I’d like to see the application output.

Does anyone face the same issue ?
Or has an advice about how to solve this ?

Many thanks,
HP

It sounds like the console is using scan rate settings the monitor does not support. What is the exact cabling used with the monitor, including any adapters? Also, what is the output from this:

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

Also, you may want to install packages “read-edid” and “edid-decode”, and then from the GUI, post the output of these:

sudo -s
get-edid | parse-edid
get-edid | edid-decode
exit
xrandr

Thanks for your help. Indeed, it looks like this is related to my monitor.
It is an old model (LG FLATRON W2246), connected through a HDMI to DVI cable.

Here are the outputs of the commands:

> sudo cat /sys/kernel/debug/tegradc.1/edid
 00 ff ff ff ff ff ff 00 1e 6d 84 57 0f 95 04 00
 05 15 01 03 ea 30 1b 78 ea 33 33 a5 55 4d 9d 25
 11 50 52 a5 4b 00 b3 00 81 80 81 8f 71 4f 01 01
 01 01 01 01 01 01 02 3a 80 18 71 38 2d 40 58 2c
 45 00 dd 0c 11 00 00 1a 21 39 90 30 62 1a 27 40
 68 b0 36 00 dd 0c 11 00 00 1c 00 00 00 fd 00 38
 4b 1e 53 0f 00 0a 20 20 20 20 20 20 00 00 00 fc
 00 57 32 32 34 36 0a 20 20 20 20 20 20 20 00 a8

> sudo -s
> get-edid | parse-edid 
This is read-edid version 3.0.2. Prepare for some fun.
Attempting to use i2c interface
No EDID on bus 0
No EDID on bus 1
No EDID on bus 3
No EDID on bus 4
No EDID on bus 5
No EDID on bus 6
1 potential busses found: 2
Bus 2 doesn't really have an EDID...
Couldn't find an accessible EDID on this computer.
I'm sorry nothing was successful. Maybe try some other arguments
if you played with them, or send an email to Matthew Kern <pyrophobicman@gmail.com>.
Partial Read... Try again

> get-edid | edid-decode 
This is read-edid version 3.0.2. Prepare for some fun.
Attempting to use i2c interface
No EDID on bus 0
No EDID on bus 1
No EDID on bus 3
No EDID on bus 4
No EDID on bus 5
No EDID on bus 6
1 potential busses found: 2
Bus 2 doesn't really have an EDID...
Couldn't find an accessible EDID on this computer.
I'm sorry nothing was successful. Maybe try some other arguments
if you played with them, or send an email to Matthew Kern <pyrophobicman@gmail.com>.
Extracted contents:
header:          00 00 00 00 00 00 00 00
serial number:   00 00 00 00 00 00 00 00 00 00
version:         00 00
basic params:    00 00 00 00 00
chroma info:     00 00 00 00 00 00 00 00 00 00
established:     00 00 00
standard:        00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
descriptor 1:    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
descriptor 2:    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
descriptor 3:    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
descriptor 4:    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
extensions:      00
checksum:        00

No header found
Manufacturer: @@@ Model 0 Serial Number 0
EDID version: 0.0
Analog display, Input voltage level: 0.7/0.3 V
Sync: 
Image size is variable
Gamma: 1.00
Monochrome or grayscale display
Established timings supported:
Standard timings supported:
non-conformant standard timing (0 horiz)
non-conformant standard timing (0 horiz)
non-conformant standard timing (0 horiz)
non-conformant standard timing (0 horiz)
non-conformant standard timing (0 horiz)
non-conformant standard timing (0 horiz)
non-conformant standard timing (0 horiz)
non-conformant standard timing (0 horiz)
Manufacturer-specified data, tag 0
Manufacturer-specified data, tag 0
Manufacturer-specified data, tag 0
Manufacturer-specified data, tag 0
Checksum: 0x0 (valid)
EDID block does not conform at all!
	Bad year of manufacture
	Manufacturer name field contains garbage

> exit

> xrandr
Screen 0: minimum 8 x 8, current 1920 x 1080, maximum 16384 x 16384
HDMI-0 connected primary 1920x1080+0+0 (normal left inverted right x axis y axis) 480mm x 270mm
   1920x1080     60.00*+
   1680x1050     59.96  
   1280x1024     75.03    60.00  
   1152x864      75.00  
   1024x768      75.03    60.01  
   800x600       75.00    60.32  
   720x400       70.04  
   640x480       75.00    59.94

Obviously, the quickest fix would be changing the monitor for a more recent model, but this is expensive for my poor graphical needs, so if I can force the scan rate to one supported by my monitor it would be nice.
Thanks again,
HP

Most HDMI-to-DVI should work (there may be some adapters which fail to pass through EDID data, but your case shows EDID does indeed exist, so that can be ruled out).

If you paste the EDID file data here, you can see that the data is valid (it doesn’t mean it is supported, but it does prove hardware read is correct and follows the data format at some standard):
http://www.edidreader.com/

Looking at its timing bitmap of the URL you’ll see it supports many older/typical resolutions, but none of the hidef type standards (e.g., no 1920x1080).

When you get to the software in the Jetson which uses this data it appears there are some issues. Checksum is valid, but then it goes on to state this:

EDID block does not conform at all!
Bad year of manufacture
Manufacturer name field contains garbage

It’s useful to know that there are many monitors which have “quirks” in EDID, and even the kernel source is somewhat humorous when you start to read the number of monitors which have customizations for a particular quirk. Regardless of why this is the case, it appears the EDID data is not being used for setting console modes. If it happened that the default console mode when not using EDID happened to match what your monitor supports, then it would work anyway. Default modes do change depending on release versions.

In the “get-edid | parse-edid” you’ll see this note:

Couldn't find an accessible EDID on this computer.
I'm sorry nothing was successful. Maybe try some other arguments
if you played with them, or send an email to Matthew Kern <pyrophobicman@gmail.com>.

You will probably want to send the same information to that email address and see if he might be able to help (in the past he’s been very responsive).

So far as manually forcing a different console video mode goes, I’m not sure of how to do this on a Jetson. For the desktop PC drivers it is possible to append a VGA mode to the kernel command line. Desktop systems even allow “vga=ask” to get an interactive prompt which lists available modes and asks which one to use (on my desktop I use “vga=0x318” which I found through “vga=ask”). This functionality does not seem to exist on Jetsons, but I would be very curious if someone at nVidia might be able to comment on methods to manually set console mode on a Jetson.

Possible solutions are: (1) If the email address above can get a quirk workaround; (2) find a way to manually set console video mode; (3) find a monitor which supports default modes; or (4) find a monitor which the EDID code works with. Answer “2” would be quite useful since a number of people run into this issue; I personally use an older monitor with this situation as well.

I have sent an email to Matthew and hope to get a workaround.

This monitor works fine in console mode with my TK1 R19.
The EDID seems better handled here (see details below) with read-edid 3.0.1 instead of 3.0.2.
I’m sure it was also working with my TX1 in previous JetPacks versions.

> cat /sys/kernel/debug/edid1
edid[000] = 00 ff ff ff ff ff ff 00 1e 6d 84 57 0f 95 04 00
edid[010] = 05 15 01 03 ea 30 1b 78 ea 33 33 a5 55 4d 9d 25
edid[020] = 11 50 52 a5 4b 00 b3 00 81 80 81 8f 71 4f 01 01
edid[030] = 01 01 01 01 01 01 02 3a 80 18 71 38 2d 40 58 2c
edid[040] = 45 00 dd 0c 11 00 00 1a 21 39 90 30 62 1a 27 40
edid[050] = 68 b0 36 00 dd 0c 11 00 00 1c 00 00 00 fd 00 38
edid[060] = 4b 1e 53 0f 00 0a 20 20 20 20 20 20 00 00 00 fc
edid[070] = 00 57 32 32 34 36 0a 20 20 20 20 20 20 20 00 a8

> get-edid | edid-decode 
This is read-edid version 3.0.1. Prepare for some fun.
Attempting to use i2c interface
No EDID on bus 0
No EDID on bus 1
No EDID on bus 2
No EDID on bus 4
No EDID on bus 5
1 potential busses found: 3
128-byte EDID successfully retrieved from i2c bus 3
Looks like i2c was successful. Have a good day.
Extracted contents:
header:          00 ff ff ff ff ff ff 00
serial number:   1e 6d 84 57 0f 95 04 00 05 15
version:         01 03
basic params:    ea 30 1b 78 ea
chroma info:     33 33 a5 55 4d 9d 25 11 50 52
established:     a5 4b 00
standard:        b3 00 81 80 81 8f 71 4f 01 01 01 01 01 01 01 01
descriptor 1:    02 3a 80 18 71 38 2d 40 58 2c 45 00 dd 0c 11 00 00 1a
descriptor 2:    21 39 90 30 62 1a 27 40 68 b0 36 00 dd 0c 11 00 00 1c
descriptor 3:    00 00 00 fd 00 38 4b 1e 53 0f 00 0a 20 20 20 20 20 20
descriptor 4:    00 00 00 fc 00 57 32 32 34 36 0a 20 20 20 20 20 20 20
extensions:      00
checksum:        a8

Manufacturer: GSM Model 5784 Serial Number 300303
Made week 5 of 2011
EDID version: 1.3
Digital display
Maximum image size: 48 cm x 27 cm
Gamma: 2.20
DPMS levels: Standby Suspend Off
Supported color formats: RGB 4:4:4, YCrCb 4:2:2
First detailed timing is preferred timing
Established timings supported:
  720x400@70Hz
  640x480@60Hz
  640x480@75Hz
  800x600@60Hz
  800x600@75Hz
  1024x768@60Hz
  1024x768@75Hz
  1280x1024@75Hz
Standard timings supported:
  1680x1050@60Hz
  1280x1024@60Hz
  1280x1024@75Hz
  1152x864@75Hz
Detailed mode: Clock 148.500 MHz, 477 mm x 268 mm
               1920 2008 2052 2200 hborder 0
               1080 1084 1089 1125 vborder 0
               +hsync -vsync
Detailed mode: Clock 146.250 MHz, 477 mm x 268 mm
               1680 1784 1960 2240 hborder 0
               1050 1053 1059 1089 vborder 0
               -hsync +vsync
Monitor ranges: 56-75HZ vertical, 30-83kHz horizontal, max dotclock 150MHz
Monitor name: W2246
       Checksum: 0xa8
EDID block does NOT conform to EDID 1.3!
	Digital display field contains garbage: 6a

> get-edid | parse-edid 
This is read-edid version 3.0.1. Prepare for some fun.
Attempting to use i2c interface
No EDID on bus 0
No EDID on bus 1
No EDID on bus 2
No EDID on bus 4
No EDID on bus 5
1 potential busses found: 3
128-byte EDID successfully retrieved from i2c bus 3
Looks like i2c was successful. Have a good day.
Checksum Correct

Section "Monitor"
	Identifier "W2246"
	ModelName "W2246"
	VendorName "GSM"
	# Monitor Manufactured week 5 of 2011
	# EDID version 1.3
	# Digital Display
	DisplaySize 480 270
	Gamma 2.20
	Option "DPMS" "true"
	Horizsync 30-83
	VertRefresh 56-75
	# Maximum pixel clock is 150MHz
	#Not giving standard mode: 1680x1050, 60Hz
	#Not giving standard mode: 1280x1024, 60Hz
	#Not giving standard mode: 1280x1024, 75Hz
	#Not giving standard mode: 1152x864, 75Hz
	Modeline 	"Mode 0" 148.50 1920 2008 2052 2200 1080 1084 1089 1125 +hsync -vsync 
	Modeline 	"Mode 1" 146.25 1680 1784 1960 2240 1050 1053 1059 1089 -hsync +vsync 
EndSection

> xrandr
Screen 0: minimum 8 x 8, current 1920 x 1080, maximum 16384 x 16384
HDMI-0 connected primary 1920x1080+0+0 (normal left inverted right x axis y axis) 0mm x 0mm
   1920x1080      60.0*+
   1680x1050      60.0     60.0  
   1280x1024      75.0     60.0  
   1152x864       75.0  
   1024x768       60.0  
   800x600        75.0     60.3  
   720x400        70.0  
   640x480        75.0     60.0

Thanks for your help,
HP

Well, no success with option1 (Matthew has not answered yet).

I have tried to look at option 2, but not obvious to try without reflashing.
Possible ways (please tell if it is useless) from simplest to the most complicated :

  • Adding nomodeset to kernel command line. This has been used on PCs with grub. I don’t know if this is only for PC or if this can work here. I guess I would have to modify the bootloader config, but so far I don’t know precisely how to do this.

  • According to :
    https://wiki.archlinux.org/index.php/kernel_mode_setting
    Provide the binary edid file in folder /usr/lib/firmware/edid/edid.bin, update initramfs and add to kernel command line the option:

drm_kms_helper.edid_firmware=edid/edid.bin

Not sure it will work in my case, as I may have to make a fixed edid file, just able to give the resolution I want for console and the one for GUI. However, I had no knowledge of EDID nor KMS before this issue and I cannot invest days for that, albeit I like to solve problems.

  • Rebuild a new kernel.The kms part embeds four default modes, so it should be possible to hardcode these for my hardware. Not sure however how it selects amomg these four…

So I was thinking to go for buying a brand new HDMI monitor (option 4 or at least 3), but…

Trying to understand difference with my old TK1 that works, I have modified get-edid 3.0.2 from source to see why it was failing on TX1 with 3.0.2, just printing the received header.
It seems to me that the received edid from i2c by get-edid is wrong. It is constantly (reproductible) wrong header (01 00 0D 00 84 08 E8 03), while on my TK1, (L4T R19) it is constantly ok.
On TX1, edid read from /sys/kernel/debug/tegradc.1/edid is ok.

I have been trying a few other displays without improvement.
First I took a Lenovo All in One PC having a vga input…not better, but VGA was probably not the best trial.
So I went to a big Samsung Flat TV having an HDMI input and it was another cable. Then, I have been able to see Linux booting. But, after GUI had started, virtual consoles were black again.
Tonight, I’m using another monitor from ASUS, quite old as well, not better.

When looking at errors in dmesg, I’ve noticed some about i2c, but not sure they are “normal”. After booting I tried some get-edid :

dmesg |grep i2c
[    0.834692] i2c i2c-3: of_i2c: modalias failure on /i2c@7000c700/prod-settings
[    4.389921] i2c /dev entries driver
[    7.263700] tegra-i2c 7000c000.i2c: no acknowledge from address 0x1b
[    8.672282] vi vi: parsing node /host1x/i2c@546c0000/ov5693_c@36
[    8.681031] vi vi: handling endpoint /host1x/i2c@546c0000/ov5693_c@36/ports/port@0/endpoint
[    8.716093] vi vi: processing endpoint /host1x/i2c@546c0000/ov5693_c@36/ports/port@0/endpoint
[    8.727523] vi vi: skipping channel port /host1x/i2c@546c0000/ov5693_c@36:0
[ 5695.977629] tegra-i2c 7000c000.i2c: no acknowledge from address 0x50
[ 5695.977934] tegra-i2c 7000c400.i2c: no acknowledge from address 0x50
[ 5696.974570] tegra-i2c 7000c700.i2c: --- register dump for debugging ----
[ 5696.981510] tegra-i2c 7000c700.i2c: I2C_CNFG - 0x22c00
[ 5696.987520] tegra-i2c 7000c700.i2c: I2C_PACKET_TRANSFER_STATUS - 0x10001
[ 5696.996123] tegra-i2c 7000c700.i2c: I2C_FIFO_CONTROL - 0xe0
[ 5697.003300] tegra-i2c 7000c700.i2c: I2C_FIFO_STATUS - 0x800040
[ 5697.009824] tegra-i2c 7000c700.i2c: I2C_INT_MASK - 0xed
[ 5697.015170] tegra-i2c 7000c700.i2c: I2C_INT_STATUS - 0x0
[ 5697.020531] tegra-i2c 7000c700.i2c: msg->len - 1
[ 5697.026344] tegra-i2c 7000c700.i2c: is_msg_write - 1
[ 5697.031307] tegra-i2c 7000c700.i2c: next_msg->len - 1
[ 5697.037071] tegra-i2c 7000c700.i2c: is_next_msg_write - 0
[ 5697.042467] tegra-i2c 7000c700.i2c: buf_remaining - 1
[ 5697.048170] tegra-i2c 7000c700.i2c: i2c transfer timed out, addr 0x0050, data 0x00
[ 5697.056206] tegra-i2c 7000d000.i2c: no acknowledge from address 0x50
[ 5698.054727] tegra-i2c 7000d100.i2c: --- register dump for debugging ----
[ 5698.061497] tegra-i2c 7000d100.i2c: I2C_CNFG - 0x22c00
[ 5698.070831] tegra-i2c 7000d100.i2c: I2C_PACKET_TRANSFER_STATUS - 0x10001
[ 5698.079510] tegra-i2c 7000d100.i2c: I2C_FIFO_CONTROL - 0xe0
[ 5698.085436] tegra-i2c 7000d100.i2c: I2C_FIFO_STATUS - 0x800040
[ 5698.091265] tegra-i2c 7000d100.i2c: I2C_INT_MASK - 0xed
[ 5698.097107] tegra-i2c 7000d100.i2c: I2C_INT_STATUS - 0x0
[ 5698.102415] tegra-i2c 7000d100.i2c: msg->len - 1
[ 5698.107625] tegra-i2c 7000d100.i2c: is_msg_write - 1
[ 5698.112584] tegra-i2c 7000d100.i2c: next_msg->len - 1
[ 5698.118270] tegra-i2c 7000d100.i2c: is_next_msg_write - 0
[ 5698.123663] tegra-i2c 7000d100.i2c: buf_remaining - 1
[ 5698.129146] tegra-i2c 7000d100.i2c: i2c transfer timed out, addr 0x0050, data 0x00
[ 5698.137601] tegra-vii2c 546c0000.i2c: no acknowledge from address 0x50
[ 5698.137784] tegra-vii2c 546c0000.i2c: no acknowledge from address 0x50
[ 5698.137930] tegra-vii2c 546c0000.i2c: no acknowledge from address 0x50
[ 5698.138073] tegra-vii2c 546c0000.i2c: no acknowledge from address 0x50
[ 5878.258582] tegra-i2c 7000c000.i2c: no acknowledge from address 0x50
[ 5878.258947] tegra-i2c 7000c400.i2c: no acknowledge from address 0x50
[ 5879.257022] tegra-i2c 7000c700.i2c: --- register dump for debugging ----
[ 5879.263833] tegra-i2c 7000c700.i2c: I2C_CNFG - 0x22c00
[ 5879.269445] tegra-i2c 7000c700.i2c: I2C_PACKET_TRANSFER_STATUS - 0x10001
[ 5879.276351] tegra-i2c 7000c700.i2c: I2C_FIFO_CONTROL - 0xe0
[ 5879.282269] tegra-i2c 7000c700.i2c: I2C_FIFO_STATUS - 0x800040
[ 5879.288322] tegra-i2c 7000c700.i2c: I2C_INT_MASK - 0xed
[ 5879.295002] tegra-i2c 7000c700.i2c: I2C_INT_STATUS - 0x0
[ 5879.300375] tegra-i2c 7000c700.i2c: msg->len - 1
[ 5879.305021] tegra-i2c 7000c700.i2c: is_msg_write - 1
[ 5879.310005] tegra-i2c 7000c700.i2c: next_msg->len - 1
[ 5879.315159] tegra-i2c 7000c700.i2c: is_next_msg_write - 0
[ 5879.320596] tegra-i2c 7000c700.i2c: buf_remaining - 1
[ 5879.325680] tegra-i2c 7000c700.i2c: i2c transfer timed out, addr 0x0050, data 0x00
[ 5879.333727] tegra-i2c 7000d000.i2c: no acknowledge from address 0x50
[ 5880.327124] tegra-i2c 7000d100.i2c: --- register dump for debugging ----
[ 5880.333979] tegra-i2c 7000d100.i2c: I2C_CNFG - 0x22c00
[ 5880.341139] tegra-i2c 7000d100.i2c: I2C_PACKET_TRANSFER_STATUS - 0x10001
[ 5880.348588] tegra-i2c 7000d100.i2c: I2C_FIFO_CONTROL - 0xe0
[ 5880.354264] tegra-i2c 7000d100.i2c: I2C_FIFO_STATUS - 0x800040
[ 5880.360554] tegra-i2c 7000d100.i2c: I2C_INT_MASK - 0xed
[ 5880.365819] tegra-i2c 7000d100.i2c: I2C_INT_STATUS - 0x0
[ 5880.371588] tegra-i2c 7000d100.i2c: msg->len - 1
[ 5880.376245] tegra-i2c 7000d100.i2c: is_msg_write - 1
[ 5880.381606] tegra-i2c 7000d100.i2c: next_msg->len - 1
[ 5880.386711] tegra-i2c 7000d100.i2c: is_next_msg_write - 0
[ 5880.392102] tegra-i2c 7000d100.i2c: buf_remaining - 1
[ 5880.397250] tegra-i2c 7000d100.i2c: i2c transfer timed out, addr 0x0050, data 0x00
[ 5880.405794] tegra-vii2c 546c0000.i2c: no acknowledge from address 0x50
[ 5880.405957] tegra-vii2c 546c0000.i2c: no acknowledge from address 0x50
[ 5880.406113] tegra-vii2c 546c0000.i2c: no acknowledge from address 0x50
[ 5880.406266] tegra-vii2c 546c0000.i2c: no acknowledge from address 0x50

I’ve also noticed some errors with regulator_get() failing with error -19.

dmesg | grep regulator_get
[    0.788592] regulator_get() failed for (1-0074,vcc), -19
[    0.811043] regulator_get() failed for (1-0077,vcc), -19
[    3.768210] regulator_get() failed for (tegra-udc.0,usb_bat_chg), -19
[    3.820895] regulator_get() failed for (tegra-ehci.0,usb_vbus), -19
[    3.820897] usb_phy: failed regulator_get vdd_vbus_usb:-19, inst:0
[    5.995035] regulator_get() failed for (sdhci-tegra.3,vqmmc), -19
[    6.003988] regulator_get() failed for (sdhci-tegra.3,vmmc), -19
[    6.126141] regulator_get() failed for (sdhci-tegra.1,vqmmc), -19
[    6.144056] regulator_get() failed for (sdhci-tegra.1,vmmc), -19
[    6.256585] regulator_get() failed for (sdhci-tegra.0,vqmmc), -19
[    6.256594] regulator_get() failed for (sdhci-tegra.0,vmmc), -19

Is there a hardware issue with my TX1 or power supply ?
I have removed the USB keyboard hubbing a mouse, so no more USB device, and even removed the HDMI cable, but errors are still hapenning (devices were plugged after GUI had started).

Below are the dmesg output in both cases (Ethernet cable was still connected to a miniswitch).

dmesg.UsbAndHdmiPlugged.txt (69.6 KB)
dmesg.NoUsbNoHdmi.txt (69.1 KB)

If you look at one of your earlier listings it had this:

non-conformant standard timing (0 horiz)

It sounded like one of the later listings was for the JTK1 instead of JTX1…which you said worked better. Using the same monitor on the JTK1 and JTX1, does that line “non-conformant standard timing (0 horiz)” go away on the JTK1? If so, then this line might be a starting point for debugging (it would be a case of finding out why this triggered with the same EDID on the TX1’s software, but not with the TK1’s software).

Hi Linuxdev,

Thanks for your hopeful reply. I also hope I’ll have some time tomorrow for trying this on my TK1 on send the exact output there.

Please let me know furthermore, if no information can be found at boot :

display board info: id 0x0, fab 0x00

why using modern default rates ?
Modern monitors are able to send information, aren’t they ?
Having old standards should be a ‘most cases’ working starting point, albeit painful, but only for boot.
After X has started, wouldn’t it be possible and if yes how complicated would it be to create a command that would switch the virtual consoles (or some of them) to the mode used by X ?

Thanks for your help,
HP

I am unsure of your question…perhaps rewording would help. However, the whole topic revolves around two basic ideas: 1) Query the monitor to see what it can do; and 2) set up video drivers to deal with that monitor. If either a query cannot be performed, or if the monitor does not have settings matching the graphics card’s capabilities, then some default must be reverted to. If a default gets lucky and is supported by the monitor, then it works.

The “modern monitor” does send information, this is the EDID data I was mentioning before (it occurs over an i2c protocol, but the information must be formatted specifically to DDC/EDID/E-EDID). In your case device query works, but it looks like parsing fails (that is the “non-conformant standard timing” issue). The question is why this fails. Comparison with the JTK1 might help answer this. Either way your monitor is seeing a default scan rate setting which it does not support (if you manually forced the display setting at the driver to be something the monitor works with, then the monitor would work).

In the cases of failure to parse there seems to be two possible issues. The first, and most common, is that many monitors in some way are not exactly conforming to the required data structure. The kernel code itself has many monitor “quirks” noted and hard wired for specific monitor models (the manufacturer was sloppy). If there is a quirk in the EDID data itself, then probably a patch is required to deal with this (this is a case for the email…it might result in a quirk patch). Possibly earlier kernel code worked with a quirk if it parsed differently on the TK1 versus the TX1, but failure to parse does not provide information yet on why the failure occurred.

The other possibility is that the data does not have any “quirk”, and that parsing itself is at issue. Comparing what triggers the TX1 to fail with the same EDID the TK1 works with is a very good piece of debugging evidence. It gives a specific case of data failure which might be traced to a specific location in source code and compared to the same location in the working TK1 code.
So it may be important to find out if “non-conformant standard timing (0 horiz)” happens on the JTK1 or not…look carefully at those same query commands when performed on a working JTK1…see if the JTK1 thinks EDID conforms and can be parsed.

On the topic of defaults, I don’t know how a Jetson chooses defaults when EDID fails. Since 640x480 is mostly guaranteed on any monitor I’d guess this would be a good default. My suspicion is that the default goes to something a more modern wide screen monitor would support.

Have you tried this kernel patch? It does resolve a similar issue for me.

https://devtalk.nvidia.com/default/topic/946129/jetson-tx1/switching-to-tty1-6-/post/4914207/#4914207

It seems to me that there are 2 different things… edid read by kernel (looks ok in sysfs for TK1 and TX1) and edid read by get-edid (ok for TK1, wrong on TX1).
However, here are the outputs from my TK1 with the same monitor :

sudo get-edid | parse-edid 
This is read-edid version 3.0.2. Prepare for some fun.
Attempting to use i2c interface
No EDID on bus 0
No EDID on bus 1
No EDID on bus 2
No EDID on bus 4
No EDID on bus 5
1 potential busses found: 3
128-byte EDID successfully retrieved from i2c bus 3
Looks like i2c was successful. Have a good day.
Checksum Correct

Section "Monitor"
	Identifier "W2246"
	ModelName "W2246"
	VendorName "GSM"
	# Monitor Manufactured week 5 of 2011
	# EDID version 1.3
	# Digital Display
	DisplaySize 480 270
	Gamma 2.20
	Option "DPMS" "true"
	Horizsync 30-83
	VertRefresh 56-75
	# Maximum pixel clock is 150MHz
	#Not giving standard mode: 1680x1050, 60Hz
	#Not giving standard mode: 1280x1024, 60Hz
	#Not giving standard mode: 1280x1024, 75Hz
	#Not giving standard mode: 1152x864, 75Hz
	Modeline 	"Mode 0" 148.50 1920 2008 2052 2200 1080 1084 1089 1125 +hsync -vsync 
	Modeline 	"Mode 1" 146.25 1680 1784 1960 2240 1050 1053 1059 1089 -hsync +vsync 
EndSection
sudo get-edid | edid-decode 
This is read-edid version 3.0.2. Prepare for some fun.
Attempting to use i2c interface
No EDID on bus 0
No EDID on bus 1
No EDID on bus 2
No EDID on bus 4
No EDID on bus 5
1 potential busses found: 3
128-byte EDID successfully retrieved from i2c bus 3
Looks like i2c was successful. Have a good day.
Extracted contents:
header:          00 ff ff ff ff ff ff 00
serial number:   1e 6d 84 57 0f 95 04 00 05 15
version:         01 03
basic params:    ea 30 1b 78 ea
chroma info:     33 33 a5 55 4d 9d 25 11 50 52
established:     a5 4b 00
standard:        b3 00 81 80 81 8f 71 4f 01 01 01 01 01 01 01 01
descriptor 1:    02 3a 80 18 71 38 2d 40 58 2c 45 00 dd 0c 11 00 00 1a
descriptor 2:    21 39 90 30 62 1a 27 40 68 b0 36 00 dd 0c 11 00 00 1c
descriptor 3:    00 00 00 fd 00 38 4b 1e 53 0f 00 0a 20 20 20 20 20 20
descriptor 4:    00 00 00 fc 00 57 32 32 34 36 0a 20 20 20 20 20 20 20
extensions:      00
checksum:        a8

Manufacturer: GSM Model 5784 Serial Number 300303
Made week 5 of 2011
EDID version: 1.3
Digital display
Maximum image size: 48 cm x 27 cm
Gamma: 2.20
DPMS levels: Standby Suspend Off
Supported color formats: RGB 4:4:4, YCrCb 4:2:2
First detailed timing is preferred timing
Established timings supported:
  720x400@70Hz
  640x480@60Hz
  640x480@75Hz
  800x600@60Hz
  800x600@75Hz
  1024x768@60Hz
  1024x768@75Hz
  1280x1024@75Hz
Standard timings supported:
  1680x1050@60Hz
  1280x1024@60Hz
  1280x1024@75Hz
  1152x864@75Hz
Detailed mode: Clock 148.500 MHz, 477 mm x 268 mm
               1920 2008 2052 2200 hborder 0
               1080 1084 1089 1125 vborder 0
               +hsync -vsync
Detailed mode: Clock 146.250 MHz, 477 mm x 268 mm
               1680 1784 1960 2240 hborder 0
               1050 1053 1059 1089 vborder 0
               -hsync +vsync
Monitor ranges: 56-75HZ vertical, 30-83kHz horizontal, max dotclock 150MHz
Monitor name: W2246
       Checksum: 0xa8
EDID block does NOT conform to EDID 1.3!
	Digital display field contains garbage: 6a

Attached is dmesg output of the TK1 with same peripherals (Monitor and USB) just after boot.

dmesg.sameMonitorAndUsb.TK1.txt (62.9 KB)

Thanks jkjung13 for sharing this. This thread describes the same problems. I’ll try this.

Furthermore, I’ve noticed :

[    2.744142]  (null): coherent DMA mask is unset
[    2.748755] gk20a gpu.0: failed to allocate secure buffer -12
[    2.758590] tegradc tegradc.1: vrr_setup failed

Are these messages normal ?

Thanks for your help.
HP

I believe the coherent DMA mask is from serial port ttyTHS3 and would be unrelated. I do not know if the other messages are related or not, but my feeling is that those messages are unlikely to matter. If any i2c error mattered, then the “/sys” edid file would have failed. This seems to be purely a parsing error of EDID.

This does seem to verify though that the exact same EDID data works on a TK1, but fails on a TX1. Acquisition of that EDID is correct in both cases, what fails is parsing of the EDID. The clue is to find out why this occurs with that exact valid EDID data is this error message:

Standard timings supported:
non-conformant standard timing (0 horiz)

For reference to those wanting to debug this, here is the EDID data which produced the error on a JTX1, but worked correctly on a JTK1:

00 ff ff ff ff ff ff 00 1e 6d 84 57 0f 95 04 00
05 15 01 03 ea 30 1b 78 ea 33 33 a5 55 4d 9d 25
11 50 52 a5 4b 00 b3 00 81 80 81 8f 71 4f 01 01
01 01 01 01 01 01 02 3a 80 18 71 38 2d 40 58 2c
45 00 dd 0c 11 00 00 1a 21 39 90 30 62 1a 27 40
68 b0 36 00 dd 0c 11 00 00 1c 00 00 00 fd 00 38
4b 1e 53 0f 00 0a 20 20 20 20 20 20 00 00 00 fc
00 57 32 32 34 36 0a 20 20 20 20 20 20 20 00 a8

The validity of the data standard timings can be verified by pasting the EDID into this web URL:
http://www.edidreader.com/

Hi Linuxdev,

Thanks for your prompt reply.

My feeling is :

Kernel succeeds in getting the right EDID, but fails to set mode accordingly.
When launching cat in sysfs, does kernel really performs an I2C query or does it just send the edid it has received in early boot and stored in memory ?

After some time, maybe a driver issue, the I2C communication is broken on the TX1. I’ve read this is known and have happened in the 64 bits porting.
I’m quite sure (I have some images but no time to reflash) that TX1 32 bits versions were working correctly.
Then, parsing the wrong EDID with get-edid is useless.

I’m also thinking about my trial with the Samsung HDMI TV. How can we explain to see booting, but no more console after X has started ? I expect these multiple symptoms have a single cause. If required, I can make this test again and send the dmesg output.

I would appreciate if someone from Nvidia’s L4T developers could help on this topic.

Thanks,
HP

Monitors seem to be hotplug, and u-boot has no video driver…I would guess that if edid changes, then so does that “/sys” edid file. Regardless, valid EDID data is there…only parsing and implementation based on parsing remains.

It is possible i2c fails in future reads, but while the “/sys” edid is there, this should be irrelevant. Consider also that the EDID queries showed some data, but other parts failed…this would imply i2c failure in the middle of the query which would leave partial correct data and partial corrupt data. I do not believe that is the case, but until the actual point of failure is known this can’t be claimed as a fact.

There have been several cases where going from 32-bit user space to 64-bit user space has been an issue, but in the kernel it has always been 64-bit. This is consistent with the “/sys” edid file being correct, but does not say whether transfer of data to user space is at fault, or if user space software is at fault…but once more, having at least partial correct data tends to lean towards parsing as a failure. I can’t prove it, but it seems data in is correct and data out is not. I would be surprised if it is a 32-bit/64-bit issue since some monitors work correctly (a 32-bit/64-bit issue in parsing probably would break all monitors, not just this EDID case). My gut feeling is that this has something to do with the particular data case.

The hotplug features made me thinking to see what happens when unplugging/replugging the monitor.
On TK1, no problem.
On TX1, after replugging I got VGA resolution for X, but still black consoles.

On TK1, unplugging gives :

[   54.125002] tegra_dc_hdmi_irq: start
[   54.125062] tegra_dc_hdmi_irq: end
[   54.125159] hdmi_state_machine_worker (tid eb234040): state 4 (Enabled), hpd 0, pending_hpd_evt 1
[   54.125177] hdmi_state_machine_set_state_l: switching from state 4 (Enabled) to state 5 (Wait for HPD reassert)
[   55.627791] hdmi_state_machine_worker (tid eb234040): state 5 (Wait for HPD reassert), hpd 0, pending_hpd_evt 0
[   55.628007] hdmi_state_machine_set_state_l: switching from state 5 (Wait for HPD reassert) to state 0 (Reset)
[   55.628471] hdmi_state_machine_worker (tid eb234040): state 0 (Reset), hpd 0, pending_hpd_evt 0
[   55.629485] hdmi_disable_l: audio_switch 0
[   55.629981] hdmi_disable_l: hpd_switch 0
[   55.630085] HDMI from connected to disconnected
[   55.646394] hdmi_state_machine_set_state_l: switching from state 0 (Reset) to state 1 (Check Plug)
[   55.656339] hdmi_state_machine_worker (tid eb234040): state 1 (Check Plug), hpd 0, pending_hpd_evt 0
[   55.656365] hdmi_disable_l: audio_switch 0
[   55.656371] hdmi_disable_l: hpd_switch 0
[   55.656380] hdmi_state_machine_set_state_l: switching from state 1 (Check Plug) to state 3 (Disabled)

and replugging gives:

[   64.366491] tegra_dc_hdmi_irq: start
[   64.366829] tegra_dc_hdmi_irq: end
[   64.367210] hdmi_state_machine_worker (tid eb234040): state 3 (Disabled), hpd 1, pending_hpd_evt 1
[   64.367695] hdmi_state_machine_set_state_l: switching from state 3 (Disabled) to state 0 (Reset)
[   64.408299] hdmi_state_machine_worker (tid eb234040): state 0 (Reset), hpd 1, pending_hpd_evt 0
[   64.408708] hdmi_disable_l: audio_switch 0
[   64.408829] hdmi_disable_l: hpd_switch 0
[   64.408965] hdmi_state_machine_set_state_l: switching from state 0 (Reset) to state 1 (Check Plug)
[   64.419101] hdmi_state_machine_worker (tid eb234040): state 1 (Check Plug), hpd 1, pending_hpd_evt 0
[   64.419546] hdmi_state_machine_set_state_l: switching from state 1 (Check Plug) to state 2 (Check EDID)
[   64.480155] hdmi_state_machine_worker (tid eb234040): state 2 (Check EDID), hpd 1, pending_hpd_evt 0
[   64.495660] panel size 48 by 27
[   64.556416] handle_check_edid_l: audio_switch 0
[   64.557379] Display connected, hpd_switch 1
[   64.557397] hdmi_state_machine_set_state_l: switching from state 2 (Check EDID) to state 4 (Enabled)
[   64.557518] hdmi_state_machine_worker (tid ee0a7a80): state 4 (Enabled), hpd 1, pending_hpd_evt 0
[   64.558550] tegradc tegradc.1: nominal-pclk:148500000 parent:594000000 div:4.0 pclk:148500000 147015000~161865000
[   64.558681] tegra_dc_hdmi_enable: HDMI clock already configured to target frequency, skipping clk setup.

On TX1, unplugging gives :

[  123.106449] tegradc tegradc.1: hdmi: unplugged
[  123.141347] tegradc tegradc.1: blank - powerdown
[  123.141719] tegradc tegradc.1: unblank
[  123.141801] tegradc tegradc.1: unblank

and replugging gives :

[  131.097908] tegradc tegradc.1: vrr_setup failed
[  131.099465] tegradc tegradc.1: hdmi: plugged
[  131.142840] tegradc tegradc.1: blank - powerdown
[  131.143249] tegradc tegradc.1: unblank
[  131.191829] tegradc tegradc.1: nominal-pclk:148500000 parent:148500000 div:1.0 pclk:148500000 147015000~161865000
[  131.559465] tegradc tegradc.1: unblank
[  131.628939] tegradc tegradc.1: blank - powerdown
[  131.717136] tegradc tegradc.1: blank - powerdown
[  131.717224] tegradc tegradc.1: unblank
[  131.763551] tegradc tegradc.1: nominal-pclk:25200000 parent:25200000 div:1.0 pclk:25200000 24948000~27468000
[  132.115073] tegradc tegradc.1: unblank

vrr_setup error is there, and no hdmi_state_machine and no EDID parsing trace.

On TX1, it seems the correct clock was found first, but a second step gives a different clock.

A little progress…I’ve found a workaround but with limitations :

If I boot the TX1 without HDMI cable, after Linux has booted I type Alt-Ctl-F1 to switch to first console, then plug the HDMI cable, the console works fine !
dmesg gives only the 6 first lines similar to

131.097908] tegradc tegradc.1: vrr_setup failed
[  131.099465] tegradc tegradc.1: hdmi: plugged
[  131.142840] tegradc tegradc.1: blank - powerdown
[  131.143249] tegradc tegradc.1: unblank
[  131.191829] tegradc tegradc.1: nominal-pclk:148500000 parent:148500000 div:1.0 pclk:148500000 147015000~161865000
[  131.559465] tegradc tegradc.1: unblank

But this is not so simple. After typing Alt-Ctl-F7, I get the GUI working but not so good. Many icons in my Desktop are stacked in the same position (because of previous VGA mode low resolution Desktop). Switching again to tty1, the console is black again. Switching back to X, I got black screen, only mouse pointer is visible.

Ok, this workaround seems to be working :

  1. Unplug the HDMI cable
  2. Switch to your console (ex: Alt-Ctl-F1)
  3. Replug the HDMI cable
    (4. Optional: for multiple inputs monitor, select TX1 input again)

Switching to GUI works in most cases, but switching back to console leads to black screen again.
When I switch back to X with Alt-Ctl-F7, I can also notice pclk out of range error.

[ 1523.158569] tegradc tegradc.1: nominal-pclk:25174000 parent:148500000 div:1.0 pclk:148500000 24922260~27439660
[ 1523.158580] tegradc tegradc.1: pclk out of range!
[ 1523.193798] tegradc tegradc.1: blank - powerdown
[ 1524.188608] tegradc tegradc.1: unblank
[ 1524.241259] tegradc tegradc.1: nominal-pclk:148500000 parent:148500000 div:1.0 pclk:148500000 147015000~161865000
[ 1524.592184] tegradc tegradc.1: unblank
[ 1524.634218] tegradc tegradc.1: blank - powerdown
[ 1524.659258] tegradc tegradc.1: unblank
[ 1524.705174] tegradc tegradc.1: nominal-pclk:148500000 parent:148500000 div:1.0 pclk:148500000 147015000~161865000
[ 1525.072807] tegradc tegradc.1: unblank
[ 1525.131338] tegradc tegradc.1: blank - powerdown
[ 1525.159212] tegradc tegradc.1: unblank
[ 1525.210161] tegradc tegradc.1: nominal-pclk:148500000 parent:148500000 div:1.0 pclk:148500000 147015000~161865000
[ 1525.578855] tegradc tegradc.1: unblank
[ 1525.617231] tegradc tegradc.1: blank - powerdown
[ 1525.646097] tegradc tegradc.1: unblank
[ 1525.693440] tegradc tegradc.1: nominal-pclk:148500000 parent:148500000 div:1.0 pclk:148500000 147015000~161865000
[ 1526.061353] tegradc tegradc.1: unblank
[ 1526.119880] tegradc tegradc.1: blank - powerdown
[ 1526.146307] tegradc tegradc.1: unblank
[ 1526.193924] tegradc tegradc.1: nominal-pclk:148500000 parent:148500000 div:1.0 pclk:148500000 147015000~161865000
[ 1526.561676] tegradc tegradc.1: unblank

In the case of the previous error in parsing EDID I could see the possibility of that error propagating to become an incorrect pclk:

non-conformant standard timing (0 horiz)

I could also see the possibility that some part of the current video state remains each time a hotplug event updates some data, but not other parts of data (think of some successful EDID parsing, then failure for other parts); completely unplugging a monitor prior to the time at which a monitor detect event occurs could possibly revert all of the data back to a correct default value (the “non-conformant standard timing” errors might revert to a sane value due to assuming defaults). There are previous cases where hot plugging a monitor which works allows the non-working monitor to then be plugged in and work at the same resolution at which the working monitor had succeeded…this is also consistent with some or all parts of video setting state being updated to a sane value and then the failing monitor assuming the pre-existing state when EDID fails.

There is no message from kernel indicating that EDID parsing failed or succeeded.

The message :

non-conformant standard timing (0 horiz)

is just the output of edid-decode receiving nothing.
As its I2C communication gives wrong data, get-edid receives a bad header and aborts.
edid-decode receiving no EDID, it displays this message. It is similar to the output of :

sleep 1 | edid-decode

.

I have verified that after unplugging and with no HDMI cable connected, the EDID remains in sysfs node. So it is probably stored in memory by the driver, until a new EDID is read.

Thus, if a working monitor has successfully sent an EDID that turns into a video mode supported by another monitor that fails to send EDID (a HDMI to VGA would probably do this), this video mode may be used again, and I would bet it would still display the same EDID from sysfs node.

The question is how we can know if kernel parsing of the EDID failed ? No message about this in dmesg (TK1 kernel had such messages).
I will probably try to build a new kernel with traces of EDID parsing to see if it fails or succeeds, and try the patch mentioned by jkjung13.

There are some other nodes in sysfs tegradc. If someone knows if these can be used to investigate further, please let us know.

When used with TK1 where get-edid receives the good EDID, edid-decode mentions :

EDID block does NOT conform to EDID 1.3!
	Digital display field contains garbage: 6a

Would TX1 kernel be more confused than TK1’s one because of this ? Is it a quirk ? Or does driver need a quirk for this ?