Does someone has experience with an standardized process to setup jetson modules for serial production.
The Setup includes:
- OS
- System setting (e.g. network configuration)
- configurations
- some libs
- own software (is updated continuously)
Thank you
Hi,
Thanks for your question.
We are checking this internally and will update more information with you later.
Thanks.
Not an answer, but some comments which might be useful to you.
You should always have a spare unit which is for testing. That unit can become a reference for cloning, and updates should probably be done and tested (especially “sha1sum -c /etc/nv_tegra_release”) prior to using the clone.
You should check for any MAC address dependency in “/etc/apt/” subdirectories. udev may save a MAC address which needs editing.
Keep in mind that accounts and passwords are also cloned. It may not be a bad idea to have a standardized account name/pass in the beginning, but then you must make sure the system changes passwords later or is protected.
Clone comes in two varieties from a single clone operation: (1) A “raw” file which is a bit-for-bit exact clone, and (2) a “sparse” file, which is smaller, and flashes faster. A raw file can be turned into a sparse file with “mksparse” (NULL fill pattern). A raw file can be loopback mounted, edited, or examined. A sparse file is set in stone (open source tools won’t work with it…one needs to use flash to a recovery mode Jetson to expand it). Never throw away your raw image even though it is large. Be very careful to have a saved copy which won’t get overwritten.
When cloned a valid raw clone size should be checked. The size should be evenly divisible either twice or three times by 1024. The raw clone should be loopback mountable.
You can place a clone (either raw or sparse) in “bootloader/system.img”, and the flash will succeed if you use the “-r” option to “flash.sh”. If you fail to use “-r” you will destroy the image.
A loopback mounted clone can be updated via rsync. A system can be updated via rsync from a loopback mounted clone.
“flash.sh”, without “-r”, will build a new image from the content in the “rootfs/” subdirectory. Some “rootfs/boot/” content will update, but other content which is not associated with boot will be an exact copy. You can replace the usual “rootfs/” software (which is the Ubuntu sample rootfs plus the apply_binaries.sh step NVIDIA drivers) with a loopback mounted clone. The clone’s “/boot” content will change depending on flash.sh parameters and target board, but will otherwise be an image based on the clone.
Never mix a clone from one release with another. Non-rootfs content and rootfs content have dependencies. There may be some exceptions from patches, e.g., an R28.3 clone can be used with an R28.3.1 flash.sh (which wouldn’t make a lot of sense, but might), and an R28.3.1 clone can be used on R28.3 (however, I wouldn’t advise either of these). Using R28.2 with R28.3 will flat out break, but not necessarily in a way you’ll notice right away.
The “-S size” parameter to flash.sh reserves a rootfs size. If you are using a clone which is the default size, then you’ll never need to use “-S”. However, if the rootfs size differs from the clone (the raw size), then you’ll need to adjust. If the raw image is divisible twice by 1024, then that is the size in “MiB”; if divisible three times by 1024, then that is the size in “GiB”. For example, 15,032,385,536 bytes will be “-S 14GiB”, and 15,288,238,080 bytes will be “-S 14580MiB”.
You can resize a loopback mounted (read-only mode) clone using the usual tools, e.g., gparted (making sure you preserve the filesystem). If the base file is larger than what you are reducing to, then it is easy to reduce to that, and then use “trunc” to trim the excess. If the file needs to be larger, then you have some thought ahead and need to loopback mount the original image, followed by appending space without breaking loopback; followed by the usual tools to expand the filesystem. All expansions or contractions in size should be even multiples of either 10241024, or of 10241024*1024.
Sometimes revisions in modules or carrier boards trip people up. You might want to keep a log of the revision of module/carrier and what is flashed to it before shipping out.
@AastaLL did you meanwhile have some informations? Thanks