Flash TX2 with SD card

I have been running Jetson TX2 on SD card for sometime. I want to do this because I can easily port the entire system from one TX2 Developer Kit board to another TX2 Developer Kit board without spending time to setup each TX2 board.

I followed the instruction here to make my SD card: Run Jetson TX1 from SD Card - JetsonHacks Basically, it copied the entire eMMC to SD card.

Currently, I felt running TX2 on SD card seemed slower that running on eMMC. So I would like to flash the TX2 board with the content on my SD card, basically, copy everything on my SD card to eMMC.

Anyone know how to do this?

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:

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.

Thank you for your post. I was running jetpack 3.1. Due to some reasons, I do not want to upgrade to a newer version.

Is the following statement correct?

“Running TX2 on SD card seemed slower that running on eMMC”

Hi AutoCar,

Yes , Your statement is correct. Onboard eMMC read/write speeds and throughput performances are high compared to SD Cards.But You can opt for high speed SD Cards(UHS 1) to achieve better performance.

Does the UHS1 SD card have the same speed ad eMMC?

Hi @linuxdev

I am not exactly sure from your post what I need to do. Do the mean the I should follow the procedure below?

Option 1:

On jetson tx2 with SD card inserted, run

sudo ./flash.sh -S 28GiB jetson-tx2 mmcblk0p1

Option 2:

  1. Remove the SD card from Jetson tx2 and insert it to another linux computer
  2. The linux computer has a program “flash.sh”, which is from jetpack.
  3. Connect Jetson Tx2 mini USB port to the linux computer USB port with cable. Setup Jetson to recover mode
  4. On linux computer, run
sudo ./flash.sh -S 28GiB jetson-tx2 mmcblk0p1

Hi AutoCar,

In jetson TX2, eMMC have better performance compared to SD UHS-1 interface.The theoretical speed of eMMC is 400 Mbytes/Sec and SD card UHS-1 is 104MBytes/Second which is less compared to eMMC transfer speed.

This will completely install to the eMMC (do not install the SD card):

sudo ./flash.sh -S 28GiB jetson-tx2 mmcblk<b>0</b>p1

In the above it is possible (after the flash is done) to make alterations to mount the root file system on an alternate SD card if desired. There are a number of ways to do this, e.g., through edit of extlinux.conf or via U-Boot environment variables. I believe by default if a valid rootfs is visible on SD card via U-Boot (which searches for partitions), then probably the SD will become rootfs (and conversely removing the SD will result in booting to eMMC).

Note that if you flash to mmcblk0p1, then you have some options. If you instead flash to mmcblk1p1, then the unit will never boot without a correct SD card being present.

@linuxdev, I still do not understand your post. Seems you were saying my option 1 is correct. However, If I do not insert the SD card, how can I flush the content on my SD card to tx2 eMMC?

Flash does not flash to the SD card when it is present during flash. What it does is install content which points to the SD card and you should expect to create the SD card content yourself. The extlinux.conf of the SD would be the first thing searched for during boot if “mmcblk1p1” is used. You don’t want initial configuration searched for on SD unless configuration on eMMC is missing. It is trivial for eMMC to name the SD card for rootfs or for the SD to name eMMC as rootfs (or for SD to name itself as rootfs).

By flashing without the SD card you install content on eMMC. Part of that content tells boot procedure to look for boot related files on the eMMC. This may sound counter-intuitive, but this is what you want due to how the rootfs is searched for. Always keep in mind that there is a difference between where boot configuration looks and where the rootfs is…it is only coincidence and convenience that default install points to eMMC for configuration (unless U-Boot macros find an SD card with boot environment) and also runs rootfs on eMMC.

Important distinction: The corollary where config points to an SD card and then first checks for eMMC content for alternate boot does not occur and is a one-way street.

Do you want to be able to boot without the SD card present? If so, then you must install boot configuration to the eMMC. After this you can put in the SD card which is set up with a rootfs (the SD would also need “/boot” content, e.g., extlinux.conf and Image…just copy from eMMC “/boot” and edit extlinux.conf). If the SD card is set up correctly, then the SD content will be detected and used during boot. If no SD boot environment is detected, then no such detection succeeds and boot will instead go to eMMC.

In the case of your SD card “/boot” content being used make sure the default boot entry within this version of extlinux.conf has “rootfs=/dev/mmcblk1p1” instead of “mmcblk0p1”. If U-Boot macros find this extlinux.conf on SD, then this entry will be used instead of eMMC and this entry points to the SD card. Remove the card, and it reverts to the eMMC entry which still points to “mmcblk0p1”.

