Hello I am planning on using the Jetson TX2 in an industrial computer vision application The IT team at my company have their own procedures so it won’t be possible to use Ubuntu on a workstation nor let the jetpack installer fetch data online “freely”, so I was wondering if it was possible to use RHEL or CentOs 6 for the setup instead of using Ubuntu 16.04 .
Also is it possible to make the jetpack installer fetch data from a location on the Hard drive instead of fetching data online ?
thanks in advance!
I recall forum user linuxdev saying that he had unofficially used JetPack on the host side with Fedora, however I am unsure if it would work with the older RHEL/Centos distributions.
You can have JetPack download the packages in advance, they are stored in jetpack_downloads/ folder underneath where the JetPack executable resides, however JetPack will still require internet connection to read the package manifest.
In lieu of that, what you can try doing is installing L4T directly from the downloads here: [url]https://developer.nvidia.com/embedded/linux-tegra[/url]
Not all of the packages are available through that page, like CUDA toolkit, cuDNN, and TensorRT for aarch64. What you can do is have JetPack download those packages on your host, then manually copy and install them to your Jetson.
Note that although flashing JetPack-L4T from within a virtual machine is unsupported, unofficially you should at least be able to have JetPack download the packages within a VM (running Ubuntu), at which point you can copy them out of your Ubuntu VM and manually install them to your Jetson.
What I did (someone else I am grateful to discovered this) was cause JetPack to extract the repository.json file via running “./Chooser” (you have to chmod it to make it executable…it is in the “_installer” subdirectory after trying to run JetPack even on Fedora). Within this file are all of the URLs used to download different software which JetPack would use. This includes URLs for both host and Jetson, and for different models of Jetsons, so you have to look at descriptions to find the ones which belong to the TX2. For example, you might see reference to “jetson_64_tx1”…the 64-bit TX1 software…or “tx2_64bit”. There are now also some tx2i entries.
JetPack knows the order and dependencies, but if you wget the packages you are interested in, then install those manually on the Jetson with dpkg, the effect is the same. The major issue is it may be trial and error as to what must be installed in which order.
One tip is that you always want the “cuda-repo” package for arm64 (not amd64, not arm32, not armhf) installed before anything else. This actually puts a local repo on the Jetson for some of the CUDA items. After that is in you could install other packages obtained with wget.
Another tip is that you can sometimes install multiple packages from a single dpkg command. If you have three packages and don’t know the order, but do know that there is some dependency, then you can sometimes save effort by seeing if dpkg can figure out the order when you name all in a single command.
These days I try to use an old atom 64-bit laptop to do this.
Note that getting packages to a Jetson, when not flashing, is just an ordinary package update and is nothing special on a Jetson. Downloading and picking the files through JetPack is what is special…but if you already have the files and know the install order there is no issue.
Flashing using command line driver package plus sample rootfs is never an issue on any x86_64 Linux. With one exception any such PC can do flash. That exception is easy to get around. This particular issue is from 64-bit extensions being enabled by default for mke2fs on the newest and latest of PC Linux hosts…you simply edit the flash.sh script to disable those extensions (which didn’t exist when flash.sh first came out).
To tell if a host has 64-bit extensions in need of disabling look at your host PC’s “/etc/mke2fs.conf”. Within the ext4 block you do NOT want to either of “metadata_csum” or “64bit”. You could remove that for your whole host, but it is better to just edit the flash.sh so it disables this during flash.
If you examine flash.sh you will find this line (line 507 on my script…but I may have changed a line or two):
mkfs -t $4 "${loop_dev}" > /dev/null 2>&1;
If you edit to become this it will ignore 64bit extensions and do the right thing (you are safe to do this even if your host doesn’t use 64bit…this should really be part of the default script):
mkfs <b>-O ^metadata_csum,^64bit</b> -t $4 "${loop_dev}" > /dev/null 2>&1;
Note: flash.sh is part of the driver package. The rootfs is from the sample rootfs. JetPack is a front end to these two packages during flash…after that it just does network operations for packages based on repository.json.
One other thought: If you were to flash once using the actual JetPack and save a log of the file install order then a manual install could be scripted based on that.
thank you for your tips. I’ll get back to you guys with the updates as soon as I try it!