You can easily use a custom rootfs, but only if it has what is needed. Some explanation of boot content follows…
Jetsons do not have a BIOS. Thus the equivalent of what a BIOS does is flashed into partitions used during boot (flashing a Jetson is equivalent to flashing both the CMOS BIOS and the bootloader and the operating system simultaneously if comparing to a PC). On a dev kit (which uses an SD card), only the rootfs is on the SD card, while the rest of the content goes into the QSPI memory (on an eMMC model this content shows up in eMMC partitions). Flashing the SD card itself can be done separately without the Jetson connected to the PC.
Normally (on the PC side) the flash software has content in the “
Linux_for_Tegra/rootfs/” directory which is nearly an exact copy of what goes into the rootfs. I say “nearly” because arguments passed to the flash software will pick some content to put into the “
Linux_for_Tegra/boot/” directory. Typically that would be device tree, kernel, and an
extlinux.conf adjusted for your flash. Otherwise, when the final flash image is generated, this content is a 100% exact match to what gets flashed.
If you put your content in “
rootfs/”, and that content is not part of “
/boot”, then you get exactly what you want. An image is generated and this becomes “
Linux_for_Tegra/bootloader/system.img.raw” (then a sparse image is created from that named “
system.img”; flash software can flash raw or sparse, but a sparse image takes less time to flash).
Flash software for the SD card is similar. Note that the
system.img.raw could be applied directly to either the right eMMC partition or the SD card partition and it would work as is.
You can also clone the rootfs or the original SD card partition, and put this in the place of “
bootloader/system.img”, and tell flash to “reuse” the existing image instead of creating a new one. This would become your rootfs. Had you cloned from a system in which you’ve set up accounts, networking, and customized packages (e.g., removed things you don’t want), and then put that in place of the
system.img before flash, you’d get your system.
An example would be that a factory with eMMC models might have a reference system which has updated packages and customizations. That could be cloned, and each future flashed unit would have that rootfs.
Alternatively, one could mount a clone over the “
Linux_for_Tegra/rootfs/” directory and temporarily replace the sample rootfs with your clone. This would be used if generating an image from scratch. Be warned though that this will edit the “
/boot” content. Should the
extlinux.conf and kernel and device tree content be a match to what flash would add, then this is the same as just using your clone as an exact match to what gets flashed.
You will never have any benefit (other than speed of flash) by using the
system.img.raw instead of the
system.img. The content and partition specifications are exact matches between the two.
Often users will add some sort of external storage, e.g., via an m.2 device.