Black Screen after Flashing


I have installed the L4T 21.3 from the command line successfully without any error, I have tried the R21.5 too.

After the installation, I reboot the Jetson (as suggested in the command line) but I only obtain a black screen.

Do you know any solution to this?

What kind of video cabling is used (such as adapters or purely HDMI)? If you install package “read-edid” and “edid-decode”, what is the output from these:

sudo get-edid | parse-edid
sudo get-edid | edid-decode

Can you also post the contents of “/var/log/Xorg.0.log”?

What is the output of:

sudo cat /sys/kernel/debug/edid1

"What kind of video cabling is used (such as adapters or purely HDMI)? "

Initially, I was using one adapter, but I change to a direct HDMI with no results.

I cannot access the command line of Jetson since I don’t have any video. The installation of the OS happen without any error, but I cannot understand what is wrong now since I have already installed in the past with success.

It is likely just the default video mode not being compatible with the monitor, which would mean networking would still give ssh access, and of course the serial console works even when most everything else fails. So, can you ping the Jetson, and can you ssh in? That would be very useful. Alternatively, you could use the 9-pin D-sub connector with a serial console program (setting 115200 8N1).

To use the 9-pin D-sub connector, it’s only needed to connect to the Serial port?

I try two different adapters (USB to DB9 - RS232) it doesn’t work for me.

The adapters you have should work, but there are sometimes some tricks to seeing it actually succeed (depending on adapter design and USB chipset). If the chipset is FTDI it should probably “just work” without most of the “tricks”.

Sometimes the USB portion is powered by the device, and at other times by the host. It may be necessary to unplug and replug one end or the other after power is actually up. Order of powering up device and host may change things. “lsusb” should at least show the adapter on the host.

Once it is connected you need to use a serial console program, e.g., minicom, gtkterm (my favorite), or PuTTY. Finding the right serial device can be a pain, especially under Windows. Once you have this running, speed is 115200, 8 bits, no parity, 1 stop bit. Typically flow control with a full DB-9 connector is RTS/CTS, although software flow control would probably work as well.

If everything is set up on host, and Jetson does not show anything, keep the Jetson on, replug the DB-9, and then power cycle the Jetson while the DB-9 stays connected. If lsusb does not show the device on host, unplug and replug it on the host…after that you may still need to unplug and replug the DB-9 if host side had not been visible before.

I cannot obtain nothing from the serial port, any suggestion?

Sometimes order of powering/reconnecting the USB end can change things (as mentioned earlier, sometimes the USB side is powered by the Jetson, sometimes it is powered by the host…this can change the requirements of power up order). While the Jetson remains plugged in, first verify that on host you see the cable from lsusb. Make sure the Jetson is powered up. Then unplug and re-plug the USB side, verify lsusb again shows up.

As you plug it in there would be log output on the host regarding which device was created. Numbering and naming can depend on order of enumeration, so if it works once, it may change name and mysteriously fail another time. Try restarting any serial console program after you see the log message and making sure the specific device is being used. Also be sure to start the serial console program using sudo (unless you’ve gone through steps to set up permissions it may be only root can reach that device special file).

Even if settings are wrong in the serial console program you’d likely get at least garbage output. Do be sure though that you are using 115200 8N1. USB to DB-9 probably has flow control capability of CTS/DTS…I’d use that…but software flow control would likely work as well unless the adapter had an odd design.

If you have an oscilloscope you could look for any signs of signal between the balanced pair TX/RX pins just to verify activity or not.

Thanks for your help linuxdev.

Currently, I do not have any oscilloscope with me to see the RS232 communication. I tried with several adapters without success.

I tried to reinstall the Linux for Tegra R21.5 and the Linux for Tegra R21.3.4, and I still have no image. In every installation, the message of successful installation and reboot to start from Jetson appeared.

I tried with several HDMI cables and in two different monitors without success.

I do not know what can I do more.

Chances are that only video is failing, and other parts are working.

Does ssh work (or just ping)? Can you find an IP address via your router or other DHCP server? SSH works for finding information. Command line could be from ssh, not just local and not just serial console.

