JetPack 2.2 and L4T R24.1 for Jetson TX1 released

We’re pleased to announce that the full compliment of Linux4Tegra R24.1 packages for Jetson TX1 have been released, including Jetpack and the CUDA installers for both 64-bit and 32-bit userspaces. Updates to VisionWorks, OpenCV4Tegra, and cuDNN are also posted, included in the links below.

L4T R24 is available in both 64-bit and 32-bit flavors, depending on the preference of the developer. Jetpack 2.2 will automatically flash your Jetson TX1 with the latest OS and tools, or you can install manually with the core L4T packages. Upgrading previously existing images is not officially supported.

Download Jetpack 2.2 bundle — [url][/url]
Access L4T components/docs — [url][/url]
Please see the Release Notes — [url][/url]

Many thanks for the so long waited release :)

Just a quick hint for those with host Ubuntu > 14.04:

I haven’t found anything so far that prevents me from installing on my updated 15.04 release, just the installer will not jump over version verification.
So edit /usr/bin/lsb_release like this:

   if options.release or options.all:
        if short:
            print(distinfo.get('RELEASE', 'n/a'))
#            print('Release:\t%s' % distinfo.get('RELEASE', 'n/a'))

And the installer will work as it should. After install you can roll back the change.

Yahhhhhhhhhhhhh!!! Cheers!!!

Cheers on the update to R24. I do have some new messages on the console that I don’t understand. Has anybody seen these after refresh of TX1 to R24?

RTNETLINK answers: Network is unreachable
[ 16.505749] tegra210_mixer tegra210-mixer: ASoC: hw_params() failed: -22
[ 16.512452] tegra-snd-t210ref-mobile-rt565x sound.27: ASoC: PRE_PMU: TX1 Transmit-MIXER1-1 Receive event failed: -22
RTNETLINK answers: Network is unreachable
saned disabled; edit /etc/default/saned

The RTNETLINK only happens twice and Wifi seems to work okay. Not sure what the sound errors indicate or the “saned disabled” message.

Any ideas?


Hi I’m just trying to download carrier board pdf file [the link above], but unfortunately it said page not found. Is there a cached copy or any optional link available? Or is there an update version coming soon?

The general embedded downloads are here:

You do have to be logged in first, or else the page may not show what you want. There is a carrier board spec file URL available there which works once logged in.

Hi, i was install 2.2 version, but i got error.
after jetson got system image, after the reboot, jetpack installer lost the communication between hsot and tx1. Basically it said connection closed and

Error: CUDA cannot be installed in device. Please use apt-get command in a terminal to make sure following packages are installed correctly on device before continuing:
cuda-toolkit-7-0 libgomp1 libfreeimage-dev libopenmpi-dev openmpi-bin
after these packages are installed on device, press Enter key to continue

I download deb file, but “sudo dpkg -i” gives me error

I was able to this using individual packages (no JetPack…ssh or serial console login…took some time to get a stable GUI login):

<b>sudo -s</b>
# First update everything in general.
apt update
apt-get upgrade
apt-get autoremove
# .deb repo packages were already downloaded to current directory.
dpkg -i cuda-repo-l4t-7-0-local_7.0-76_arm64.deb
dpkg -i libopencv4tegra-repo_2.4.13_arm64_l4t-r24.deb
apt-get install cuda-toolkit-7-0
usermod -a -G video ubuntu
apt-get install libopencv4tegra libopencv4tegra-dev

In L4T-r24.1, is there any update related to gstreamer version or its plugin?

I just flashed 2.2 to my TX1 - 64bit and I cannot get firefox to open. Also everything on the desktop keeps freezing. I tried to flash this 2 more time with the same problem. I tried all of the normal fixes to include update and dist-upgrade. Anyone having similar problems?

There is a segmentation fault related to javascript, but without building a non-optimized version of firefox specifics are not available. Details below.

I tried to open firefox remotely from Jetson to my x86_64 host machine. Connected via “ssh -Y”, then ran firefox on command line. The purpose of this was to separate graphical display dependencies and desktop environment away from Jetson, and isolate behavior strictly to the runtime with everything graphical depending only on my desktop host machine (one which has everything set up and 100% tested for anything graphical).

I also get a hang if I start with the simple command line “firefox” (the shell front end pointed to by the symbolic link “/usr/bin/firefox” means you are really running “/usr/lib/firefox/”, which in turn opens “/usr/lib/firefox/firefox”). The issue shows as not being dependent upon the graphical environment, with a segmentation fault.

