This might not matter for your case, but I’ll try to give some context.
During flash the Jetson is a custom USB device, and you are first limited by the USB connection speed. You could use something like “lsusb -tv” and find the Jetson during (or at the start while in recovery mode) and examine the speed. The end of the tree view line will show something like “5000M” (USB3.1 gen. 1) or “480M” (USB2). If it has reverted to USB2, then definitely this takes a long time.
When the rootfs of a Jetson is flashed there are two possibilities for images: Raw or sparse. In a normal flash where an image is created from default content it will first generate a raw image, and then a sparse image from the raw image. Either image can be used for flash if named system.img and in the “Linux_for_Tegra/bootloader/” directory. What you’re doing typically “reuses” an image that already exists and thus would not overwrite that image. The raw image is the exact byte size of the entire partition, whereas the sparse image is the size of the content within the partition. If the raw image is 64GB, then so too will be the raw file. As filesystem content is added, and as the content approaches a full partition, so too will the sparse image approach the size of the raw image. Image size is the main speed determinant (after USB mode) for how long this takes.
Note that when you flash to a non-default media (such as SSD), then there will always be an initial ramdisk image (initrd). This is also present in a few other scenarios. That image has to be created correctly to boot to your rootfs device. I could see the possibility that this somehow slows things down since it needs to put kernel modules from the particular media into the initrd, although normally I don’t think this would be a big time changer.
The QSPI content use changes with model. If you have a developer’s kit, then it does not have eMMC for the small form factor models. If this is a commercial module, then it has eMMC. The boot chain installation differs quite a bit depending on which model you are using, especially with regard to QSPI versus other partitions. You would need to provide exact context on whether this is the commercial module on a carrier board, versus a pure developer’s kit without eMMC.
Note that I would start by checking the size of the system.img and system.img.raw in the “Linux_for_Tegra/bootloader/” directory. If you are using a backup/restore command, then I would compare size of any image for fast case versus slow case. Perhaps it is a raw image instead of a sparse image. Perhaps it is sparse, but the filesystem is filling up and thus more data must cross the USB.
I would definitely also look at that tree view of “lsusb -tv” when the Jetson is in recovery mode on the host PC which takes a longer time. See if it is at least USB3 gen. 1 (which is still slightly slower than the 6 Gb/s of SATA3, but it is close. Of course if the SSD is on a host PC or being accessed in some manner to create its content separate from the flash process, then I’d expect a possible massive speed-up.
I can’t really say that 7 minutes is a “long time”. Under many circumstances this could be “normal”.