Jetson TX1 won't start after flashing with JetPack 3.2 but works with JetPack 3.1

A01337885 · May 6, 2020, 5:36pm

Hello. I’m trying to flash a TX1 development card with a JetPack 3.2 installer. The problem is that, after “successfully” finishing the flashing, the TX1 starts correctly, but the second time we tried to turn it on, the monitor only displays the “NVidia” logo, then several lines of code and then nothing, black screen.

After several tries, we reinstalled JetPack 3.1 and it worked! Then, we tried, once again, to reinstall the JetPack 3.2, and the same situation occurred. First time, Ubuntu started, second time it didn’t.

Does anybody have had the same situation or any thoughts on how to fix it?

We also tried to keep the JetPack 3.1 configuration and then install CUDA 9.0, but while we were doing it so the terminal requested us the IP address. At that moment we connected the TX1 to the computer where we were doing the installation, via Ethernet connection. I’m not sure how to obtain the IP address requested, and we already tried with the IP direction of the computer but, again, it doesn’t work.

PLEASE, could anyone help me?

(We are working with a 16.04 Ubuntu version)
(The same process has been tried out with four different laptops with Ubuntu 16.04 operative system)

linuxdev · February 1, 2020, 6:36am

Are you sure it didn’t start? There is an extreme difference between video not configuring and having no video versus failure to boot. You can wait a minute and try ping and ssh. By far the best tool is a serial console:
http://www.jetsonhacks.com/2015/12/01/serial-console-nvidia-jetson-tx1/
http://elinux.org/Jetson/TX1_Serial_Console

A01337885 · May 6, 2020, 5:36pm

Thanks for answering me, linuxdev. The problem is that we are almost sure that the system boots correctly; the starting dialogs are displayed on screen as well as the NVidia logo, but after that the screen goes black. I’ll try to run the serial console as you said in order to verify if the system boots correctly, however, I’m not sure how the “ping and ssh” thing works or what you are trying to say with this.

I appreciate your help and sorry for the trouble. I’m super new in all this NVidia environment.

linuxdev · May 6, 2020, 5:36pm

Video on HDMI has a wire (the DDC wire) which the video card can use to ask the monitor what its capabilities are (the data is the EDID data). Video will fail (but everything else will work) if either the HDMI fails to correctly respond, or if the monitor responds with specifications out of the range of what it is designed for. So it is quite common that video will start and then fail later in boot (especially if you use a VGA adapter…this absolutely guarantees auto configuration cannot work and luck is the only way it will ever work).

Serial console is by far the best way to access a system since a large part of the system can crash and burn, and yet the console would still provide normal access to see what is going on. Sometimes you use the hot keys CTRL-ALT-F2 to get to a text mode console…if that works you can use that.

If networking is up, then the Jetson will use DHCP and ask your router for a network address. The logs of your router will tell you what the address is that was assigned (your PC can act as a router). Just as an example, if your router assigned address “192.168.1.4”, then you could see if the network is alive by pinging it from your host PC (“ping 192.168.1.4”).

If ping works, then you can use ssh for logging in. If the example address is used, then you can “ssh 192.168.1.4” and look at logs and enter commands.

Basically you need some method to get into the system to see what is going on.

A01337885 · February 1, 2020, 6:37am

Hello Linuxdev and thank you again for the reply:
I’ve already tried the serial console option you told me. The first time the TX1 had the JetPack version 3.1 and it worked, as it was supposed to be; the system didn’t even asked us for a password. Then, we flashed the card with the newest version of JetPack (3.2.1) and we were hopeful that the system would initiate normally alongside with the video; however, this didn’t worked (as well as with the previous version 3.2) and we launched the serial console to determine what was wrong.

Anyway, we know how what to do to initiate the serial console using minicom terminal emulator but, when we initiate the TX1 again, we don’t know what to look for on the dialog window that is displayed.

linuxdev · May 6, 2020, 5:36pm

Minicom complicates things. This tool came to exist in the days of dialup telephone modems, and those modems were basically serial pipes with certain sequences being detected as commands for modem setup.

The Jetson is not a modem, and has no such modem init commands needed. In fact, since serial console can interrupt boot while in the U-Boot stage, any activity on the serial console will halt boot. So you either need to wait till you are past U-Boot before running your console (you can even pull the plug if you are using a USB cable), or otherwise guarantee the serial console on the host side is only sending text you type in at a terminal. If your serial console is putting out activity while the Jetson boots, then it may be your flash succeeded and it is just halting due to serial console activity interrupting it.

I actually prefer gtkterm, but to name any serial device other than the older “ttyS0” naming convention requires editing the “~/.gtktermrc” file. What I do is save an entry which has all the desired settings, close gtkterm, and then edit the port. On my system I have a lot of serial adapters, but I know the one going to the TX2 is “/dev/serial/by-id/usb-FTDI_TTL232R-3V3_FTFONKOI-if00-port0”. So my “~/.gtktermrc” is:

[TX2]
<b>port    = /dev</b><i>/serial/by-id/usb-FTDI_TTL232R-3V3_FTFONKOI-if00-port0</i>
speed   = 115200
bits    = 8
stopbits        = 1
parity  = none
flow    = none
wait_delay      = 0
wait_char       = -1
rs485_rts_time_before_tx        = 30
rs485_rts_time_after_tx = 30
echo    = False
crlfauto        = False
font    = "Monospace 14"
term_transparency       = False
term_show_cursor        = True
term_rows       = 80
term_columns    = 25
term_scrollback = 2000
term_visual_bell        = True
term_foreground_red     = 43253
term_foreground_blue    = 43253
term_foreground_green   = 43253
term_background_red     = 0
term_background_blue    = 0
term_background_green   = 0
term_background_saturation      = 0.500000

(adjust for your host’s serial port name, select “TX2” in “load configuration”)

You can do similar tricks with most serial console applications. Just pay attention to these settings and do not use any terminal initialization:

Speed 115200
8 bits, no parity, 1 stop bit
No hardware flow control (the TX1 could use CTS/RTS hardware flow control, the TX2 cannot...no flow control works for either TX1 or TX2)

“picoterm” has some similar use:

picocom -b 115200 --databits 8 --parity n --stop 1 --flow n /dev/serial/by-id/usb-FTDI_TTL232R-3V3_FTFONKOI-if00-port0

kayccc · February 1, 2020, 6:38am

Hi A01337885,

Are you able to have your TX1 work with JetPack3.2 or 3.2.1 successfully?
Any result can be shared?

Thanks