Jetson TX2 turns on and only displays NVIDIA logo screen

Autonomous Machines Jetson & Embedded Systems Jetson TX2
1

Hey everyone,

I’m using a Jetson TX2.

It has been working for a week now straight out of the box, and it seem to come pre-flashed with Ubuntu 18.04, and it does not rely on an SD card.

Yesterday I was working on it and it was running fine. I went to turn it on today and every time it goes to the NVIDIA logo screen and does nothing else.

At a loss on what to do…

Slightly annoying as I was also working on some code during the whole week on the device and it would be a shame to lose that too. (Stupidly didn’t back up, ironically I told myself that I’d do it today just in-case something happened … and well, it happened).

Also when I try to get the Jetson TX2 to go into recovery mode it makes the USB connection sound but nothing shows up on my windows10 machine, and because of that I cannot do a USB passthrough to a virtual machine (Hyper-V).

Been using out-of-the-box power supply etc.

Thanks

EDIT1: Using Oracle Virtual Box instead of Hyper-V now, will see what I can troubleshoot with that. I believe this software has an easier method to pass USB. Will update.

EDIT2: Ubuntu 18.04 LTS Desktop ISO is busted on Oracle, can’t even work it out. Constant errors, constant redownloads. Files are probably corrupted somehow.

2

As long as the unit can reach recovery mode you can clone the rootfs partition and save your work (it does take time and a lot of disk space on the host PC). Clones can not only be examined, they can also be used for flashing in place of a generated default image.

Note that Windows has no ability to work with a recovery mode Jetson, and the host must be a Linux PC (the GUI software requires Ubuntu 18.04, but command line works with any Linux PC). A recovery mode Jetson is a custom USB device, and is not mass storage. Recovery mode requires a special driver to work with, and there is no such driver (for good reasons) on Windows.

Before talking about cloning, you will probably need a serial console boot log to see what is going wrong. It isn’t unusual for the GUI to fail, and yet the system otherwise boots normally. For example, the monitor must be an HDMI monitor, and not a VGA monitor with HDMI adapter…for this latter case you might get lucky and it would boot and display correctly, but would randomly stop working…in which case an actual HDMI monitor would fix the issue.There are a lot of reasons to not trust the GUI to say if the unit failed or not. You can find information on serial console here:
http://www.jetsonhacks.com/2017/03/24/serial-console-nvidia-jetson-tx2/

Serial console can log all activity, and you could log the full boot and post the log here, which would be very useful.

FYI, the “default” install may be rather out of date, and you’d want to update anyway (though you probably want a clone of your work). Clones cannot be directly flashed if the release version changes, but for example, home directory and your content could simply be copied in to the location where the default image is generated…the content would just “be there” when flash completes (takes a bit of extra knowledge though).

VMs can be made to work, but are not officially supported. A VM will not handle USB connect/reconnect correctly without extra knowledge and work, and a recovery mode Jetson connects and reconnects during flash operations. You would be far better off with a native Linux install, preferably Ubuntu 18.04 so you can use the GUI. You need plenty of extra space. Even a base flash implies you’d want about 50GB of free space, but as soon as you clone, you can expect the clone to be nearly the entire size of the memory of the Jetson all by itself.

Regarding clones: You can clone with most any release of flash software. The clone information will change depending on release. You should restore only with the release which originally created the clone. You should pick the release based on the newest release which has a compatible CUDA release version (CUDA release is tied to the install release due to strong dependencies…CUDA version does not correctly mix across install versions).

An install/flash starts with stock Ubuntu and adds drivers from NVIDIA, and becomes known as “Linux for Tegra” (“L4T”) after that. JetPack/SDK Manager are just GUI front ends. Actual flash is from the package known as the “driver package”, and JetPack/SDKM download and install this from a GUI for you, but the driver package itself is capable of command line. The driver package only flashes or clones. If flashing with default software, then you would also be unpacking the sample rootfs package and the driver package would create a flash from that content.

You can find the different releases of L4T and JetPack/SDKM here (you will probably have to go there, log in, and then go there a second time since redirect tends to not work):
https://developer.nvidia.com/linux-tegra
https://developer.nvidia.com/embedded/jetpack-archive

FYI, when installing the GUI software (JetPack/SDKM), and then running that software, a directory “~/nvidia/nvidia_sdk/JetPack_...some version.../Linux_for_Tegra/” is created (the “~” is a shortcut in Linux and other *NIX clones for the home directory). The content of the “Linux_for_Tegra/” directory is actually the driver package (and like with “Linux_for_Tegra/rootfs/” having been populated with a generic Ubuntu 18.04). So it takes plenty of space, and then during the flash you’ll want to have about 50GB or more free. If you work with clones, then you’ll want to add another 35GB or so.

As painful as that may sound, once you have an Ubuntu host PC life is much easier. You can set up for dual boot if you have disk space (and you can even add a new disk and leave the Windows disk alone), or use the partition manager to reduce size of Windows to leave spare space for Linux (I’m guessing you won’t want to do that, most people do not unless they have a rather large disk).

To summarize, if you can post a serial console boot log, then it might turn out that things are actually working, and perhaps a non-GUI login method would allow you to fix things. We need that log though to find out (a serial console logs even in boot stages prior to Linux ever starting, so it works reliably).

If you decide you want to clone, or flash, just ask for more information.

3

Thanks for the suggestions !

I’ll give these a go, I’ll start with a HDMI cable and TV change, since I am (and have been for the past week) using a HDMI to VGA cable (I’m hoping that this is the issue since I didn’t do anything unusual to warrant a failed boot, but we shall see). If that is not the issue I will do a dual-boot Ubuntu 18.04 and check serial console logs etc. , and then get back to you if it does/doesn’t work.

Thanks again.

4

When HDMI came out it allowed auto configuration where the monitor itself reports its own capabilities. In the days of VGA one had to add a “driver” (which was really just a database of capabilities), and when HDMI came along no driver was needed because of the monitor’s ability to self-describe. This is the EDID data (the wire is the DDC wire). Without EDID the driver cannot self-configure. Some people will say that later VGA had EDID added, but this is from an older protocol not used by newer hardware, and a Jetson won’t use this.

The reason this is so important is that most PC drivers allow setting up common modes without EDID. Jetsons do not allow this, the EDID is the only accepted configuration method. You might get lucky and the default mode happens to be a mode the monitor also works with, but this is just coincidence.

Also, the range of modes a Jetson works with is less than the range of modes a typical PC works with, and so something like an HDMI television might work well on a Jetson, but it is also possible that the modes are “extension” modes which won’t work. It is worth testing because I suspect most HDMI televisions have some working modes.