Hi,
system.img size is ~5GB
system.img.raw size is ~15.GB
From my understanding, the APP partition is flashed with system.img.raw when using flash.sh
is it possible to flash it with system.img and “earn the extra 10 GB”?
will the result rootFS will be identical?
Thanks
system.img.raw is the exact bit-for-bit copy of the partition to be created. system.img is a “sparse” version. Basically it doesn’t show empty partition space, but when it unpacks, it “becomes” the system.img.raw. Technically it isn’t compression, but in reality it is run length compression adapted to the filesystem. They provide the exact same content since the recovery mode Jetson knows how to uncompress the sparse image.
If you were to succeed, then what you would get is a perfect 100% filled filesystem with not a single byte left. When you flash a 5 GB sparse image to a partition which is 15 GB you get 5 GB of content and the rest is empty filesystem. It does not matter if you flash with the raw or sparse image, the result is exactly the same (except that the sparse image is smaller so it takes less time to flash).
Note that after a flash “optional” packages like CUDA are also added in. If the content exceeds the 5 GB sparse image size, then it is from those optional packages being added after flashing the base system.
Thank you @linuxdev for your reply.
A small followup question:
Can I use buildroot to create a minimal rootfs and use it? the emmc size is limited so I’m looking for as small as possible rootFS
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.
This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.