Hello,
Do we have to use jetpack inorder to install filesystem or is it that jetpack is actually the same as L4T SDK package ?
I see that all installation can be done using Tegra<>Linux<>_aarch64.tbz2 , so I don’t understand what is jetpack for.
Is the GUI for jetpack actually does the same as L4T package founded in : l4t-jetson-tx2-driver-package-28-1 ?
Does jetpack also builds all its installations or only uses the binaries ?
Thank you,
ranran
JetPack (and its replacement, SDK Manager) is a GUI front end. The actual flash is performed by the driver package plus sample rootfs, and JetPack/SDKM only flashes by means of those intermediate packages. JetPack/SDKM also act as a front end to extra package installs.
The normal install work flow is that the driver package is unpacked (without sudo) on the host PC (this is what produces the “Linux_for_Tegra/” directory and content, but the “Linux_for_Tegra/rootfs/” directory is empty other than a README file). Then the sample root file system is unpacked (using sudo) into the new “Linux_for_Tegra/rootfs/” directory. This sample is purely Ubuntu. Then the “Linux_for_Tegra/apply_binaries.sh” script is run (with sudo) and this adds direct hardware access drivers to the sample rootfs. Now you can refer to the “rootfs/” content as either Ubuntu or L4T.
Flash always occurs with the Jetson in recovery mode. This does not actually change the Jetson, but it does cause the Jetson to become a custom USB device which is understood by the driver package (which is on a host, not the Jetson). The driver package then flashes, and in the end, the Jetson reboots. JetPack or SDKM would have downloaded the driver package and sample rootfs, and would have also run the apply_binaries.sh step for you after asking for your password. Then JetPack/SDKM would have run the actual flash (by sending the right command to flash.sh of the driver package).
Once the Jetson is rebooted (and running Linux instead of being in recovery mode) the driver package and sample rootfs are no longer involved. Nor is USB. Package addition occurs over the Jetson’s wired ethernet (there is now work going on to make it possible to use a virtual ethernet card on the Jetson via the micro-B USB cable…which implies needing the USB cable to be connected…but this is still actually wired ethernet despite the wiring being over USB with a synthetic ethernet card…mostly just use wired ethernet unless you know about setting up for this). JetPack/SDKM can modify the host to act as a router for a directly connected Jetson, or can be set to depend on a separate router appliance (check options for network style as you go along). JetPack/SDKM then downloads a manifest over the internet, and the correct packages (which is what the manifest lists), followed by copying these packages to the Jetson and installing in the correct order.
JetPack and SDKM are convenience tools. These tools know where to download software, and know the order of install. As of L4T R32.1 SDK Manager is the only advertised method of downloading the other packages. JetPack is the predecessor of SDKM, but is still used for releases prior to R32.1. SDKM version 4.2 corresponds to L4T R32.1. Had JetPack continued (3.3 is the last release of JetPack), then it would have been JetPack4.2 instead of SDKM4.2 (the numbering continues from JetPack into SDKM).
Do note that SDKM allows you to download packages without actually flashing. This leaves the “Linux_for_Tegra/” directory (the driver package) such that you can still manually flash…only the download tool differs.
Package installation is always a separate step from flash, but JetPack and SDKM allow you to add packages without flashing, and also allows you to flash without adding packages. You don’t have to flash every time you run JetPack/SDKM.
The package addition steps which occur only after the flash does try to cross compile examples on the host before copy to the Jetson.
My advise: If you want the latest (and probably you do unless you have a compatibility issue) L4T R32.1 with CUDA 10, then use SDK Manager 4.2. If you are using R28.1, which is actually old and not recommended, then use JetPack (I forget which release is for R28.1, but JetPack3.3 is for R28.2.1). If you don’t need to flash, then just uncheck that step and only connect wired ethernet without using recovery mode. Never use packages from one JetPack/SDKM release on a system flashed with a different version of JetPack/SDKM/L4T because they are not compatible.
Here is a listing of previous JetPack releases (keep in mind some of the URLs related to download may require you to log in again, but since they don’t always redirect correctly, then you might have to go to that URL a second time to see full content):
[url]https://developer.nvidia.com/embedded/jetpack-archive[/url]
The sample root file system is the reference Ubuntu arm64/aarch64 system. These are pre-built and you don’t need to compile anything, but sources do exist for download. It is possible to substitute another file system, but this is an extremely difficult thing to do if you want to maintain direct hardware access (e.g., if you want to use CUDA on the GPU and have hardware accelerated video).
One valid reason to use the driver package and sample rootfs directly (versus via JetPack/SDKM) is if you must flash from a non-Ubuntu host (I use Fedora…my Ubuntu is a tiny dual core Atom laptop). As of L4T R32.1 you would still need SDKM to download driver package and sample rootfs for you since the web pages no longer support direct download.
One other example of why you might flash on command line without JetPack is that L4T R28.3 is a bug fix release which did not come with a full JetPack release. So JetPack doesn’t know how to download R28.3, and if you wanted this release, you’d instead download the driver package and sample rootfs (this release is compatible with extra software from JetPack3.3 though, so you could still use those packages, which is an exception).
linuxdev,
Thank you very much for the detailed answer!
ranran