So I plan to compile my codes on a separate Linux Ubuntu machine, and just copy over the built codes into the Jetson device itself.
With that, is it possible to remove some libraries/dependencies in the Jetson device that is only used for compiling and not executing? If so, is there a list of such libraries/dependencies?
You’re speaking of cross compiling. This is common, and in fact JetPack will set up your host for this if you install samples. When samples are installed the host cross compiles that code first before copying it to the Jetson.
Understand that there will be times when there is significant effort required to cross compile. Kernels are easy because they only involve a kernel. As soon as you add user space software you involve the linker and every library required for linking. This latter (the libraries) are also cross-architecture so far as your host PC is concerned. This is called the sysroot. The format the PC knows is “native”, the aarch64/arm64/ARMv8-a is “foreign” to the PC.
Even if you have cross-compiler and cross-linker correctly installed expect to need to add the dev headers and libraries used for building that software since the number of libraries and headers installed due to the sample software is minimal.
The official documentation downloaded with the L4T release version you are using has useful information, especially on kernel compile. However, I would start by using JetPack to see what it installs when you install samples. Be sure to uncheck flash, and then run JetPack with the TX2 not in recovery mode, and having wired ethernet connected (be sure to know its IP address, you’ll need to enter it manually at the console). Don’t bother with the micro-B USB cable because it is used only for flash.
I tend to advise people to install all of the required libraries and dev header packages needed on the actual TX2. Once this is done you can either copy those over from the TX2, or better yet, clone the TX2 rootfs and loopback mount it on your host so you have a complete copy of everything (which also serves as a backup if you ever lose everything on eMMC). Clone instructions differ depending on release (see “head -n 1 /etc/nv_tegra_release”).
Thanks for the very concise answer, let me try to explain my current situation.
Based from this, is my understanding correct in a layman’s term of steps?
Yes, to flash you would want an actual Jetson with a non-virtual machine Ubuntu 64-bit host PC. There are other steps where a VM wouldn’t matter, but flash itself is picky.
Yes, JetPack3.3 can set up and install packages to both an Ubuntu host and Jetson. By default JetPack install options will first flash, and then after flash completes and reboots, install software over the wired ethernet. If you don’t flash (you’d uncheck this in the options), and only install software, then you can leave out the USB cable and you can avoid putting the Jetson in recovery mode. If you are just flashing, and want to ignore adding any kind of package to the Jetson itself, then you could ignore the wired ethernet. If you just want to install packages to the host, then you could probably do so without having a Jetson present at all.
Yes, a clone of the rootfs gives you a 100% bit-for-bit exact match of the TX2’s root file system. If you had done package updates, and added devel packages for compiling software against, then your clone too would have that. Your cross-compile environment on the host PC could point at a loopback mounted clone and anything your Jetson could compile could then be cross compiled on your host PC. All linking would be against the exact library versions at the time of the clone.
At a later date a clone can be loopback mounted on a host and updated via rsync, e.g., after doing more package updates and/or additions to the Jetson. This would be quicker than a full clone.
If your virtual machine can run “sudo apt-get” commands, then you would need to add whatever dev packages you are interested in to do user space builds there.
To build a kernel or modules you do not need any sysroot (the user space libraries and linker tools). All you would need is the source code, a cross compiler, and the correct commands. JetPack can install the right tools. The “source_sync.sh” script from the driver package can download the correct kernel source. If you’ve flashed with JetPack, then this would act as a front end to the driver package, and thus you’d already have source_sync.sh. The “Linux_for_Tegra/” directory is from the driver package, and the content in “Linux_for_Tegra/rootfs/” is from the sample rootfs plus the “sudo apply_binaries.sh” step (and these steps will also be performed for you if you use JetPack to flash…but you can do this on command line as well).
Thanks a lot for the detailed answers.
Hopefully I could get an actual Jetson device from our client soon so I can begin flashing it and have my own copy of the rootfs cloned into my own Ubuntu machine.
By then I should be able to ask much more specific questions on actual Jetson development itself.
Before you clone you might make sure that all of the devel packages needed for compile are in place. It is easy to add a package with “apt-get” on a running machine, but not so easy to add a package to the loopback mounted rootfs without a running o/s.
Something to save you time since you expect to not have the actual device after cloning: Any time you do an “sudo apt-get update; sudo apt-get upgrade” to update packages check if all output shows “ok” from “sha1sum -c /etc/nv_tegra_release”. There is one libGLX.so file which at rare times gets overwritten…but notice that there is both an Xorg version of this and an aarch64 lib path version of this (the “nv_tegra_release” file is human readable…it is easy to see the two with “grep -i libglx /etc/nv_tegra_release” if you forget). The GUI will fail until the bad version is replaced…simply copy the aarch64 version into the Xorg version if this occurs (this will probably occur on a first update, and then never again). Then add all of your required dev packages (you might even test compile on the system before calling it good). That’s the best time to clone.
If you don’t want the dev packages on the TX2 after you are done, then clone before adding dev packages, add the dev packages, clone again, and then reflash with the non-dev version. Always save the raw version of the clone (I throw away the smaller “sparse” clone file). Those files are huge, but worth keeping.