On your host, with Jetson powered up and DB-9 to USB cable connected, what does your host log show from a disconnect and reconnect of the USB connector? E.g., check “dmesg | tail -n 100” before and after the disconnect/reconnect sequence. It can be frustrating getting the mapping right between a serial UART via USB and the proper device special file for the serial port. My host is Fedora so udev may name USB serial UART files differently, but chances are with the USB cable unplugged your host will show some “/dev/ttyUSB*” and “/dev/ttyS*” files, and after plugging in the USB serial UART, one more will show up; does the host show a change in tty files after plugging in the USB cable, or does the log mention a tty file?

Incidentally, if you do identify a file in “/dev” which is the serial UART, “lsusb” will list the device and give an “ID” field. You can limit the query to just the one device by the ID, e.g.:

sudo lsusb -d 0955:7140

…you can then do the verbose version and post the information here or attach a verbose listing as a text file and it might be easier to know what the USB serial UART has in it, e.g.:

sudo lsusb -d 0955:7140 -vvv 2>&1 | tee lsusb_log.txt


I have the:

Bus 003 Device 027: ID 067b:2303 Prolific Technology, Inc. PL2303 Serial Port

And I read another device using it when I connect it to the Jetson TK1 nothing appears.

I have installed the Linux OS using the Jetpack with success (without installing the rest via Ethernet), and nothing appears again.

I am without ideas of how I can solve this.

What is the host’s output of:

sudo lsusb -d 067b:2303 -vvv

I ask because I’m wanting to see what chipset is behind the serial UART. USB sees the device, but this does not indicate if a driver was ever installed (it reminds me of the saying “the lights are on, but nobody is home”…USB turns on the lights, but without a driver, nobody is home). Also, what is the host’s output from “lsmod”?

If trying to deal with video issues there isn’t much you can do without some form of console or network or serial port access.

One thing which would be of interest is to see what the EDID data shows when that same monitor and cable are used on another Linux system. Is there any chance you can see if that monitor works on any other computer? If so, perhaps the output of “xrandr” would be of use.

The output of:

sudo lsusb -d 067b:2303 -vvv

Is given by:

Bus 003 Device 003: ID 067b:2303 Prolific Technology, Inc. PL2303 Serial Port
Device Descriptor:
  bLength                18
  bDescriptorType         1
  bcdUSB               1.10
  bDeviceClass            0 (Defined at Interface level)
  bDeviceSubClass         0 
  bDeviceProtocol         0 
  bMaxPacketSize0        64
  idVendor           0x067b Prolific Technology, Inc.
  idProduct          0x2303 PL2303 Serial Port
  bcdDevice            3.00
  iManufacturer           1 Prolific Technology Inc.
  iProduct                2 USB-Serial Controller
  iSerial                 0 
  bNumConfigurations      1
  Configuration Descriptor:
    bLength                 9
    bDescriptorType         2
    wTotalLength           39
    bNumInterfaces          1
    bConfigurationValue     1
    iConfiguration          0 
    bmAttributes         0xa0
      (Bus Powered)
      Remote Wakeup
    MaxPower              100mA
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        0
      bAlternateSetting       0
      bNumEndpoints           3
      bInterfaceClass       255 Vendor Specific Class
      bInterfaceSubClass      0 
      bInterfaceProtocol      0 
      iInterface              0 
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x81  EP 1 IN
        bmAttributes            3
          Transfer Type            Interrupt
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x000a  1x 10 bytes
        bInterval               1
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x02  EP 2 OUT
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0040  1x 64 bytes
        bInterval               0
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x83  EP 3 IN
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0040  1x 64 bytes
        bInterval               0
Device Status:     0x0000
  (Bus Powered)

EDID read on other UBUNTU system:

