Jetson TX1 will not boot

I upgrade from 14.04 to 16.04, which I now regret. After I upgraded, Ubuntu would completely freeze while I was in the GUI. I could still access the terminal though. I tried installing JetPack on my TX1 by setting it into recovery mode, but now it will not even boot. I see the solid two green lights, along with two red lights, but I don’t get any HDMI output. One of the red LED’s is next to: “ALERT PCIE/SATA POWERED UP” I have nothing I need on the TX1, so I want to completely reinstall Ubuntu 14.04 or at least get it to boot. If you need any other information, please ask.
I’ve tried installing Jetpack again, using serial through VM Virtualbox and through a TTL-232R-3V3 serial to usb cable.

A VM is a very common source of problems. Sometimes they work, sometimes not…sometimes someone who knows the VM can make adjustments to USB and get it to work. If it is a host issue, then the version of L4T won’t matter. I’d suggest just using a command line flash and logging it.

If you have the driver package installed (the Linux_for_Tegra directory…which is one of the pieces of what JetPack adds indirectly), and if the rootfs directory is already set up (having had the sample rootfs unpacked as root and apply_binaries.sh run as root…which JetPack also does), then a typical flash is:

sudo ./flash.sh -S 14580MiB jetson-tx1 mmcblk0p1

A modification to log this:

sudo ./flash.sh -S 14580MiB jetson-tx1 mmcblk0p1 2>&1 | tee flash_log.txt

How do I execute those commands?

Go to the command line in the directory with the flash.sh file. Just type them. Make sure the Jetson is already connected via the correct micro-B USB cable, and is in recovery mode. flash.sh should be in the Linux_for_Tegra subdirectory added by the JetPack install. You can verify that the further subdirectory “rootfs” seems to have a full Linux directory in it as well.

Where is the directory of Linxc_for_Tegra?

If you installed JetPack it’ll be part of that. If you want to you can just install it directly via the driver package. At minimum you need the driver package and sample rootfs. Look here:
https://developer.nvidia.com/embedded/linux-tegra

Download driver package, unpack it, e.g.:

tar xjfv Tegra210_Linux_R24.2.1_aarch64.tbz2

Then that will have produced “Linux_for_Tegra” directory. cd there, it will in turn have directory “rootfs”. You’ll use sudo to unpack the sample rootfs there, then complete the sample rootfs via apply_binaries.sh, and start the flash (the Jetson must be in recovery mode with the micro-B USB cable attached)…so the above step expands as:

tar xjfv Tegra210_Linux_R24.2.1_aarch64.tbz2
cd Linux_for_Tegra
cd rootfs
sudo tar xjfv /where/ever/you/downloaded/Tegra_Linux_Sample-Root-Filesystem_R24.2.1_aarch64.tbz2
cd ..
sudo ./apply_binaries.sh
sudo ./flash.sh -S 14580MiB jetson-tx1 mmcblk0p1 2>&1 | tee flash_log.txt

This last command not only flashes, it creates a log file of flash called “flash_log.txt”. You can refer to that file for debugging purposes. One word of warning…if flash succeeds there will be a line within the file which is quite long…it’s produced from the progress bar (on the screen it backs up and overwrites the old percent complete with the new percent complete…but in the file it just gets longer instead of backing up). This log can be attached in the forum to one of your existing posts…if you hover the mouse over the quote icon in the upper right of one of your replies, then a paper clip icon also shows up which is used for file attachments. Depending on the forum setup you may have to rename the flash_log.txt to something like flash_log.rtf.

I do this in the terminal in VM Virtualbox with the USB connected to the jetson in recovery mode?

Yes, but be warned that a VM is not reliable. You may get failures because of the VM…you won’t know until you try. Using a VM as host may be the reason of any initial failure.

I know it’s been a few months, but would I install my desired version of Linux, 14.04, or what is on the Jetson, 16.04, for the VM.

