FYI, that copies only the root file system. There is a lot more going on for boot in other partitions which remain on eMMC. The URL was written from the days of R24.2.1, which is very old and some of the arrangement of partitions and use of extlinux.conf has changed since then. Basically the non-rootfs partitions depend on a matching non-rootfs partition layout, and so if you go to flash or restore, then the driver package needs to be from the same release that your SD card is from.
So a first question is this: Which release is this from? See “head -n 1 /etc/nv_tegra_release”. What follows is in general, but may require adjusting for different releases.
One of the edits that URL talks about is extlinux.conf (in “/boot” or “/boot/extlinux”). The edit there to change from “mmcblk0p1” (eMMC) to “mmcblk1p1” (SD) would need to be reverted back to “mmcblk0p1” for any copy which lives in the eMMC. There are a couple of variations on how this works, but I mention this because your SD card probably has a “/boot” directory, and within that an extlinux.conf. Should your method of copy restore from that extlinux.conf, then this is the edit which would tell the system where the rootfs is to be found…SD card or eMMC.
During flash one can tell the Jetson to look for configuration (note I did not say the operating system) on eMMC or on SD. If a command line flash specified “sudo ./flash.sh jetson-tx2 mmcblk0p1”, then configuration is found on eMMC. If instead the command line specified “sudo ./flash.sh jetson-tx2 mmcblk1p1”, then the Jetson looks for configuration on SD. Whichever has the extlinux.conf is the extlinux.conf that is used during boot. If you still have an eMMC rootfs and it just isn’t used, and if your SD card extlinux.conf is the config, then changing it from “mmcblk1p1” to “mmcblk0p1” on SD would cause it to boot to eMMC (config would be found on SD, and then SD would point to eMMC for rootfs).
If the flash was told to look for configuration on eMMC, then reverting the eMMC copy of extlinux.conf to mmcblk0p1 (by a number of possibilities) would restore eMMC. If flash was told to look for configuration on SD, then flash must again be performed and told to look for config on eMMC.
This is complicated by the fact that U-Boot can also do some macro lookup, and that the macros can be edited and saved. It might be that the macros sometimes change what is found.
It is a lot of trouble to use the non-flash methods to restore if you are making guesses. Probably the best method is to command line flash with your SD card rootfs content replacing the sample rootfs. During that flash the “/boot” content would be edited to set up for eMMC, and other than that boot content, the resulting rootfs would be from your SD and all of the surrounding environment would default back to eMMC.
What release are you using in the SD? Then look for the driver package here:
https://developer.nvidia.com/embedded/linux-tegra-archive
Go to the release applicable to you, e.g., perhaps it is R28.2. Download the driver package, unpack this as your regular user. Find the “Linux_for_Tegra/rootfs/” subdirectory. Normally the next step would be to unpack the sample rootfs there, and then “sudo ./apply_binaries.sh” from the “Linux_for_Tegra/” directory. Your rootfs already has the apply_binaries.sh content, but it doesn’t hurt to add it again if you want to (this would be a disaster if you applied binaries from the wrong release…the correct release depends on those files being present). You can either mount the SD card root file system directly on the “rootfs/” subdirectory, or you can recursively copy it in. If you copy, then you must do this with sudo and you must use the correct options to copy all permissions and symbolic links and device special files without modification.
If you were to instead try to run with JetPack, then there is risk your “rootfs/” would get overwritten.
If you were using a clone, then this would be an exact bit-for-bit copy of the partition, but rootfs content is used to create a new image of the correct size. Clones would require restoring to a system that had the same rootfs size. This method lets you set size so long as the size is large enough for the rootfs and small enough to not exceed eMMC. Clones can be resized, but that’s an extra complication. The following would take your copied rootfs content, add boot edits (you will still want to change the extlinux.conf to make sure it is “mmcblk0p1”), and create a new “bootloader/system.img” for a rootfs of 28GB:
sudo ./flash.sh -S 28GiB jetson-tx2 mmcblk0p1
# Or if you wish to log:
sudo ./flash.sh -S 28GiB jetson-tx2 mmcblk0p1 2>&1 | tee log_flash.txt
(and of course the micro-B USB must be connected and the TX2 must be in recovery mode)
If you wish to use eMMC of a different release then you should probably just save a copy of anything important and skip all of that and just flash. Some exceptions are if you are using a bug release driver package to your current release (though you might find the bugs are not fixed). Example: R28.2 can be mixed with R28.2.1. Probably R28.3 can be used with R28.2 or R28.2.1, but I’m not sure.