Section "Monitor"
	Identifier "S27C750"
	ModelName "S27C750"
	VendorName "SAM"
	# Monitor Manufactured week 21 of 2013
	# EDID version 1.3
	# Digital Display
	DisplaySize 600 340
	Gamma 2.20
	Option "DPMS" "true"
	Horizsync 30-81
	VertRefresh 50-75
	# Maximum pixel clock is 170MHz
	#Not giving standard mode: 1152x864, 75Hz
	#Not giving standard mode: 1280x720, 60Hz
	#Not giving standard mode: 1280x800, 60Hz
	#Not giving standard mode: 1280x1024, 60Hz
	#Not giving standard mode: 1440x900, 60Hz
	#Not giving standard mode: 1600x900, 60Hz
	#Not giving standard mode: 1680x1050, 60Hz

	#Extension block found. Parsing...
	Modeline 	"Mode 8" 74.25 1280 1720 1760 1980 720 725 730 750 +hsync +vsync 
	Modeline 	"Mode 0" 148.50 1920 2008 2052 2200 1080 1084 1089 1125 +hsync +vsync 
	Modeline 	"Mode 1" 74.25 1280 1390 1430 1650 720 725 730 750 +hsync +vsync 
	Modeline 	"Mode 2" 148.500 1920 2008 2052 2200 1080 1084 1089 1125 +hsync +vsync
	Modeline 	"Mode 3" 74.250 1280 1390 1420 1650 720 725 730 750 +hsync +vsync
	Modeline 	"Mode 4" 148.500 1920 2448 2492 2640 1080 1084 1089 1125 +hsync +vsync
	Modeline 	"Mode 5" 74.250 1280 1720 1760 1980 720 725 730 750 +hsync +vsync
	Modeline 	"Mode 6" 27.027 720 736 798 858 480 489 495 525 -hsync -vsync
	Modeline 	"Mode 7" 27.000 720 732 796 864 576 581 586 625 -hsync -vsync
	Modeline 	"Mode 9" 27.00 720 732 796 864 576 581 586 625 -hsync -vsync 
	Modeline 	"Mode 10" 27.00 720 736 798 858 480 489 495 525 -hsync -vsync 
	Option "PreferredMode" "Mode 8"

The output of:


Is given by:

