Flashing TX2

when I flash TX2, this step takes a long time:

Making system.img…
populating rootfs from /home/tx2/nvidia/nvidia_sdk/JetPack_4.3_Linux_P3310/Linux_for_Tegra/rootfs …

What is doing in this step? Can I remove this step?

A big question is “does this step finally complete”? This is the step which actually creates a bit-for-bit exact ext4 partition image which your flashed system will use. This is the operating system.

Initially, if your partition is 28GB in size, then a 28GB file is created in “Linux_for_Tegra/bootloader/”, named “system.img”. Depending on flash arguments, some “rootfs/boot/” content is edited, and then the entire operating system is copied into the loopback mounted system.img (loopback treats the file as a partition which is first ext4 formatted). Needless to say this takes time, but the actual content will only be around two or three GB. There are some cases where this will stall, and so knowing if this is permanently stuck there or not would help.

The “system.img” is then moved to name “system.img.raw”, and from this a smaller “sparse” image is created, named once more “system.img”. This latter file is much smaller than the raw image.

If and only if you have already created the image, and if and only if you don’t need to change options, then the generation of the image can be circumvented. The image must still be there, and that image will still be used to flash with, but the generation step can be skipped.

Are you flashing multiple Jetsons without the need for a new image each time? If so, then this command line, with the “-r” option would do the job much faster without generating the image (and if the image is wrong, everything will be flashed with the wrong image):

sudo ./flash.sh -r jetson-tx2 mmcblk0p1

Note that if you have a cloned image, then this is how you can install the clone…by replacing system.img with the clone.

Hi “linuxdev”,
Thank you very much for your thorough explanation

1_ Is this true? : uImage and u-boot and dtb and filesystem all are included in system.img before flashing.
Do I need to rebuild system.img if I make a change to dtb? Also about uImage and u-boot

2_ According to the photo I have attached,It seems that “dtb” file is in two place

In flashing step, which one is updated and which one will be used by Kernel during boot?

“system.img” is purely just a partition. “uImage” is specific to certain U-Boot installs, but is not used with Jetsons. Just the ordinary “Image” is used in “/boot”. This “/boot” Image may at times appear in a partition for some setups (I have not worked with the partition Image…think of people setting up Secure Boot and preventing booting altered systems). The dtb used to be in “/boot”, and may in some ways interact if use is attempted from there (not sure), but most of the newer releases put this in a partition with signing. I think the dtb in “/boot” is just left over from the past.

Updating the dtb is a flash step now (versus a “/boot” file), but you don’t necessarily need to flash the rootfs to do this. Procedures tend to depend on release. If you are experimenting with this, then it is probably a good idea to have a clone of the rootfs handy in case something goes wrong (if you’ve worked with the dtb before and trust your flash methods, then there isn’t much reason to clone other than ordinary desire to back things up).

Note that U-Boot uses the “/boot/extlinux/extlinux.conf” file, but that parts of this are now obsolete. The reason is that U-Boot also inherits some of its parameters from earlier boot stages, and that trying to use the dtb file here (instead of the one in the partition) would collide with the inherited version (the inherited version gets edits by the earlier boot stages prior to passing on). Thus you will not see the “FDT” key/value pair in extlinux.conf, and yet you have a device tree you can examine in “/proc/device-tree/”.

I don’t remember which specific partition is used, but sometimes there is a redundancy, and depending on circumstances, the second version may or may not be used (I have not worked with the redundant boot software, but if one partition fails, then another may be used). Simply copying those partitions though may not work since the content is signed during flash.