If you use JetPack, then you’d install Ubuntu 14.04 on the VM (JetPack runs only on the host and requires this specific version…there may be some success possible with 16.04 but it may be an issue). If you just flash, then mostly any x86_64 distribution will work. If you want to install without JetPack (which simplifies requirements), then the above post is still descriptive:
https://devtalk.nvidia.com/default/topic/986957/jetson-tx1/jetson-tx1-will-not-boot/post/5052979/#5052979

Hey, sorry, it’s me again. After I flashed it, the jetson “booted”.

*** Flashing target device started. ***
Welcome to Tegra Flash
version 1.0.0
Type ? or help for help and q or quit to exit
Use ! to execute system commands
 
[   0.0000 ] Generating RCM messages
[   0.0168 ] tegrarcm --listrcm rcm_list.xml --chip 0x21 --download rcm nvtboot_recovery.bin 0 0
[   0.0183 ] RCM 0 is saved as rcm_0.rcm
[   0.0251 ] RCM 1 is saved as rcm_1.rcm
[   0.0251 ] List of rcm files are saved in rcm_list.xml
[   0.0251 ] 
[   0.0251 ] Signing RCM messages
[   0.0383 ] tegrasign --key None --list rcm_list.xml --pubkeyhash pub_key.key
[   0.0418 ] Assuming zero filled SBK key
[   0.0501 ] 
[   0.0502 ] Copying signature to RCM mesages
[   0.0516 ] tegrarcm --chip 0x21 --updatesig rcm_list_signed.xml
[   0.0649 ] 
[   0.0649 ] Parsing partition layout
[   0.0683 ] tegraparser --pt flash.xml.tmp
[   0.0844 ] 
[   0.0844 ] Creating list of images to be signed
[   0.0908 ] tegrahost --chip 0x21 --partitionlayout flash.xml.bin --list images_list.xml
[   0.1307 ] 
[   0.1307 ] Generating signatures
[   0.1329 ] tegrasign --key None --list images_list.xml --pubkeyhash pub_key.key
[   0.1345 ] Assuming zero filled SBK key
[   0.1785 ] 
[   0.1786 ] Generating br-bct
[   0.2235 ] tegrabct --bct P2180_A00_LP4_DSC_204Mhz.cfg --chip 0x21
[   0.2253 ] Copying Sdram info from 1 to 2 set
[   0.2352 ] Copying Sdram info from 2 to 3 set
[   0.2353 ] 
[   0.2353 ] Updating boot device parameters
[   0.2366 ] tegrabct --bct P2180_A00_LP4_DSC_204Mhz.bct --chip 0x21 --updatedevparam flash.xml.bin
[   0.2381 ] Warning: No sdram params
[   0.2385 ] 
[   0.2385 ] Updating bl info
[   0.2398 ] tegrabct --bct P2180_A00_LP4_DSC_204Mhz.bct --chip 0x21 --updateblinfo flash.xml.bin --updatesig images_list_signed.xml
[   0.2416 ] 
[   0.2416 ] Updating secondary storage information into bct
[   0.2429 ] tegraparser --pt flash.xml.bin --chip 0x21 --updatecustinfo P2180_A00_LP4_DSC_204Mhz.bct
[   0.2447 ] 
[   0.2447 ] Updating board information from board config into bct
[   0.2460 ] tegraparser --boardconfig board_config_p2597-devkit.xml --chip 0x21 --updatecustinfo P2180_A00_LP4_DSC_204Mhz.bct
[   0.2778 ] 
[   0.2778 ] Updating Odmdata
[   0.2795 ] tegrabct --bct P2180_A00_LP4_DSC_204Mhz.bct --chip 0x21 --updatefields Odmdata =0x84000
[   0.2810 ] Warning: No sdram params
[   0.2812 ] 
[   0.2812 ] Get Signed section bct
[   0.2827 ] tegrabct --bct P2180_A00_LP4_DSC_204Mhz.bct --chip 0x21 --listbct bct_list.xml
[   0.2844 ] 
[   0.2844 ] Signing BCT
[   0.2872 ] tegrasign --key None --list bct_list.xml --pubkeyhash pub_key.key
[   0.2905 ] Assuming zero filled SBK key
[   0.2910 ] 
[   0.2910 ] Updating BCT with signature
[   0.2929 ] tegrabct --bct P2180_A00_LP4_DSC_204Mhz.bct --chip 0x21 --updatesig bct_list_signed.xml
[   0.2946 ] 
[   0.2946 ] Copying signatures
[   0.2960 ] tegrahost --chip 0x21 --partitionlayout flash.xml.bin --updatesig images_list_signed.xml
[   0.2974 ] Run tegrabct to update tboot signature in bct
[   0.3022 ] 
[   0.3022 ] Updating BFS information
[   0.3060 ] tegrabct --bct P2180_A00_LP4_DSC_204Mhz.bct --chip 0x21 --updatebfsinfo flash.xml.bin
[   0.3166 ] 
[   0.3166 ] Boot Rom communication
[   0.3181 ] tegrarcm --chip 0x21 --rcm rcm_list_signed.xml
[   0.3196 ] BR_CID: 0x32101001641225830800000013008600
[   0.3295 ] RCM version 0X210001
[   0.3341 ] B