Module                  Size  Used by
cmac                   16384  2 
drbg                   28672  1 
ansi_cprng             16384  0 
ctr                    16384  1 
ccm                    20480  1 
hid_logitech_hidpp     20480  0 
uvcvideo               90112  0 
videobuf2_vmalloc      16384  1 uvcvideo
videobuf2_memops       16384  1 videobuf2_vmalloc
rtsx_usb_ms            20480  0 
videobuf2_v4l2         28672  1 uvcvideo
hid_logitech_dj        20480  0 
videobuf2_core         36864  2 uvcvideo,videobuf2_v4l2
pl2303                 20480  0 
v4l2_common            16384  1 videobuf2_v4l2
rtsx_usb_sdmmc         28672  0 
memstick               20480  1 rtsx_usb_ms
usbserial              53248  1 pl2303
videodev              180224  4 uvcvideo,v4l2_common,videobuf2_core,videobuf2_v4l2
usbhid                 49152  0 
hid                   118784  3 usbhid,hid_logitech_dj,hid_logitech_hidpp
rtsx_usb               24576  2 rtsx_usb_sdmmc,rtsx_usb_ms
ath3k                  20480  0 
media                  24576  2 uvcvideo,videodev
btusb                  45056  0 
btrtl                  16384  1 btusb
btbcm                  16384  1 btusb
btintel                16384  1 btusb
joydev                 20480  0 
snd_hda_codec_realtek    86016  1 
snd_hda_codec_hdmi     53248  1 
snd_hda_codec_generic    73728  1 snd_hda_codec_realtek
intel_rapl             20480  0 
x86_pkg_temp_thermal    16384  0 
intel_powerclamp       16384  0 
asus_nb_wmi            24576  0 
coretemp               16384  0 
asus_wmi               28672  1 asus_nb_wmi
rfcomm                 69632  8 
bnep                   20480  2 
sparse_keymap          16384  1 asus_wmi
mxm_wmi                16384  0 
kvm_intel             167936  0 
bluetooth             516096  26 bnep,ath3k,btbcm,btrtl,btusb,rfcomm,btintel
kvm                   536576  1 kvm_intel
irqbypass              16384  1 kvm
crct10dif_pclmul       16384  0 
crc32_pclmul           16384  0 
arc4                   16384  2 
ath9k                 143360  0 
aesni_intel           167936  4 
aes_x86_64             20480  1 aesni_intel
lrw                    16384  1 aesni_intel
gf128mul               16384  1 lrw
glue_helper            16384  1 aesni_intel
ath9k_common           36864  1 ath9k
ablk_helper            16384  1 aesni_intel
ath9k_hw              466944  2 ath9k_common,ath9k
cryptd                 20480  2 aesni_intel,ablk_helper
snd_hda_intel          36864  5 
snd_hda_codec         135168  4 snd_hda_codec_realtek,snd_hda_codec_hdmi,snd_hda_codec_generic,snd_hda_intel
ath                    32768  3 ath9k_common,ath9k,ath9k_hw
snd_hda_core           73728  5 snd_hda_codec_realtek,snd_hda_codec_hdmi,snd_hda_codec_generic,snd_hda_codec,snd_hda_intel
snd_hwdep              16384  1 snd_hda_codec
input_leds             16384  0 
i915                 1208320  5 
mac80211              733184  1 ath9k
serio_raw              16384  0 
snd_pcm               106496  4 snd_hda_codec_hdmi,snd_hda_codec,snd_hda_intel,snd_hda_core
snd_seq_midi           16384  0 
cfg80211              557056  4 ath,ath9k_common,ath9k,mac80211
snd_seq_midi_event     16384  1 snd_seq_midi
snd_rawmidi            32768  1 snd_seq_midi
snd_seq                69632  2 snd_seq_midi_event,snd_seq_midi
drm_kms_helper        151552  1 i915
snd_seq_device         16384  3 snd_seq,snd_rawmidi,snd_seq_midi
drm                   360448  6 i915,drm_kms_helper
snd_timer              32768  2 snd_pcm,snd_seq
binfmt_misc            20480  1 
wmi                    20480  2 mxm_wmi,asus_wmi
i2c_algo_bit           16384  1 i915
fb_sys_fops            16384  1 drm_kms_helper
syscopyarea            16384  1 drm_kms_helper
sysfillrect            16384  1 drm_kms_helper
sysimgblt              16384  1 drm_kms_helper
snd                    81920  21 snd_hda_codec_realtek,snd_hwdep,snd_timer,snd_hda_codec_hdmi,snd_pcm,snd_seq,snd_rawmidi,snd_hda_codec_generic,snd_hda_codec,snd_hda_intel,snd_seq_device
parport_pc             36864  0 
soundcore              16384  1 snd
mei_me                 36864  0 
ppdev                  20480  0 
shpchp                 36864  0 
ie31200_edac           16384  0 
mei                    98304  1 mei_me
edac_core              53248  1 ie31200_edac
lpc_ich                24576  0 
video                  40960  2 i915,asus_wmi
lp                     20480  0 
mac_hid                16384  0 
parport                49152  3 lp,ppdev,parport_pc
psmouse               122880  0 
ahci                   36864  2 
r8169                  81920  0 
libahci                32768  1 ahci
mii                    16384  1 r8169
fjes                   28672  0

The above gives useful information, but more questions follow. Some questions may differ depending on your host’s distribution, e.g., I’m using Fedora, many people here use Ubuntu. Some of this may be more than you are interested in, but serial ports are important enough it may be worth pointing this stuff out. The whole topic of whether flash worked because of video issues makes it worth iterating more about monitors as well.

Serial Console “Stuff”

Looks like the host requires CONFIG_USB_SERIAL_PL2303 in kernel config to use your particular model of serial UART. Since you used the serial UART to read another device you can infer that this driver must be in place and functioning correctly. It’s up to hotplug layers and udev to make it all work together (most of what follows is because of this). Because the driver is a module on your system verified that the particular non-FTDI driver is correctly loaded from the lsmod line:

usbserial              53248  1 pl2303

