Booting L4T 28.1 from SD on boards containing different L4T versions on EMMC


I am struggling to get two Jetson TX1 boards to boot from the same SD card. The situation is as follows:

We have two TX1 boards (both with the CTi Astro Carrier + Breakout), one on my desk and one in a robot. The one on my desk has L4T 24.2.1 on it’s EMMC, the one in the robot has 28.1. We want to be able to boot 28.1 from the same SD card on both of them so i can develop on my desk and just take the SD card over when i’m ready. The EMMC-contents of the one with L4T 24.2.1 should be left untouched.

I know that there were several changes in the U-Boot and in general boot configuration between these versions. However there should still be a way to make it work, right?
My steps until now, guided by tutorials and several forum topics, were as follows:

  1. Cloned rootfs from the 28.1 EMMC to the SD
  2. Modified extlinux.conf on the SD, duplicating the default entry and changing it to root=mmcblk1p1. After this step I was able to boot the board with 28.1 from SD, but not the one with 24.2.1.
  3. To be able to boot it on the 24.2.1 board the following steps worked for me:
    • Copied initrd from EMMC to SD
    • Copied the Parameters in the "APPEND" line of extlinux.conf from the EMMC to the SD (replacing the "${cbootargs}".
    • Also copied the FDT-line of extlinux.conf from EMMC to SD.

So currently I am able to boot from SD on the 24.2.1 board. If I want to boot on the 28.1 board I have to comment out the FDT-line, and for the 24.2.1 I have to put it back in.

Does anyone know how I can have both boards booting from the SD-card, without needing to change anything in any files when I want to switch the board? I can imagine my problems are caused by the different versions of U-Boot on both boards. Is it possible to load the bootloader from SD or something like that?

There are many hidden partitions beyond the root partition. The scheme for those files and the boot environment is drastically different between R28.1 and previous releases. This is the first release which unifies TX1 and TX2 installation. This release also transitions from a 3.x kernel series to a 4.x kernel series. Device tree setup is far different as well. Basically, you can clone and preserve your rootfs, but you are unlikely to get both to boot off the same SD card…maybe you will, but not likely…and if you do make it work, it won’t be easy or quick.

If you can preserve your non-boot part of the environment, are you ok with making both modules R28.1? You can preserve everything except boot environment and then use a single SD card between the two modules…but you have to first be at the same L4T release version.

Thanks for your reply!
The problem is that we have some software running on R24.2.1, and I don’t know what parts of the system it depends on. I’m hesitating to update it (“never change a running system”).

So your suggestion is to update the L4T release version but keep all software installed by JetPack and by the user. Could that break anything?

The steps I guess would be to backup the whole EMMC, put a fresh L4T on it (only the L4T, without the libraries, APIs and all that), and then copy stuff back over from the backup?

Probably the first thing to do is become comfortable with being able to update and not lose anything. You should clone your rootfs before doing anything. Should you have a clone of rootfs where L4T was R24.2.1, and then flash again with the “-r” (reuse system.img) option, then you have restored everything. Should you flash again under R28.1 with “-r” using a clone of a rootfs which was under R28.1, then you once more know you’ll have a working system. Simply flash with “-r” using an L4T which was used during the original install of that L4T version.

Information on cloning differs between hardware and between software release, but the ideas on the TK1 are still valid for all of the releases. For some information on the clone topic see:

For commands specific to a TX1 under R24.2.1, see:

Under L4T R28.1 the “Documentation” download has cloning command information:

The gist is that a clone is an exact copy of the same thing which the generated as “bootloader/system.img.raw”. Flash is via “bootloader/system.img”…without the “-r” option to this “.img” file is generated based on the rootfs directory. If you place an uncompressed system.img.raw (or clone) under the name “bootloader/system.img” (and using “-r” option), then flash will work… does not care if the image is the sparse/compressed version, nor if it is the uncompressed raw version. It just takes longer with a larger raw image for “bootloader/system.img”.

Sadly, both flash and clone with raw images take a lot of time and disk space. You can mount your first clone on loopback on a host and then do rsync backups to the loopback mounted clone for fast incremental updates.

So getting back to your question, more or less “yes, flash to the proper version, then try to install software with the package manager and/or JetPack”. If it breaks, use the loopback mounted clone to explore why. It’ll eventually be a losing battle if you have part of your software running on R24.2.1 and part on R28.1.

Something which might be useful would be to describe your software (such as what known interfaces there are, e.g., a particular CUDA version or OpenCV, TensorRT, particular camera drivers, so on), and see if anyone can predict a situation ahead of time for what might happen when migrating from R24.2.1 to R28.1.

Thanks a lot! I did a backup and will try to set everything up on R28.1 now. I will come back when I hit any problems.