Hello,
I’ve recently begun experimenting with executing a mass flash generated using the nvmassflashgen script. It took approximately 45min to flash four boards simultaneously using a single flashing host.
When examining the output of top, I didn’t notice any resource constraints that would present an obvious bottleneck for the speed of the flash process, so I’m wondering:
How can we improve our procedure and/or hardware selection to speed up the mass flash operation?
To provide some context:
The mass flash tarball was initially created using the -r flag, and the provided system.img was a raw system image created using the flash.sh script. The system.img file has a size of approximately 28G.
Two boards were connected to the USB3.0 ports directly on the host, and two boards were connected to USB3.0 ports exposed by a USB-C hub attached to the host.
hello harris6ctq5,
flashing time takes mostly when writing a raw system image into the APP partition.
BTW, here’s Flash Script Usage you may refer to for detailed information about flash.sh command.
this -r option will skip building system.img, and reuse the existing one for platform flashing.
may I know what’s your expectation results,
thanks
Hi @JerryChang,
Thanks for your prompt reply. Helpful information.
Is it possible to use a sparse image when generating the mass flash artifact? I should think that would speed things up significantly.
Beyond that, it sounds like the bottleneck for speed will either be bandwidth on the USB controllers or write speed on the flash targets themselves. Would that be a fair assessment? Which would you consider to be more likely?
FYI, within the “Linux_for_Tegra/bootloader/” directory you will find the mksparse utility. This utility, when using a “NULL” fill pattern, will produce a sparse image from a raw image. Example:
sudo mksparse -v --fillpattern=0 system.img.raw system.img
Just be careful to not create a sparse image that overwrites what was already there (if you value that current sparse image).
Originally only raw images were used, and to speed up flash, mksparse and use of sparse images were added. The Jetson itself can be flashed with either format and won’t care, but larger files take longer to flash. Also, you cannot loopback mount and examine a sparse image.
Note that the less “filled” your filesystem is, the more gain you will see in terms of a smaller sparse image. As the filesystem fills the size of the sparse image approaches the size of the raw image.
1 Like
@linuxdev thanks for the additional information.
I’ll try again with a sparse image sometime in the near future and let you know how that impacts performance.
I don’t recall seeing command line options for generating the mass flash artifact documented anywhere in the README for nvmassflashgen. I got sort of lucky by trying the -r option during my tests. This might be something worth including in the next patch to L4T.