You can run “firefox --help” and see a number of options which can use in opening the binary file of “/usr/lib/firefox/firefox”. One of those options is “–debug” for starting firefox within gdb debugger. To make use of this you first need to install the debug symbols via:

sudo apt-get install firefox-dbg

The stack frame at failure is extremely large. At first I didn’t have actual firefox source code, I was disappointed to find that even with a stack frame I couldn’t see actual code in the backtrace. So further source code is required beyond the dbg package. The backtrace named “firefox_47.0+build3”, which I found here:

Once source is unpacked to “/build/firefox-lAZp76/firefox-47.0+build3” a useful backtrace can be presented, along with complete source code at each frame. Unfortunately, optimizing has stripped out actual values in the stack frame, so it isn’t possible to determine what arguments were actually passed without rebuilding firefox (optimizing needs to be removed). Build instructions are here for those interested:

The amount of RAM and other resources mean building a debug/non-optimized version on Jetson would need a lot of swap space and time, so I stopped at this point. Maybe someone else is more ambitious.

I’m wondering if anyone knows of any full 64-bit ARMv8-a/aarch64 platform actually runs firefox successfully? Does anyone know of any Linux 64-bit ARM environment on which firefox can be tested as run or fail?

Looking at strace there wasn’t a lot of useful information. Lots of FUTEX messages, perhaps this is really a threading issue.

Looking at ltrace things become more useful, but nothing conclusive. There may be some issues with threading which have a chance of being a bug of libraries and/or kernel, rather than from firefox. The tail of the failed ltrace:

strlen("nsSocketTransport")                                                               = 17
pthread_mutex_lock(0x7fb6100040, 18, 0, 0x3d74657372616863)                               = 0
pthread_mutex_unlock(0x7fb6100040, 32, 1, 0xfffff000)                                     = 0
strncpy(0x7fb602a280, "nsSocketTransport", 17)                                            = 0x7fb602a280
pthread_mutex_lock(0x7fb6100040, 56, 0, 0)                                                = 0
pthread_mutex_unlock(0x7fb6100040, 64, 1, 0xfffc0000)                                     = 0
pthread_mutex_lock(0x7fb6100040, 31, 0, 0x7ffc1ac004)                                     = 0
pthread_mutex_unlock(0x7fb6100040, 32, 1, 0xffffc000)                                     = 0
pthread_mutex_lock(0x7fb6100040, 32, 0, 0x7fb36b4a06)                                     = 
disable_breakpoint pid=8022, addr=0x55952f0d80: No such process
get_instruction_pointer: Couldn't read registers of 8022.
+++ killed by SIGILL +++

Apparently the instruction pointer corrupted or was otherwise invalid, possibly hitting at a thread context switch.

I’m afraid I haven’t had any luck with the all-64-bit version. There seems to be some kind of (graphics?) resource leak. It starts zippy enough, but then slows to a jerky crawl eventually, and finally locks up. This is especially acute if I run the ‘particles’ cuda example.

Any suggestions for debugging what is wrong? Neither dmesg or tegrastats seems to tell me much.

I have gone back to Jetpack 2.1, which runs fine on the same hardware.


In JetPack 2.2 on TX1 for 64bit don’t work console mode (ctrl + alt + F1 … F6) - black screen instead console. On TK1 (L4T 21.4) it work fine.
Can you help me?

This is probably the same issue as listed here:
[url]Switching to tty1-6 - Jetson TX1 - NVIDIA Developer Forums

There is a patch which I’m trying to test, but I’m having issues with my cross compilers on Fedora 23 (some compile details are pickier on the R24.1 release versus older releases). You might try that fix if your host is Ubuntu (cross compilers should just work on Ubuntu hosts). The gist of the issue is a bug in monitor information/capability query failing.

I am having the same GUI freezing issues as reported in post #10 (JetPack 2.2, L4T 24.1, 64bit). Is there a fix or is the solution indeed to return to JetPack 2.1 as suggested in post #12?

There is a thread that seems dedicated to the 64-bit graphics problem:

It looks like there is a memory leak in the 64-bit graphics infrastructure somewhere.

No fix/ workaround has been suggested as yet.

We’re currently investigating, determining root cause and will provide updates when available. Thanks for your reports and feedback.

If you’re experiencing an issue using Firefox or Chromium, a workaround is to try lightweight Dillo browser:

External Media

It’s included the aarch64 default repo:

sudo apt-get install dillo

What audio codecs can be used?
You can use DMIC?

Hi adistel,

DMIC is not supported on Jetson TX1.