L4T R21.7 — Maintenance Release for Jetson TK1

NVIDIA has released L4T R21.7, a software maintenance update for Jetson TK1.

Please see the Release Notes for more info.

L4T R21.7 download available here - https://developer.nvidia.com/linux-tegra-r217

FYI, the link at https://developer.nvidia.com/linux-tegra-r217 for “Trusty Packages -> Sample Root File System Sources” is not working. Similar for “Sample Root File System Sources SHA”/https://developer.nvidia.com/embedded/dlc/sample-root-filesystem-sources-sha-r217 (I suppose there can’t be a checksum for a missing file).

The other “Sources” link does work.

Thanks linuxdev, we will get it fixed and update the thread.

I noticed that compiling the Linux kernel sources for r21.7 currently fails as follows due to an erroneous + sign in front of an #endif in arch/arm/mm/fsr-3level.c:

In file included from /home/user/linux-3.10/arch/arm/mm/fault.c:554:0:
/home/user/linux-3.10/arch/arm/mm/fsr-3level.c:68:0: error: unterminated #else

make[2]: *** [/home/user/linux-3.10/scripts/Makefile.build:308: arch/arm/mm/fault.o] Error 1

Basically, the following commit is messed up (see double + signs at the very bottom):


BTW: What exactly is the tag tegra-l4t-r21.7.update-01 vs. tegra-l4t-r21.7 which got applied 2 resp. 4 weeks ago?

Thanks for reporting this Toradex, we’ll look into if it’s been patched yet and about the tag.

I highly doubt I will see a revival of the Grinch kernel but I would love that X11 support for remote connecting. Because of the End of Life of the Jetson TK1 development board, will this feature become integrated into a future JetPack release?

Could you explain more of what you mean by remote connecting? Most of what is there now is part of Linux, e.g., ssh. Particular packages depend on distribution, but virtual desktops also are part of Linux. I’m not sure if this is what you are asking, but if so you might be interested in:
(some people have mentioned “vino” to me which is for Gnome desktop…see “apt search vino”)

