After the test program runs successfully, can the tx2 BSP do factory reset?
I’m not quite understand what’s your request.
could you share more details or please give an example about what’s your expectation.
Assuming the factory has a final image of the burn, they burn it on tx2 first time and need to install some test tools.
After all functional tests have been passed, they need to restore the tx2 as same as the image but not burn it.(Use simple method to clear any redundant data)
since you need to install some test tools for testing, I think flashing entire eMMC is the most reliable way to ensure your product with a “pure” image.
may I know what’s your expectation about NOT burning the final image after QA validation?
We had some product, it use a fast method reset to the pure image, so we can speed up the producing.
Thank for your answer and have a good day!
You can clone an image which has what you want for a final image, and you can clone an image for what you consider a test environment. Then simply flash the clone back onto the Jetson for whichever case you desire. Instructions for clone change slightly depending on release, but in general:
Beware that if you are in a factory you may want to assure that the clone does not contain specific settings, e.g., a static IP address might get cloned as well. Passwords and user accounts get cloned.
Thank for your answer.
Is there any way to restore directly on tx2? I mean do not operate on a computer.
You can restore directly only if you are running on alternate media. For example, if you have a copy of the entire eMMC content in binary format, and you’ve booted to SD card, then you could use dd to copy.
- If you are using the same release of rootfs image which was used to flash the Jetson originally, then you only need to install the rootfs.
- If you use a rootfs from a release other than the one currently flashed on the Jetson, then you need to install the entire eMMC, not just the rootfs. Don't mix and match the hidden and other partitions from a version not matching the intended rootfs.
- You can't write a partition for installation if the partition is mounted.
- If you mess up the write to the other partitions which are separate from rootfs, and then the system crashes or you reboot, you won't be able to recover without an actual flash. The rootfs is used during run, and to some slight extent at boot...the other partitions are used only during boot.
- Sometimes you can use backup/restore of rootfs via rsync or similar tools, but a running and mounted file system is a problem since it is changing as you write it.
EDIT: One more note for writing a prebuilt rootfs partition:
- The rootfs partition (and any other partition, but rootfs is the only case you would normally see) needs to be the same size as the prior partition.
- The flash.sh option "-S 29318MiB" implies rootfs is exactly "29318*1024*1024 = 30742151168" bytes.
- The flash.sh option "-S 28GiB" implies rootfs is exactly "28*1024*1024*1024 = 30064771072" bytes.
From the size of an image you can find the required “-S” option to used when you use flash.sh to restore the rootfs.
I got it!
Thank you, have a nice day!
Added a note to the prior post on finding the size of the rootfs partition (mmcblk0p1 of eMMC) to consider.