Hi just wondering if a new version of L4T “Jetpack” has been released for my TX2?
I’m still running R27 Rev 1.0.
If so where is the download and does it still need to be flashed through from a PC running Ubuntu or can I upgrade in place?
Thanks.
There have been hints the release will be “very soon”. You won’t be able to upgrade in place though. I typically clone and then overlay some of that onto the sample rootfs before flashing (e.g., ssh keys and network setup customization…even entire directory trees). If you want to read about cloning the TK1 description is good, but actual command for TX2 clone is here:
[url]https://devtalk.nvidia.com/default/topic/1000105/jetson-tx2/tx2-cloning/[/url]
Note that the above URL has a patch for flash.sh, but this should be in the next release by default (the “-G” option).
To read more about cloning see this:
[url]http://elinux.org/Jetson/Cloning[/url]
If you git clone the kernel sources, you will note that there are two tags: “tegra-27.1” and “tegra-28.1.”
Thus, my guess is that the kernel is “done” for the next Jetpack release, and the NVIDIA release people are waiting for other bits and pieces to fall in place to create a full “Jetpack.”
Also: No, upgrading in place is not a supported operation. It’s probably possible to get all the right bits into all the right locations, but you’d have to do that through reverse engineering yourself; there’s no online help or tools available for how to do that.
Related question: all the stuff I’ve installed on the TX2 under 27r1…will that all disappear when I upgrade to 28.1 via flashing?
Short answer: Yes, everything will be gone!
Long answer: Installation on the target “should” be done through some kind of automated configuration management tool. Whether this is “puppet” or “git” or “nix” or “a shell script I re-run from scratch each time” is really up to you. The embedded system development tools are set up to do development on the host PC, and do deployment by creating a new flash image, and re-flashing the device. You’re supposed to do that “often” and thus not be attached to any particular application state on the module.
I use a script that backups the things I modify into a cpio archive on the host PC.
I can then restore this backup, in theory. (I haven’t tested restoration on a target, and thus this is not actually yet a “backup” but instead an “optimistic assumption.”)
I make sure to only change configurations in /etc, files in /home/nvidia, and put all my local stuff in /usr/local. Additionally, I extract the list of installed packages, so I can re-install them as needed later without forgetting anything.
The script works by copying a separate script to the Jetson, and then using that script to generate the cpio archive, and capturing all the output (this runs over SSH.) It also hard-codes the IP address of my Jetson (10.0.0.86) so you’ll probably have to change that if you try the script. Finally, yes, you need enough space on the host to store the backup, and RESTORE HAS NOT BEEN TESTED and there are no scripts to automate that part. You have been warned.
backup-jetson.zip (523 Bytes)
Okay I get it. That’s where the “host” PC comes into play. I’ve kinda been using my TX2 as my main workstation - works remarkably well actually. Disciplines me to write performant code because on my 4Ghz i7 everything runs fast. But I get that you’re supposed to be keeping the HOST modified and then flashing the entire thing from there. Details are a little dense for me at this stage but I’ll parse your response more carefully tomorrow. Thanks for the help, Snarky.
– Vegabook.
To be fair, I do that too. I prefer that mode of development. But, as the device will have to be flashed periodically, good source/change/configuration control practices are suddenly very important!
Hi snarky
How do I upgrade JetPack 3.0 into JetPack 3.1 on TX2? I have no idea to how to do it.
Thanks.
JetPack itself only runs on an x86_64 PC (and was intended for Ubuntu 14.04, though people have had success on 16.04). The flash part of the software can be run separately (driver plus sample rootfs together) on command line and requires any x86_64 Linux.
I haven’t done it, but what people have mentioned on the forums makes me think that if you ran JetPack 3.0 in the past, then if you have trouble with a package conflict under 3.1 you could uninstall the package via 3.0 before installing on 3.1. Actual L4T release via flash won’t care about other packages, all package management function occurs after a flash, so there probably can’t be any kind of glitch if you just flash.