Also, the Jetson TK1 is no longer sold, but the Tegra K1 chip is long term support, so some manufacturers still produce TK1 products…just not the Jetson TK1 (which implies the dev carrier board). Toradex happens to produce one which is the same footprint as a DIMM memory module…you’d use their carrier board or build your own. I’ve used that before (but for Tegra3), and though it lacks enough pin count for more complicated products you might want to check it out (https://www.toradex.com/computer-on-modules/apalis-arm-family/nvidia-tegra-k1).

Greetings again linuxdev,

I meant I would like to use an X11 Terminal to remotely use the TK1 at a graphical interface level.

Well, specifically, because the Jetson TK1 is no longer sold, why would anyone compile an OS for it? Which is why it is up to the legacy consumers to keep it going, and if the eLinux wiki is any indication of how much much longer the community wishes to utilize it, I’m not sure I will ever see a kernel for the Jetson board itself. Because demand for wireless was so high, Grinch was essential out of necessity until the official release integrating the support. X11 support has been added after so long, I feel as though this was something needed back when the Grinch kernel was being developed and would have aided in increasing accessibility for the TK series. I can’t really evaluate this claim but the things I was trying to do 4 years ago would have really helped with X11.

I do understand that TK1 products will continue to exist, but that was my mistake for not being specific. Regardless, I would like to see a kernel release in the next Jetpack for all sorts of fun graphic experiments.

The Ubuntu sample rootfs is still available, along with the driver package for installing it (or JetPack…just not the recent one). The kernel is actually provided with the driver package (and JetPack can act as a GUI front end to the driver package). So I’m wondering if you mean a “recent” kernel? It is true that there won’t be any updates in this regard for a TK1. A big part of this isn’t that the TK1 itself is old, but is instead because the 32-bit world in general is losing support (arm32 is being deprecated for arm64).

WiFi should work on the more recent R21.5+ releases, but use the most recent (it has a security fixes). Grinch was backporting a lot of very needed features from newer releases into the R19.x kernel, but most of that ended up in the R21.x releases anyway (so Grinch wasn’t needed after that).

X11 has been supported since the TK1 first came out (I think it was installed with R19.1, and you could flash even in the beginning to R19.2). The recent releases have fairly high quality X11 support, but if you are trying to port to newer or other Linux distributions you might be running into the need for a specific X11 ABI. The NVIDIA video driver (also required for GPU in CUDA) is bound to a specific ABI of the X11 server. I forget where it is, but there was a thread around from a guy who managed to port CentOS and things worked well so long as he kept the X11 with that specific ABI.

The use of xterm remotely or locally works well on every L4T release of the TK1, I’m not sure of what you ran into, but if you describe more details a better answer might be available. If you have not flashed to a recent version you might also just be running into previously fixed bugs.

Keep in mind that if you remote ssh in to any Linux box and run xterm, then you’ll need to have the DISPLAY environment variable set up for forwarding. I typically do something from my host to my Jetson like this (the “-Y” is for setup of security in X11 forwarding):

ssh <b>-Y</b> ubuntu@jetson
xterm &
# Or the same thing if you installed the "geany" editor and used "ssh -Y":
geany &

A more specific example of what you want to do would help since I don’t know enough details to give a good answer.

One thing people often don’t understand about the TK1 release is that many years ago when the TK1 first came out NVIDIA had typically only released reference designs intended for third party vendors creating products (including carrier boards). The Jetson TK1 was thought of as something being sold to large companies to use in design of their own products…I don’t think it was understood at that point that the board would become so popular among the general public as an actual end product. The initial product introduction was seen only as an example…it ended up being and end user/enthusiast consumer market as well (perhaps because it was the first reference design available to the general public at a low cost). The way it has been supported since then has evolved for a more general product support, but since 32-bit has become deprecated all of the focus switched to the 64-bit hardware.

Incidentally, since the Tegra K1 chip itself is long term support (it’s only the dev carrier which is deprecated) you can still see third-party designs in production. Example:

About an hour ago before I plugged my TK1 to nothing I probably could have given you this glorious idea of how I was going to combine a Tomcat server and Arduino to automate live video game play, but now that my TK1 cannot power on (no led with live power applied and the power button does nothing) at all. I would say that my quest to find a purpose for my Jetson TK1 to come to a close.

I did and the media hyping the “next budget embedded supercomputer by Nvidia” understood it well but it is hard to understand why Nvidia continued to ignore the outcry for support as demand grew until it was too late.

I understand Linux is as Linux does. You give a man an OS, he will program within it. You give a man the tools to compile his own operating system from scratch, he can change his world as he sees fit. I was never out to change my world, I was just trying to find purpose within it, and the Jetson TK1 died before it ever lived. To be more specific the Jetson TK1 hobby enthusiast scene was never nurtured to grow and withered and died, but I suppose my non-functional board can also be called “dead” too.

Although the TK1 does not always auto-power on (and the LED won’t light if it isn’t on) the button (next to the MOLEX power connector) should cause the LED to go on. It isn’t unusual for video to not configure (which is in fact part of the reason why I suggested it needs to be flashed to a recent release), but the LED should light in that case.

FYI, HDMI itself has a wire for reporting the monitor’s capabilities to the video card. If you’ve used any adapter (especially 15-pin VGA), then the wire may have been cut.

Are you using the power supply which comes with the JTK1? Some power sources have problems due to a very short momentary drop in voltage at the moment of powering on. Some barrel connectors look like they are the correct size, but are not quite correct and it compounds that need for no voltage drop at the moment of powering up. If you can measure the voltage on the adapter I think it is around 12V. On the JTK1 this actually goes straight into the MOLEX power outlet (which is why it is 12V…it has to match that standard).

Am I correct in my assumption that you MrFreeman and linuxdev did hijack this sticky thread to discuss if not philosophise some completely unrelated issue(s)?

I try to answer questions with some insight (the difference between the saying of “feeding a man a fish”, versus “teaching a man to fish”). Not so much hijacking a thread as it is paying the ransom :P

Bottom line, someone has a problem and needs help even if it sprang from a maintenance release listing.

I do not consider this quite a hijacking but I apologize for my behavior.

The fact is there is no place for discussion on the web for the TK1 indie community if there is one at all. The fact linuxdev actually does take the time to reply and answer every single question I’ve had over the years is incredible, even with my own diet tribes thrown into the mix. There is a lot I don’t know about Linux and I will admit I bought into the hype of the board before having the background necessary for proper or intended utilization, but you have still managed to troubleshoot!

I will double check my power supply and take my issue to a new thread should any problems occur.

OK, these links to the root FS sources + checksum are now working:


r21.7 release had to be re-built because of some regressions after tegra-l4t-r21.7 was applied. So, the new release was tagged and uploaded with tegra-l4t-r21.7.update-01. That would be the correct one to use.

r21.7 release had to be re-built because of some regressions after tegra-l4t-r21.7 was applied. So, the new release was tagged and uploaded with tegra-l4t-r21.7.update-01. That would be the correct one to use.

Okay, at least for the Linux kernel sources I guess there was no change as both tags point at the exact same thing, right?

BTW: How about the Linux kernel build issue I mentioned above as well?

Please continue using your patch for the time being, we are looking into it further at this point.