Failed to boot L4T R32.2.1 on Jetson TX1


I’m trying to boot the Jetson TX1 with the new L4T release supporting DeepStream 4.0.1, but for some reason it fails to boot (or at least this is what I think by looking at the energy consumption of the board).

I’m using the NVIDIA’s stock development board, connected to ethernet connection with internet access and DHCP, and connected to host computer via USB. Host computer is Ubuntu 18.04 x64 and also has internet connection.

What I’ve tried:

  • Flash the L4T R32.2.1 and all JetPack 4.2.2 with SDK Manager. Says flash is successful.
  • Flash L4T R32.2.1 directly using terminal tool. Again, says flash is successful, same result as using SDK Manager.
    In both cases, the board won’t give any signal it is booting, no HDMI output and power consumption doesn’t get above 3W. Not able to connect via SSH. Is there any other way you can think of to determine it is actually not booting?

What worked:

  • Flash L4T R28 + JetPack 3.3 using SDK Manager
  • Flash L4T R28 + JetPack 3.3 using legacy JetPack 3.3 utility
  • Flash L4T R28 + JetPack 3.3 using terminal utility

So the board is currently working flawlessly, but with previous version of JetPack/L4T. Any ideas on how to proceed?

Thank you!

I too am having troubles with the more recent revisions. I’m struggling with 32.2.3. I’m using the a01 devkit, with a very similar setup to your dev board (usb to Ubuntu 14.04 x86_64 host, and ethernet on devkit to internet). The TX1’s I’ve been working with also used to have R28 and they worked just fine then too. I really want one of the newer L4T releases because of the kexec command introduced in Linux 4.X.

I successfully got the system in recovery/flash mode, and verified that with the lsusb utility:

ryan@tetris:~/RegOS/L4T_R32.2.3$ lsusb | grep NVidia
Bus 003 Device 016: ID 0955:7721 NVidia Corp.

I then executed:

sudo tar xpf Tegra210_Linux_R32.2.3_aarch64.tbz2
sudo mv Linux_for_Tegra L4T_R32.2.3
cd L4T_R32.2.3/rootfs/
sudo tar xpf ../../Tegra_Linux_Sample-Root-Filesystem_R32.2.3_aarch64.tbz2
cd ..
sudo ./
sudo ./ jetson-tx1 mmcblk0p1

The output of looked good to me, but here is the output of that command if you’re interested:

Perhaps the output of is more interesting. I had to cut out the Raw to Sparse Image conversion part of the log as then I wouldn’t be able to share the log as it is so long. I can’t imagine anyone can make sense of that much data anyway. A link to the output is here:

I also captured the output of the UART port from the TX1 during the flashing and then boot process. That log can be found here:

In that last log, I did notice some I2C and eeprom read failures. I am not sure why that would be, so I tried a different TX1 module and a different a01 devkit, but got the same result. Notice at the end of the log it says that “tegra-xudc-new 700d0000.xudc: setup request failed: -95” and then to complete the rest of the setup on /dev/ttyGS0

I searched for /dev/ttyGS0 in the dev guide, but did not find it. The dev guide I searched through can be found here: Google was equally unhelpful.

Ah, my mistake. The last usable version I was using was R24. I have since tried R28, which is on Linux 4.4.159 and it does work as the OP said.

Not sure if you guys know this information. After rel-32, you need a HDMI monitor to configure user account and password. According to @RLC’s uart log, your system is waiting for your configuration.

[    6.531153] Please complete system configuration setup on /dev/ttyGS0 to proceed...

However, you said HDMI have no signal. I would suggest to try different hdmi monitor first. Also, make sure there is no adapter on your hdmi (e.g. DVI-> HDMI/ VGA->HDMI/ DP-> HDMI…).

If you don’t have other monitors to try, then please use this script I shared for debugging.

It was for jetson nano debug, but should be applicable to TX1 too.

Hello WayneWWW,

Thank you for your answer. I tried earlier with several HDMI monitors, however, I will try the script you shared and will come back with feedback.

Thank you, best regards,

Well that changes the manufacturing process for systems making use of the TX1. Is that also true for the TX2?

Thank you for informing me of that. Where was that information made available by Nvidia?

Could oem-config also work around this problem when it is run in headless mode? I’ve not used it myself, and am not quite sure what is for.

So it seems the problem is solved. Nevertheless, I suspect there might have been another issue which was causing the actual problem.

When I came back from Christmas holidays, I decided to give this another try. I tried downloading latest SDK Manager in Ubuntu 16.04 host machine, then connected Ethernet, micro USB, HDMI and power to the Jetson TX1, and flashed it. There was a difference, it was that the board is actually powering on after the flash (I can tell that because I saw the NVIDIA logo and also because of the consumption - this was not the case in the previous tries with the latest firmware, I’m not sure what was changed apart from the SDK Manager version).

But even it was powering on, I was unable to see the HDMI output after the boot, there was no other sign that it has booted, only that I already knew the IP assigned by the router via DHCP. So I was able to ping the board and I knew it was booted. Then, I followed the procedure indicated in your answer, and I was able to flash once again and login with the provided username and password.

Thank you very much, best regards,