The process is the same for both the Jetson TX1 and the Jetson TX2. Refer to the video for specifics.
The process is simple. Install a SSD on a Jetson (make sure the Jetson is powered down). Note: The physical installation is not shown in the video, the first part of this video is an example. Flash the Jetson with JetPack. Format the new SSD disk, setup a partition (it should show up as /dev/sda1). Then simply copy the contents of the eMMC over to the disk, and modify the /boot/extlinux/extlinux.conf file accordingly, so that the root directory points at /dev/sda1. After rebooting the machine, the SSD is now the root directory. There should be plenty of room for developing applications.
If your module only has emmc but no QSPI flash memory, then that emmc is crucial as all the bootloaders are on it. (All TX2 series do not have QSPI memory)
After modifying the /boot/extlinux/extlinux.conf, will the eMMC become root drive again when the SSD is not present?
Yes, that is possible. But I would suggest you dump the serial console log when deal with such issue.
Serial console log will tell the bootloader log while no other interface would dump such log.
The article says(Develop on SSD), “copy the contents of the eMMC over to the disk…”. Does it mean to copy everything including all the partitions from eMMC to the SSD?
FYI, Jetsons don’t have a BIOS. If they did, then they’d (A) consume more power, (B) cost more, and (C) be physically larger. This means there are partitions containing the equivalent of the BIOS in them in software. This also means the method a BIOS uses to find a boot partition don’t apply. In an eMMC model all of that content must be on the eMMC, and on SD card models, that content is in QSPI memory (which is on the module itself). When you fully flash you are simultaneously flashing:
Equivalent of BIOS.
Bootloader.
Operating system.
During the flash the specifications of the flash cause that content to “point” to boot content. It is true that the bootloader software might search for other boot devices, but the initial pointer to boot content cannot be on external media.
What about the swap partition? I don’t think it is a part of “Equivalent of BIOS.”
By the way, I read an article about boot sequence(actually root directory sequence) of Jetson tx2/tx1, the order is SD card, eMMC, USB/SATA. Is this correct?
Swap partitions are normally ignored during boot regardless of whether or not there is a BIOS. I think by default you’re more likely to see a swap file which doesn’t enable until Linux is running (this is flexible). Swap partitions, when they exist, are not part of boot content, and so this could be on external media or eMMC (you wouldn’t have access to that for QSPI). If a swap file is on rootfs,
Note: Bootloaders and boot content always uses physical addresses. Swapping is virtual. Thus until Linux itself is running, and the memory controller is set up for virtual addressing, there is no possibility that a swap file or swap partition will matter.
I don’t know what the current sequence is for TX2/1, but it is useful to know that early on U-Boot was in the later part of the boot stages, but as the software evolved, CBoot had U-Boot functionality merged into it; as that occurred, U-Boot was removed. CBoot (and U-Boot when it existed) would never be on any external media. Once CBoot is fully loaded (or U-Boot in earlier software) USB drivers would load. The sequence of searching for content will depend on environment variable setup in CBoot (or U-Boot on earlier software). That content would in turn only succeed in finding media it has drivers for (and thus USB devices could be found; but then there might be an issue of if a filesystem driver is available, e.g., an external USB drive with ext4 I think could be found, but if it had another filesystem type, it wouldn’t be found).
I’d agree with what @Honey_Patouceul mentions. FYI, a swap file is a file “pretending” to be a swap partition. It avoids needing an actual partition.
Swap would not need a script, it has methods that are simple and standard. Actual rootfs picking isn’t possible on that generation, at least not without more knowledge than I have. The newer hardware (Xavier, Orin) supports redundant partitions, but this is not independent in the usual way, e.g., you wouldn’t be booting Ubuntu and Fedora (it’d be an automatic rescue of the same partition).
I followed the video from JetsonHacks to setup a sata SSD as boot drive last night. It is pretty straightforward but I only finished the first part (the SSD is set to root drive) but failing to build the kernel due to the differences between jetpack versions.