Skip to content

Flashing the Jetson Dev Kit

Jump to bottom Edit New page
Dan Walkes edited this page Mar 27, 2021 · 32 revisions

This total-beginner's guide will walk you through the process of flashing a newly-generated image your Jetson development kit! This is supported on all of the Jetson development kits -- TK1, TX1, TX2, Nano, AGX Xavier, and Xavier NX.

Note: Starting with L4T R32.5.0, the NVIDIA flashing tools expect the dtc command to be on your PATH for some of the Jetson platforms. Install the package that supplies this command (on Ubuntu, device-tree-compiler) before flashing your Jetson.

  • If you're using a branch based off an older version of L4T (anything older than L4T R32.3.1), you'll need to generate your image with some extra settings. Add the following lines to the local.conf in your build directory:

      IMAGE_CLASSES += "image_types_tegra"               
  IMAGE_FSTYPES = "tegraflash"

    If you're using a branch based of L4T R32.3.1 or later, those settings are included in the machine configuration files, so no modification to your local.conf file is required.

    This will generate an additional flashing script along with the image that we'll use to program the bootloader, rootfs, and other necessary artifacts to the Jetson's on-board eMMC (or boot flash and SDcard, for Nano SKU 0000). While you're generating the image with these new settings, feel free to continue on to the next step (or go get a soda or something).

  • Bitbake should have now made a new zip file or compressed tar archive (depending on which branch/version youare building) called <image-type>-${MACHINE}.tegraflash.zip or <image-type>-${MACHINE}.tegraflash.tar.gz in the image output directory (tmp/deploy/images/${MACHINE}). Extract this to somewhere else that's convenient. The package includes copies of the necessary tools for flashing the device, as well as the image and bootloader files that will be put there. NOTE that some users have reported problems using graphical file management tools to unpack the tegraflash.tar.gz files, resulting in unreadable rootfs partitions, so you should use command-line tar.

    • The tegraflash unzip and deploy step can be optionally automated with a script like the one at this link.

  • (Pre-L4T R32.3.1) For the Jetson Nano development kit (module SKU 0000 with QSPI flash and SDcard), you will also need the SDcard image: <image-type>-${MACHINE}.sdcard. Copy that image onto an SDcard directly from you development machine with dd if=<image-name> of=/dev/<sdcard-device> bs=1M conv=fsync. You may need to use sudo for this. The default SDcard image size is 16GiB, so this could take a few minutes. Once done, properly eject the SDcard from your host and insert it into the slot on the underside of the Nano module.

  • (L4T R32.3.1 and later) For the Jetson Nano development kit (module SKU 0000 with QSPI flash and SDcard), you should insert an SDcard into your device before flashing.

  • Now, make sure the board is plugged in and powered on before continuing.

  • Plug a micro-USB cable into the board's USB0 port and connect it to your host machine. For Jetson Xavier AGX development kits, use the USB-C connector on the board.

  • On your board, while holding the recovery button (REC), press reset (RST) to boot into recovery mode. You'll see the lights briefly flash off and on. You may need to hold the REC button down for at least three seconds after releasing RST to have the device fully switch to recovery mode.

    • For the Nano carrier board, unless you have connected buttons to the header pins, use a jumper (FRC to GND) to put the device into recovery mode when the device is powered on. The location of the FRC pin varies based on the version of carrier board in use. See this link for details. For carrier board revision A02, these are pins 3 and 4 of J40, which is located near the camera header. For carrier board revision B01, these are pins 9 and 10 of J50, which is located on the edge of the carrier board under the Jetson module.
    • For the Xavier NX carrier board, unless you have connected buttons to the header pins, use a jumper (REC to GND) to put the device into recovery mode when the device is powered on. See this link for details. For carrier board revision A01 these are pins 9 and 10 on J14. See picture below: xavier nx reset pins

  • Now, simply sudo ./doflash.sh, wait for it to do its thing, and voila! The script will cold-reboot the Jetson, and you've got a hot new image flashed!

    • Note: Depending on your python configuration, you may need to modify the second line of doflash.sh from something like tegraflash.py --bl cboot.bin... to python tegraflash.py --bl cboot.bin...
    • The tegraflash unzip and deploy step can be optionally automated with a script like the one at this link.

  • (L4T R32.3.1 and later) For the Jetson Nano development kit with module SKU 0000 (MACHINE jetson-nano-qspi-sd), the tegraflash package also includes a dosdcard.sh script that you can use to format an SDcard image or write to an SDcard inserted into a card reader/writer on you host system directly. However, you should flash the device via USB at least once (with the SDcard inserted) to ensure that the QSPI flash has been updated with the current bootloader.

Flashing without root access

