L4T and JetPack on NVIDIA Jetson TX1

I have been reading the Jetson Forum lately and there seems to be a general confusion as to the relationship between JetPack and Linux for Tegra (L4T) version 24.1. A reader wrote in and asked a related question which I actually knew the answer to! This is a rare enough occurrence that I wrote this article as a response, and hopefully other people might find it useful.

Background

When the Jetson TK1 was first shipped way back in ’14, the system software was revision at L4T 19.2. L4T 19.2 uses a boot loader called fastboot to load the operating system when the computer starts. In order to upgrade to a different version, the user has to “flash” a new system onto the Jetson. This involves hooking up the Jetson to a PC host via a USB cable, placing the Jetson into recovery mode, and then invoking the flash application from a Terminal command line on the host. Here’s the “Quick Start Guide” should you suddenly feel the need to go temporarily blind. The quick outline is that you:

  • Untar the files and assemble the rootfs
  • Flash the rootfs onto the system’s internal eMMC
  • Install Optional Packages such as OpenCV4Tegra and CUDA

As you might guess, newcomers to embedded development probably don’t understand what the first two entries in the list mean. This is especially true if the developers background is from a Windows or Macintosh environment.

Also, it’s pretty easy to “fat finger” in a typo or two in command lines like:

sudo ./flash.sh -S 8GiB jetson-tk1 mmcblk0p1

so you can imagine some of the support questions that came through.

Time passes. NVIDIA decided to build a graphical user interface (GUI) front end to the process, which is a host application called JetPack. JetPack basically helps download the kernel image, flash the device, and add the optional packages without having to issue commands in the Terminal. Remember that JetPack is a wrapper to the installation process itself, basically calling the aforementioned command line instructions in an automated manner. When JetPack was first released, the L4T version for the TK1 went to the 21.X series. One of the major changes for 21.X is that the boot loader changed from fastbin to U-Boot. U-Boot is a more flexible boot loader for development purposes.

When the Jetson TX1 was introduced in ’15, JetPack was expanded to include support for the new board. You can flash either the TK1 or the TX1 using JetPack. JetPack will determine which version of each package to download and send to the Jetson.

Why doesn’t XYZ work?

The Tegra TX1 is a 64 bit ARM processor. When first arriving on the scene, the TX1 ran the 23.X versions of L4T. The inner workings of the operating system (called the kernel) were running in 64 bit, and the “user space” was running on 32 bit. The 32 bit user space provided compatibility with other 32 bit ARM applications, such as those running on the Jetson TK1. Running this ‘legacy’ app strategy is pretty standard stuff when changing architectures.

Anyway, as you might guess the villagers were up in arms. Where’s true 64 bit? Be careful what you ask for …

With the new release of 24.1, there are two flavors of L4T available for the Jetson TX1. The first flavor is 32 bit, which is the previously described 64 bit kernel, 32 bit user space. The second flavor is 64 bit, which is 64 bit kernel and 64 bit user space.

The immediate inclination is to load 64-bit on the Jetson TX1 and bask in all the goodness. You use JetPack to setup the Jetson TX1, and start it up …

Let’s open up a browser. Hmmm, no browser in the Dock, like on the 32 bit version. Ok, load up Firefox, launch it and … Segfault. If you’re new to this, replace the term Segfault with “no worky”. Try to load ROS from the repositories … No ROS in the repositories for this architecture. And so on …

Welcome to the world of bleeding edge. At this moment (July 2016) there are not a large number of 64 bit ARM processors out in the wild. The way to get what you need in terms of libraries and applications is to build it all from source. The ecosystem in the Linux world hasn’t had a chance to build up the support needed to build all the various bits and pieces and put them in packages and repositories yet. Over time, this will all happen. But not today.

Welcome to the land of milk and honey. You didn’t know that the milk was still in the cow and the honey was still in the beehive? You might get stung a little getting the honey out. Why is it called “bleeding edge”? Because you bleed.

Conclusion

It’s great to have 64-bit available on the Jetson TX1. It will also take some time to get the Linux ecosystem to support it for most users. So here’s the practical recommendation.

Money Quote:

If you’re planning on getting your particular project to work on 64 bit (such as doing a ARM 64 port of Mozilla or ROS), you have to work on the 64 bit version. Most other people will want to stay on 32 bit to develop with a plan of going to 64 bit when things get a little more mature in the Linux ecosystem.

PS: Let me add that is not about NVIDIA support, this is about Linux ecosystem support. The Jetson TX1 is a 64 bit ARM platform, the Linux ecosystem just hasn’t had enough time to build up around that particular architecture. It’s basically a chicken and egg problem.

11 Comments

  1. The 64-bit version seems to have a serious memory leak somewhere in the GUI infrastructure. It slows up and eventually locks up. If you are running a GUI on the TX!, avoid the 64-bit version until this is fixed.

  2. Hi

    I did the mistake to flash the 64 bits, but now I have a Zed camera need to downgrade to 2.1,

    so I’m using the Jetpack 2.2.1 and I had selected 2.1 to be install, is that the best way to do it?

    I had did tried to use the Jetpack 2.1 but during installation its fails on my host

    any advise will be welcome

    Thank you

  3. Thank you

    I actually did try the Jetpack 2.1 but during installation on the host it allways shows an error when doing an apt-get install and despite my host being an Ubuntu 64 bit AMD the error is related to the arm architecture

    Wired enough the installation halts and if I run a update on my host the changes made by the Jetpack changes the source list of Ubuntu packages

    So I had to manually remove the armhf architecture and do an apt-get update manually to get thinks working again

    Then I did try the Jetpack 2.2.1 and selected 32 bits and 2.1 version

    But not sure if this is correct

Leave a Reply

Your email address will not be published.


*