Hi,
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
Hi,
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"
EndSection
The output of:
lsmod
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?
[url]Computer Parts, PC Components, Laptop Computers, LED LCD TV, Digital Cameras and more - Newegg.com
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.