SdkManager: unable to flash TX2 (Error: Return value 3 / Command tegradevflash_v2 --pt flash.xml.bin --create)

SdkManager version: 1.1.0-6343

Following the thread ‘How to enable KVM on Jetson TX2 board?’,
Specifically, following the instructions from

sudo dd if=/boot/modified tegra186−quill−p3310−1000−c03−00−base.dtb of=/dev/mmcblk0p15

This rendered boot failure, and is unable to flash back via SdkManager, the error message is
Error: Return value 3
Command tegradevflash_v2 --pt flash.xml.bin --create

Also tried L4T (R32.4.2), with the command ‘sudo ./ -k EBT jetson-tx2 mmcblk0p1’
The error message is “”"
Error: Return value 13
Command tegrarcm_v2 --download blob blob.bin
Failed to flash/read t186ref.

And errors from the serial port “”"
[0498.165] E> BCT size mismatch
[0498.168] E> Verification failed for 1 copy of br bct @ 0
[0498.175] E> BCT size mismatch
[0498.178] E> Verification failed for 2 copy of br bct @ 32
[0498.184] E> BCT size mismatch
[0498.187] E> Verification failed for 3 copy of br bct @ 64

[0498.769] E> Failed to verify block
[0498.773] E> Failed to load and verify header
[0498.777] E> Failed to load binary(0)
[0498.781] C> ERROR: Highest Layer Module = 0x40, Lowest Layer Module = 0x40,
Aux Info = 0x0, Reason = 0xd
[0498.790] E> Failed to load bootrom bct
[0498.794] E> (2010000d): Failed to fetch load address

Why do you want to flash EBT partition? This partition does not exist on TX2.

Thanks for the reply.

Then, I misunderstood the meaning of (L4T)

./ -k EBT <target_board> mmcblk1p1 - update <target_board> bootloader

Didn’t know the meaning, just a blindless try.

So, my problem is unable to “flash-back” TX2 via sdkManager…

If you don’t know what to do, just try the full flash.

sudo ./ <target_board> mmcblk0p1

After full flash, it stalled in “the pxe try-boot loop”

I tried:

  • “$bootcmd” <=== pxe boot-loop
  • “$bootcmd_mmc0” <=== returned, no effect
  • “$bootcmd_mmc1” <=== returned, no effect

Any idea?

BTW, The detailed error messages from sdkmanager:


Please share a more clear statment.

After full flash, it stalled in “the pxe try-boot loop”

So does the flash successfully finished? Could you share the serial console log and log from directly?
Honestly, It does not provide much help to see the log from sdkmanager.

About ./ jetson-tx2 mmcblk0p1

  • Flash successfully finished
[  17.6501 ] Flashing completed

[  17.6502 ] Coldbooting the device
[  17.6528 ] tegradevflash_v2 --reboot coldboot
[  17.6555 ] Bootloader version 01.00.0000
[  17.8079 ]
*** The target t186ref has been flashed successfully. ***
Reset the board to boot from internal eMMC.
  • Output from serial port
U-Boot 2016.07-g45dfa3dff4 (Apr 08 2020 - 18:06:40 -0700)

Model: NVIDIA P2771-0000-500
DRAM:  7.8 GiB
MC:   Tegra SD/MMC: 0, Tegra SD/MMC: 1
*** Warning - bad CRC, using default environment

In:    serial
Out:   serial
Err:   serial
Net:   eth0: ethernet@2490000
Hit any key to stop autoboot:  0 
MMC: no card present
switch to partitions #0, OK
mmc0(part 0) is current device
Scanning mmc 0:1...
starting USB...
No controllers found
USB is stopped. Please issue 'usb start' first.
starting USB...
No controllers found
ethernet@2490000 Waiting for PHY auto negotiation to complete...... done
BOOTP broadcast 1
BOOTP broadcast 2
*** Unhandled DHCP Option in OFFER/ACK: 43
*** Unhandled DHCP Option in OFFER/ACK: 43
DHCP client bound to address (273 ms)
Using ethernet@2490000 device
TFTP from server; our IP address is; sending through gateway
Filename '\boot\x86\'.
Load address: 0x80280000
Loading: T

It will then repeat trying to load from tftp…


I guess the setup on host is not correct. Please show us the result of Linux_for_Tegra/rootfs.
Did you use Linux_for_Tegra from sdkmanager or you download it as a tarball directly?

Download tarball directly:

md5sum Tegra186_Linux_R32.4.2_aarch64.tbz2

BTW, I tried sdkmanager again, with serial port connected to catch some detailed message.
And this time, it finished flash and rendered a bootable TX2.
So my problem is solved (though why it works this time is still unknown)

The difference is “re-try button” will rebuild OS-image, and after this rebuild, it works.

FYI, before this successful flush (via sdkmanager),

  • I tried sdkmanager at least 5 times
  • I also tried the “re-try button” 2 or more times
  • All failed

Thanks anyway~

Ok. In case you want to know why there was an error from the tarball.

I guess the reason is that you forgot to download the rootfs sample to your Linux_for_Tegra/rootfs as well.

Ok, didn’t notice it, thanks~