It stops at the ‘B’ and does nothing else, could this be the VM’s fault? I could duel-boot linux on a labtop if so.

Now that I look back, I installed R28.1.0_aarch64 instead of R24.2.1_aarch64 for the rootfs and the driver package. Could this be the problem?

So long as you don’t mix R28 and R24 driver/rootfs either should work. R28.1 is recommended. The failure to communicate at boot rom is typical of a VM failure. Is this still a VM?

Yep, is that why it stops part way? I could duel-boot linux on a labtop if the VM is the problem.

The VM is a problem and is not officially supported. If you want to use a VM here is some information on steps you may need to take:
https://devtalk.nvidia.com/default/topic/1002081/jetson-tx2/jetpack-3-0-install-with-a-vm/

I installed Ubuntu 14.04 onto an external hard drive to avoid VM completely, and all was well except during the flash. The taskbar on the left turned gray and the terminal closed (I think). I didn’t even have the option to shut down or suspend, since that disappeared as well. Why did this happen and how can I fix it? Should I try Ubuntu 16.04?
IMG_20171120_222422.jpg

IMG_20171120_222422.jpg

You might try to open a second terminal, keep this on top of anything else, and run “dmesg --follow” until it does this…you should see the final message.

Can you use CTRL-ALT-F1 and get to a console? Perhaps it is just the GUI…it does seem like something crashed. There are many reasons why this might crash, but this is not a common occurrence while flashing from the host, it is unusual.

If this is specific to your situation, then I can think of two areas: One, perhaps USB re-enumerated…assuming your external drive is USB, you will want to make sure under “lsusb -t” that the hard drive is on a separate USB root HUB from the one with the flash going on…avoid bus re-enumeration (and I’m not speaking strictly of the way enumeration works when it all goes well…I’m thinking of reasons under which a brief glitch anywhere in USB propagates to other USB end points). There is actually a different possibility which is sort of this same thing…if a power saving mode went into effect the consequences could be similar. Do make sure your Ubuntu install is set to never suspend, and turn off such features until the flash is done…probably this won’t be the issue, but it is easy to test.

The second possibility is an issue with RAM. You may want to test under memtest86+. RAM issues may need testing overnight since the issue will only show up when something uses a certain address, and even then things may work part of the time and not fail unless that address is hit multiple times under the right circumstances (such as temperature and load). This is actually more common than people realize because not all crashes or failures are visible or obvious the way a complete system failure is.

YES! I attempted the flash again the next day and it worked!! Thanks so much for all your help, without you I would still be confused about what to do next. Thanks!

Glad it worked :)

One question, is OpenCV included in this?