To avoid having to use sudo or be root to program the Jetson flash, add some udev rules to put the USB interface into a group that you belong to. The script at this link can be used to automate this task.

For example:

# Jetson TK1
SUBSYSTEMS=="usb", ATTRS{idVendor}=="0955", ATTRS{idProduct}=="7140", GROUP="plugdev"
# Jetson TX1
SUBSYSTEMS=="usb", ATTRS{idVendor}=="0955", ATTRS{idProduct}=="7721", GROUP="plugdev"
# Jetson TX2
SUBSYSTEMS=="usb", ATTRS{idVendor}=="0955", ATTRS{idProduct}=="7c18", GROUP="plugdev"
# Jetson TX2i
SUBSYSTEMS=="usb", ATTRS{idVendor}=="0955", ATTRS{idProduct}=="7018", GROUP="plugdev"
# Jetson TX2-4GB
SUBSYSTEMS=="usb", ATTRS{idVendor}=="0955", ATTRS{idProduct}=="7418", GROUP="plugdev"
# Jetson AGX Xavier
SUBSYSTEMS=="usb", ATTRS{idVendor}=="0955", ATTRS{idProduct}=="7019", GROUP="plugdev"
# Jetson Xavier NX
SUBSYSTEMS=="usb", ATTRS{idVendor}=="0955", ATTRS{idProduct}=="7e19", GROUP="plugdev"
# Jetson Nano
SUBSYSTEMS=="usb", ATTRS{idVendor}=="0955", ATTRS{idProduct}=="7f21", GROUP="plugdev"

Add these rules to a file under /etc/udev/rules.d on your development host, then reboot or restart udev (or systemd-udevd) to have them take effect.

Issues during flashing

If you run sudo ./doflash.sh and flashing is started but then it hang in some step like:

[   1.7586 ] Flashing the device
[   1.7611 ] tegradevflash --pt flash.xml.bin --storageinfo storage_info.bin --create
[   1.7636 ] Cboot version 00.01.0000
[   1.7659 ] Writing partition GPT with gpt.bin
[   1.7666 ] [................................................] 100%
[   1.7707 ] Writing partition PT with flash.xml.bin
[  15.9892 ] [................................................] 100%
[  15.9937 ] Writing partition NVC with nvtboot.bin.encrypt
[  16.2433 ] [................................................] 100%
[  16.2569 ] Writing partition NVC_R with nvtboot.bin.encrypt
[  26.2706 ] [................................................] 100%
[  26.2877 ] Writing partition VER_b with jetson-nano-qspi-sd_bootblob_ver.txt
[  36.3103 ] [................................................] 100%
[  36.3202 ] Writing partition VER with jetson-nano-qspi-sd_bootblob_ver.txt
[  36.5833 ] [................................................] 100%
[  36.5927 ] Writing partition APP with test-image.ext4.img
[  36.8548 ] [................................................] 100%

or if e.g following:

[   1.9394 ] 00000007: Written less bytes than expected
[  21.7219 ] 
Error: Return value 7
Command tegradevflash --pt flash.xml.bin --storageinfo storage_info.bin --create

It's good to connect serial console which in above case will print something like:

[0020.161] device_write_gpt: Erasing boot device spiflash0
[0039.824] Erasing Storage Device
[0039.827] Writing protective mbr
[0039.833] Error in command_complete 18003 int_status
[0039.840] Error in command_complete 18003 int_status
[0039.847] Error in command_complete 18003 int_status
[0039.852] sending the command failed 0xffffffec in sdmmc_send_command at 109
[0039.859] switch command send failed 0xffffffec in sdmmc_send_switch_command at 470
[0039.866] switch cmd send failed 0xffffffec in sdmmc_select_access_region at 1301
[0039.876] Error in command_complete 18001 int_status
[0039.883] Error in command_complete 18001 int_status
[0039.890] Error in command_complete 18001 int_status
[0039.895] sending the command failed 0xffffffec in sdmmc_send_command at 109
[0039.902] setting block length failed 0xffffffec in sdmmc_block_io at 945
[0039.909] block I/O failed 0xffffffec in sdmmc_io at 1215
[0039.914] block write failed 0xffffffec in sdmmc_bdev_write_block at 178
[0039.921] device_write_gpt: failed to write protective mbr
[0039.926] Number of bytes written -20
[0039.930] Written less bytes than expected with error 0x7
[0039.935] Write command failed for GPT partition

Things to try:

  • ! USB cable must be plugged directly to PC host (don't use USB hub otherwise issues like described above will appear) !
  • verify USB cable quality (try to use another one)
  • power off/on device and try flashing again
Add a custom footer
Add a custom sidebar
Clone this wiki locally