Is there another way to flash TX2 module?


Currently, the only way I know to flash the TX2 module is to put it in recovery mode then run the script to flash L4T via USB recovery port. Is there another way? Can it be done via UART or Ethernet?


There is no other way. In theory a JTAG debugger could directly write eMMC, but I do not believe there are currently any JTAG debuggers which work with the TX2.

You might want to describe what ordinary flash limitations you are trying to work around…what is the specific use case which causes you to want to avoid ordinary flash?

Hi linuxdev,

We will develop our own board for the TX2 and we have decided to leave out the micro USB recovery port.

Why not just flash it using the development board and then reconnect it to your board? You only need to flash once and can make kernel/driver updates without a reflash.

If you just intend to flash a few modules, maybe you can use a nvidia dev board with its micro-usb port and PC host for flashing the TX2 modules with modified device tree before plugging it into your own board.
However, you’d better keep a serial console available on your board for setting this up.

I’d have to agree with the other posts…flash from a developer carrier board. The TX2 is actually a lot more complicated than most embedded products and trying to adapt to flashing with methods not already supported would probably be expensive and painful. Even if you are thinking of a special use case of having techs flash in the field, and if there were a JTAG debugger, you’d probably end up spending close to $10k getting just a single JTAG debugger…so that would be the second question…are you thinking the flash has to be done in the field? Regardless, carrying a developer carrier board would be much simpler and cheaper than a custom solution.

We try to avoid pre-flashing the TX2 with the carrier board as it would interrupt the assembly process by a 3rd-party company. We want to also avoid post-flash as it will be difficult to remove the TX2 module from its enclosure; also the field person will need to carry both a host/laptop and the carrier board.

I am going to see if I can use gparted to partition the 30GB eMMC to 2 partitions; put L4T on both partitions and use one to flash over the other.

Thank you for all the responses.

If you only want to change the rootfs partition, then you have some extra options which don’t require flash. However, there can be problems if part of the flash is from an older generation (e.g., 27.0.1) while the rootfs is from the newer generation software (e.g., 27.1). Prior to manufacture processes, can you afford to flash to R27.1? If so, then follow-up changes without putting the Jetson in recovery mode become available without changing carrier board.

The two-partition scheme might do the job, though there might be a more interesting variation to this. Rather than putting a full install on the second partition, just put a rescue system on that partition…probably 4GB to rescue and the rest going to the live system would work…then an SD card or even network download could be used to download updates. You’d have to be sure extlinux.conf remains valid, and that a serial console is available to select rescue partition. SD, network, or some other bulk storage would kick in when in rescue mode. I guess the question there is that on a system being updated, how much control do you have? Is this going to be your company doing the work, or will it be in the hands of a third party buyer? Rescue systems may not be the best bet if using third parties that don’t understand the process.

Are you making dozens, hundreds, thousands, or millions?

If smaller rather than bigger sets, you could always take delivery yourself, pre-flash the modules, and then ship them to the assembly/fulfillment house. It adds a little work and expense, but presumably not all that bad. (Especially if you can teach the marketing intern how to do it :-)

The problem is that it will be very difficult to remove the TX2 module from its enclosure to flash on the carrier board. Even if we pre-flash it, it still needs to be updated/flashed later.

This and using scp (secure copy protocol) might solve most of my problem.

Will you have a serial console available?

When you say “flash,” do you really mean changing all the bits (boot loader, system partition table, etc) or would it be enough with the ability to update the on-disk files (kernel, drivers, software, etc)?

Applying a software update is simple, using scripts or whatever, as long as you don’t mind having to reboot afterwards, and have enough space to store the software-to-be-updated in addition to the running system.

Serial console and Ethernet port will be available.

The initial flash would be to remove U-Boot (to reduce boot time) and kernel. Subsequent flashes would be for updating the kernel and applications. Now that there is a way to update the kernel in-place that solves most of my issues. The only thing I cannot do right now is removing U-Boot without flashing.

If the device is way in the guts of things, and the reason you “have” Ethernet is that you have an onboard Ethernet network, perhaps there’s some other way to use Ethernet?
An option might be to put in a very small MCU of some sort that speaks Ethernet on one end and USB on the other, and then also write some Linux driver for the host that looks like a USB driver to the NVIDIA flash program, but speaks Ethernet to the MCU. (Might be simplest to do inside KVM virtualization.) Technically possible, but requires a fair bit of engineering to get there.

With U-Boot you never need to flash to update…and files are never locked once U-Boot reads in the kernel and starts Linux (kernel and other boot config is freely available for edit even on the running system). Having serial port available in combination with U-Boot gives you a way to safely do this using alternate test configs before finalizing; ethernet port gives you an easy way to transfer relevant files.

By removing U-Boot (I assume you will use fastboot) you lose much of the simplicity. U-Boot stores kernel and config in “/boot” and makes most of what you want to do a simple file copy. Fastboot stores this information in hidden partitions…normally the only way to service your updates under fastboot is with flash. You could use dd instead, but there are a lot of risky things going on to do this, and the work to get it set up correctly is much higher.

One issue is that for hidden partitions you cannot easily or safely change partition sizes (and changing kernel features can definitely change required partition size). You’ll notice that any binary data stored in the hidden partitions for boot purposes that typically there is a reference image, and that image is typically padded with NULL bytes on the tail end to match the partition size. Should your binary image fit within that size, and NULL bytes are able to pad to the correct size, then dd should work to update that partition. Once your partition size requirement changes, you’re basically screwed. You could first use a partition resizing program to reduce the size of the rootfs partition, and then enlarge the hidden partitions.

Also know that some of those hidden partitions work together during boot, and if you get it wrong with only serial port and ethernet available, you’ll be forced to physically remove the module and use traditional flash to get it working again (you can always test your updates on another Jetson before using the changes on a running system, but a mistake such as interrupting an update due to power blinking off will leave the Jetson unbootable).

Without U-Boot you also cannot use serial console to select a rescue or mirror install.

And as you have found out the initial removal of U-Boot does require flashing.

U-Boot itself only slows boot by about the 2 second delay given for serial console to drop into command line or to pick a custom boot config. I realize this may be a lot of time for you, but even so the time for actual boot after the kernel begins loading is probably more significant. In your situation is it possible you could instead shorten boot time by changing what programs run during initial startup? E.G., perhaps you use only text mode and the GUI could be removed, or WiFi isn’t used and WiFi detection could be skipped.

If you are developing your own carrier, why not just add a usb port for flashing to the carrier? I flashed directly to a 3rd party carrier to install.


Our product is very small and does not support external USB devices. To include USB just for flashing will add complexity and cost.