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.
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.
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.
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).
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.