The result will be the ability to boot to eMMC if no SD is present, or to have the SD take over if it is present with boot environment and rootfs during boot.

Tip: On the eMMC root file system add a file in “/” which is empty:

sudo touch /this_is_emmc.txt

On the SD root file system add a file in “/” which is empty:

sudo touch /this_is_sd.txt

You could name the SD card as the source of configuration during boot instead of eMMC. The result is that the unit will never boot unless the SD card has the boot environment.

@linuxdev, I think I did not make myself clear.

Currently, I have a SD card inserted in the TX2 and everything is on the SD card. I boot/run my program from the SD card. It is like the eMMC does not exist.

Now, I want to get rid of the SD card. I want to copy everything from the SD card to the eMMC. So I can remove the SD card, and boot/run the TX2 from eMMC.

To achieve that, I just want to know how to copy everything, (root, OS, my program) from SD card to eMMC.

Yes, so leave out the SD and flash normally because flash is required to get config to point at eMMC. Currently the flash demands an SD card for configuration.

Here is something which will make your life easier for this process. You don’t need to use the sample rootfs. Beware that if you mount your SD card on loopback directly replacing the “Linux_for_Tegra/rootfs/” content, then the boot entries will be modified…your SD would not be entirely preserved. However, if instead of loopback mounting the SD card you either recursively (preserving permissions and special files) copy the SD into the “rootfs/”, then the image created will be flashed based on your SD card.

Example on host…assumes host sees SD partition as “mmcblk1p1”, but adjust:

sudo -s
mount /dev/mmcblk1p1 /mnt
cd /where/ever/it/is/Linux_for_Tegra/rootfs
rm -Rf *
cp -adpR /mnt/* .
cd boot/extlinux
# <b>Edit extlinux "rootfs=" to be "rootfs=/dev/mmcblk0p1".</b>...perhaps not needed since flash
# will replace this anyway, but it illustrates.
# cd back to "Linux_for_Tegra/" from "rootfs/boot/extlinux/":
cd ../../..
umount /mnt
# Put Jetson in recovery without SD insert. Verify lsusb sees the TX2.
lsusb -d 0955:7c18
# Do not use apply_binaries.sh...although it wouldn't hurt, you already have this
# content in the clone.
./flash.sh jetson-tx2 mmcblk0p1

Your Jetson will now be running a duplicate of the SD, but booting from eMMC. Most likely if you insert the SD, then this will be the one booted due to U-Boot macros.

@linuxdev. This is clear. I will test. One question, for the new jetson-tx2 board, does it have to have the same jetpack as the SD card installed?

Yes. The version of the non-rootfs content is designed to work with a particular rootfs. Mixing versions will often cause boot failure.

Some exceptions exist where there is a simple patch release (e.g., R28.2 and R28.2.1 are interchangeable…probably also interchangeable with R28.3).

@linuxdev Your last post about “copy the SD into the rootfs on host” and then flash TX2 from host worked perfectly. Thanks a lot.

I have made a driver (i.e changed to kernel and device tree) and I need to send a working image to a client who also has a Jetson TX2. I need to make a bootable SD card, but I find conflicting information. Can someone who has successfully solved the problem please define the steps. From what I understand the uboot will be on the emmc but the dts, kernel and rootfs can be on the sd card. Is that right. Also a change is required in the extlinux.conf. I tried but it did not work. Please help.

My question is how to make a bootable SD card ?

@linuxdev now I have a different problem. The micro USB port on TX2 was broken. I could not link the TX2 to host PC through microUSB. Can I use a cable link the USB port on TX2 dev kit to host PC USB and then flash the same way?

Unfortunately no. In recovery mode the Jetson is a custom USB device, and that port is the only port capable of device mode. The OTG port can accept either type-A cable or a type-B cable. The other ports only accept a type-A cable, and to become a device, this must be type-B.

If you have a second carrier board, then you could use another carrier board for flash. Although you must customize the device tree for different carrier boards to boot normally there is no such restriction during the flash. Any carrier board should be able to flash for the dev kit board, and the dev kit board could be used when flashing a customized BSP for other carriers…the Jetson just won’t boot properly unless it is on the board for which the BSP applies.

NOTE: If you were really good with soldering, and if the carrier is not damaged, then you could direct wire a type-B connector (after cutting it off) to the carrier. This is extremely hard to imagine it succeeding though considering the trace width and spacing.

I mistakingly delete some python3 files in my Jetson TX2 device. I do not know how to flash it again(It seems it is not possible).
But I have an SD Card which I can run from that SD card. Is there any way that I can replace all bin, boot, dev,… from the available ones on my SD card?