On the host, what appends to dmesg output when the USB serial UART is plugged in? This could give information about USB port and driver handling. E.g., check “dmesg | tail -n 10” while the serial UART is not plugged in; check “dmesg | tail -n 20” after the USB device is plugged in. Paste the new addition to dmesg here. Even though your USB device works on something else the identifying tty can change so I’m hoping dmesg can help add confidence that the correct tty device is being used at this particular time (changing any device plugin or rebooting can change the ttyUSB).

On the host, does any file get added to “ls /dev/tty*” if you compare the tty list before and after plugging in this serial UART? A device which appears after plugging in the serial UART would be guaranteed as the correct device…but as mentioned above the device can change each time USB has any other change so this file should be used right after plugging in the cable (without adding or removing anything on USB). If no file appears, then it is possible the device special file is static and not added by the module, but this is uncommon. A dynamically appearing device special file is a “smoking gun” evidence that this is the right file at this moment in time.

When you open minicom or gtkterm or any serial terminal program for using the serial UART do you use “sudo” (if not then likely only members of group dialout could access the device…use sudo to be certain)? I personally prefer gtkterm. Note that udev can assign permissions differently from one device to the next which means similar operations which succeeded before may fail if some udev conditional rule kicks in. sudo should always get around that.

A really simple test to substitute for an oscilloscope is to run “sudo strings /dev/ttyUSBwhateverNameItIs”, and then turn on the power to the Jetson (test this on something known to work). Even if the serial port settings are wrong you should at least see some sort of garbage random output. If the serial port settings are correct you will get a literal read-only serial console text feed showing you what is happening play-by-play. If you get such output from another device, and then unplug the DB-9 connector only (don’t touch the USB plugin at the host side), and reconnect to the Jetson, then you have a live stream of bytes and if nothing shows up probably the Jetson itself has a problem…if something does show up, then it is just a matter of getting console access in the Jetson. There will of course only be text if something on the Jetson is actively sending characters to the console (e.g., boot messages…this is why you’d run strings on the port while boot is going on…after boot is complete you won’t get anything). The important point here is that a serial console program can simply be blank if settings are wrong…raw output via strings will work even if serial port settings are wrong…it’s a good indicator.

About the Monitor

The fact that another computer reads the EDID proves the cable and monitor make this data available to the Jetson. This does not guarantee modes are compatible, but it eliminates a lot of outright failures and means automatic configuration is possible. Even if automatic configuration did not work there would still be a possibility that the default mode of the Jetson could be used on this monitor.

That said, the monitor in question does not support newer widescreen formats. I have a similar older monitor which is physically widescreen, but does not make available modern formats like 1080p (any monitor with 1080p probably “just works”). Many of the modes in these older monitors are not available without great effort. During boot monitors such as these may not have output from initial boot…mine does not and I get a brief note from the monitor that scan mode is too fast. Later in the boot when it reaches graphical stage a compatible mode is reached (GUI stage default mode differs from console default mode…compatibility can be missing in both or working in just one…GUI and console modes should be treated as separate issues). At the moment you add power to the Jetson, and for about 60 seconds after, does your monitor give any kind of note that perhaps there was a signal for at least a moment? Perhaps it is like my monitor and complains for about only a second or so that the mode is incompatible and then it shuts off all display of anything but blank. The carrier signal light stays off because it couldn’t lock on to that scan rate. That indication is easily missed because it is so very short. Should there be even a brief moment of complaint about scanning too fast you will know the issue is one of video mode setup…that “scan too fast” complaint could occur at either the moment the text mode is started or at the moment the GUI is started.

The Jetson TK1 was working with this monitor and cables before I flash it.

I’m almost giving up of putting my Jetson working. I have tried with different operating systems to read the serial port without success.

Default video modes will change with different L4T versions. It is very likely this is why it worked in a previous version.

So far as serial port goes I wish you could try a different USB serial UART, one based on an FTDI chip. Is there any possibility you could get this or a similar FTDI-based USB serial UART?

Like this one?

That should work. I don’t know though if it is bus powered or not, so order of power up might matter (you’d have to try it to find out). The FTDI chipset though is as reliable as you can get though, I suspect it will work.