JetPack itself is just a graphical front end to the flash software. The flash software itself has no knowledge of what it flashes, and the rootfs is merely binary data so far as it is concerned. If you use command line you have other options, e.g., cloning, or flashing on command line with other arguments (most notably the “-r” option to “reuse” the generated rootfs filesystem instead of generating a new one…if you have a clone there or something custom it then flashes that content).
FYI, a normal flash takes a purely Ubuntu root filesystem and unpacks it in the “Linux_for_Tegra/rootfs/” directory. Then the “Linux_for_Tegra/apply_binaries.sh” script is run to add the NVIDIA-specific drivers and libraries to the purely Ubuntu content. This is when it becomes “Linux for Tegra” (“L4T”). On a booted system, when you run this command to check content integrity, it is the apply_binaries.sh content which is being checked:
sha1sum -c /etc/nv_tegra_release
Once a set of files exist in “rootfs/” arguments to flash.sh will determine some edits or added content to boot configuration (other than “rootfs/boot/” most everything in the image is verbatim).
Then a blank file the size of the entire root filesystem is created. Loopback covers the file, and then the file is formatted to ext4 as if it is a real hard drive partition. This will become “bootloader/system.img.raw”. A smaller version of this (requiring less time to flash) is also created, known as a “sparse” file: “bootloader/system.img”. You could flash either the raw or sparse file and it would expand properly in the rootfs of the Jetson during flash. As mentioned, the only thing different on this image versus the content of “rootfs/” is the “rootfs/boot/” content (which depends on options given to flash.sh during flash).
Manipulating the sparse image is a problem since it isn’t compatible with open source tools, but the raw image is 100% customizable (and if you desire you could then make a sparse version of this with “mksparse” using NULL fill pattern as the option).
Lets say you were to encrypt a partition. You might run a command against a partition, e.g., if your host has “/dev/sda” for its own content, and an extra disk sits on “/dev/sdb”, then a command to format or otherwise sdb is exactly the same as the commands to do the same to a blank file’s loopback device (you’d need to set up the loopback coverage).
As an example, if you have a “Linux_for_Tegra/bootloader/system.img.raw” from a previous flash, then try this:
sudo mount -o loop system.img.raw /mnt
df -H -T /mnt
# If you have used cd to go into "/mnt" you need to exit that directory tree for umount to work:
sudo umount /mnt
If you’ve performed some sort of encryption, and need a special mount command, then those options would be available on the loopback device as well. That same content will be a bit-for-bit exact copy to the Jetson rootfs if:
- You have copied your image to "bootloader/system.img".
- sudo ./flash.sh -r jetson-tx2 mmcblk0p1
This doesn’t mean it’ll boot. Embedded systems do not have a BIOS, and thus no GRUB bootloader. Adapting to encryption is not easy. However, if you were to only encrypt directories not used for boot, then having this on the system.img would magically “just be there” after boot. Once again though, if you don’t have the user space tools or kernel features installed, then it still won’t work.
Btw, JetPack doesn’t control the kernel. All it is doing is downloading a default sample configuration. You can easily work with a kernel without ever using JetPack. There are some cases where the kernel is actually in a partition, and then you need flash to add this (though you don’t have to flash everything), but most of the time it is just a copy of the “/boot/Image” file or a module somewhere in “/lib/modules/$(uname -r)/”.
The official documentation has information on kernel customization, and this is probably what you should start with. Perhaps you will want to try a clone, and then restore the clone to convince yourself the process works (just don’t restore a clone from one release onto a system with another release). See:
However, I must warn you that clone has some variations depending on the release you are using. If you have questions you’ll want to start a new thread and name the specific hardware (e.g., TX2 devel carrier kit versus an aftermarket carrier), and the version of JetPack/SDK Manager (and in reality the L4T version from “head -n 1 /etc/nv_tegra_release” on the TX2…JetPack doesn’t flash to the Jetson, only L4T flashes…JetPack is on the host PC, but each JetPack version uses only one L4T version).
When you are at a point where you know more specifics you can ask questions, but probably others will need to answer questions specific to the encryption.