We have a custom image that we developed as part of a product design. It was created using the Cloning instructions at [url]http://elinux.org/Jetson/Cloning[/url]
Now that we are ramping up production, we are looking for a more efficient way of loading this image onto the TK1. Right now, it takes about 4 hours per board using the instructions at the above URL.
Does anyone have any suggestions for alternate methods for loading the image that would reduce the cycle time?
At that URL there is some information on differences between a “raw” image and a “sparse” image. Have you tried creating and flashing a “sparse” image based on your cloned “raw” image? FYI, as your file system clone approaches a full file system going to a sparse image will help less and less…but on an image significantly less than full a sparse image will flash much faster (this is in fact why flash code which originally flashed only raw images starting using sparse images…it saved a lot of time).
I’ve tried this, but the sparse image only gets down from 15 GB to about 12. Not enough to significantly affect our cycle time.
Having linux and its rootfs on SDCard would simplify cloning, if you don’t need its full available capacity for your application.
On the other hand, mechanical disconnect issues are more likely to happen, depending on your product…
Since the transfer is over USB2 and the eMMC itself has write speed limits I am unsure about which part is the biggest bottleneck. Knowing may not help much, but there is one thing I can think of which might work in a production environment if it turns out that the USB side is the limit…
You could create a base bootable minimal image which flashes quickly, boot up, and then use gigabit network to rsync your edits in. A 12GB update would no doubt take a lot of time, but it is conceivable that rsync (which compresses) over gigabit (probably faster than USB2) could speed things up considerably.
Note that if a base image is set up with specific ssh keys and if the base image unlocks the root account to ssh (normal login would not need to be unlocked), then rsync easily becomes a productive way of updating. The rsync itself could even disable the temporary root unlock. The procedure as a whole is not actually difficult, but there are a lot of steps I’d need to explain in detail…let me know if you want to try this. Before starting what you’d want to do is create a copy of your current clone image, cut out whatever packages you can think of to make this a good starting point (such as kernel version and dtb matching your production device, but skipping CUDA and other optional packages). We could take that starting point, set up ssh keys, set up root ssh unlock, clone this, and then set up a batch file system for rsync to copy from your final clone under loopback to the JTK1.
There is no guarantee this would actually be faster, it could be a waste of time…but I think the odds are good enough that you may find it worthwhile to at least test.
And actually there is one more similar option where you start with the fast cut down version of your clone and rsync…the Jetson itself could run rsync over a SATA connected hard drive and skip all of the ssh and gigabit connection (rsync could be perfected this way even if you intend to eventually go with gigabit). This would require a hard drive for each rsync, whereas a single rsync server over ethernet would work with a lot of TK1s updating all at the same time (an rsync server has a speed advantage when reading a single read-only file system over and over because of caching…caching and running over ethernet has the potential to be faster than a directly connected drive because access is actually from RAM after the first read).
This is actually a great idea that set me down a very good path. We’re starting from a very trim base image that flashes in only a few minutes. Sending diffs across would be way faster.
Thanks for your help!