Flashing Jetson TK1, getting failed executing command 26 NvError 0x120002" / nverror:0x4

Hello everyone,

I’ve been trying to flash a Jetson TK1 with no success.

I’ve tried flashing using Jetpack and flashing L4T manually, but both return the same error.
I tried a VM and a 64-bit Ubuntu 14.04 clean installation. After system.img and gpt.img are sent to the board, I receive the following error:

Create, format and download took 4069 Secs
failed executing command 26 NvError 0x120002
command failure/warning: sync failed (bad data)
bootloader status: partition table is invalid, missing required information (code: 14) message: nverror:0x4 (0x4) Sync 5485 flags: 0

Failed flashing ardbeg.

Here’s the full flash_os_tk1.log file: Jetson TK1 flash - flash_os_tk1.log - Pastebin.com

I’ve tried running the flash.sh script using “-S 8GiB”, “-S 14580MiB”, etc., all of them with similar results. I’ve tried several times to flash it, and it always fail in a similar fashion…

I’m starting to think it may be hardware-related, but I’d like to hear (read) a second opinion. I’ve searched in the forums, and haven’t seen a solution for nverror:0x4.

Thanks in advance!
José

Hi jarrate,

Which JetPack version are you install?
Please follow JetPack install guild steps (from: jepack_docs/index.html/Download and Install JetPack L4T)

Reference: https://devtalk.nvidia.com/default/topic/930976

FYI:

0x00120002, "packet was nacked")

This is a communications error from USB. This is from the VM. The USB is failing. I don’t know how to tune or adjust USB on a VM, but if you do, try adding buffer and be sure the port is set to USB2, not USB3.

Thanks for the answers carolyuu and linuxdev!

I’m trying to install JetPack 3.0, with L4T 21.5.

I have another TK1, so I tried flashing it using an Ubuntu VM and the same USB cable and port I was using for the other TK1 board.

The process ran smoothly, so unfortunately, this could be evidence that the original board is a faulty one … One thing I noticed is that the transfer was much quicker, from 4000 seconds on the “broken” board, to ~1500 on the one that flashed correctly.

Is there an alternative way to flash other than using the micro USB connection (SD card, USB, SATA)?
Also, in case the eMMC is the faulty component, could I ran L4T exclusively from the SD card / USB port?

Again, thanks for your help.
José

I wouldn’t toss that TK1 out yet…USB over a VM, when it does work, may be at the edge of failing. If this is the case then USB tolerance to noise might just be a bit different on the failing flash. If your VM can see the recovery mode Jetson via this from the host it means USB is not dead on the Jetson:

lsusb -d 0955:7140

…this also is consistent with getting faster transfer rates because of retries and being able to get partially in to a flash. This has been the case with all of the VM failures showing packet was NAKd. I would find it hard to believe the Jetson is bad based on current issues…it could be, but a VM is terrible with its history of flash issues. I would consider evidence of hardware failure only after flashing on command line from a non-VM x86_64 Linux.

Micro-USB is the only method of flash. There are things you could do with just the root partition, but a flash deals with a lot of hidden partitions as well.

During flash you can tell the system to look for the boot loader on the SD card, but I am uncertain if some of the hidden partitions remain on eMMC…parts of eMMC could go bad and if already booted it would continue working…perhaps flashing boot configuration to SD card would have a partial immunity to eMMC failure. Whether or not you can flash to SD card while eMMC is already bad I don’t know.

I forgot to add that yesterday I switched to

  • A clean Ubuntu 14.04 installation (real, not VM)
  • New Rampow USB cables instead of the ones provided with the TK1.
  • Different USB ports on my laptop (USB2 / USB3, high-power/normal ports)

The flash times and errors were the same as before.

When I start the board on recovery mode, I always see it listed on lsusb. I understand that there’s some communication between the board and the host, since the partition info and some files are transferred.

I’ll investigate about the SD card possibilities and get back with the results (hopefully, good news).
As you said, there may be eMMC regions that aren’t working as expected and that may be avoided if I move as much as possible to the SD card.

José

There is a way to test eMMC if it is an outright failure. You can clone it and check at which byte offset it fails…then repeat. If it fails at the same spot each time, then you have a hardware failure. If it fails differently each time, then you probably have a communications (USB) error.

Unfortunately, cloning takes a long time (perhaps hours if it succeeds). The hidden partitions are not very large, almost all of the time for cloning is from the root partition (the “APP” partition). The TK1 clone has target “ALL” which will clone the entire eMMC as a contiguous set of bytes (it’s the whole disk, not one partition). You’ll need to have a bit more than 16GB of free space on your host, and then be sure to measure the exact size of the clone file when it fails. Also note from the clone command line echoes any log messages about the last byte read or any notes on failure. Here is the info on TK1 cloning:
[url]http://elinux.org/Jetson/Cloning[/url]

Be sure to reset the Jetson into recovery mode for every command issued. If you try to clone twice without resetting the board it won’t work.

Unfortunately, I don’t have very good news … I couldn’t event start transferring from the board.

The board is connected in recovery mode:

~/Downloads/TK1/Linux_for_Tegra_tk1/bootloader$ lsusb -d 0955:7140
Bus 001 Device 002: ID 0955:7140 NVidia Corp.

I reset the board on recovery mode on each test cycle.
Both the VM and a real Ubuntu host returned the same results…

Try to get the list of partitions failed with error “bootloader status: Bct file not found (code: 21) message: nverror:0x10 (0x10)”:

~/Downloads/TK1/Linux_for_Tegra_tk1/bootloader$ sudo ./nvflash --getpartitiontable table --bl ardbeg/fastboot.bin --go
[sudo] password for ubuntu: 
Nvflash 4.13.0000 started
BR_CID: 0x34001001741141021c000000150285c0
rcm version 0X400001
System Information:
   chip name: unknown
   chip id: 0x40 major: 1 minor: 1
   chip sku: 0x0
   chip uid: 0x00000001741141021c000000150285c0
   macrovision: disabled
   hdcp: disabled
   jtag: disabled
   sbk burned: false
   board id: 0
   warranty fuse: 0
   dk burned: false
   boot device: emmc
   operating mode: 3
   device config strap: 0
   device config fuse: 0
   sdram config strap: 0

RCM communication completed
downloading bootloader -- load address: 0x83d88000 entry point: 0x83d88000
download command failed NvError 0x120002
command failure/warning: bootloader download failed (bad data)
bootloader status: Bct file not found (code: 21) message: nverror:0x10 (0x10) DownloadBootloader 864 flags: 0

Trying to read the APP partition failed with the same error:

~/Downloads/TK1/Linux_for_Tegra_tk1/bootloader$ sudo ./nvflash --read APP /media/sf_2Tb/TK1/system.img --bl ardbeg/fastboot.bin --go
Nvflash 4.13.0000 started
BR_CID: 0x34001001741141021c000000150285c0
rcm version 0X400001
System Information:
   chip name: unknown
   chip id: 0x40 major: 1 minor: 1
   chip sku: 0x0
   chip uid: 0x00000001741141021c000000150285c0
   macrovision: disabled
   hdcp: disabled
   jtag: disabled
   sbk burned: false
   board id: 0
   warranty fuse: 0
   dk burned: false
   boot device: emmc
   operating mode: 3
   device config strap: 0
   device config fuse: 0
   sdram config strap: 0

RCM communication completed
downloading bootloader -- load address: 0x83d88000 entry point: 0x83d88000
download command failed NvError 0x120002
command failure/warning: bootloader download failed (bad data)
bootloader status: Bct file not found (code: 21) message: nverror:0x10 (0x10) DownloadBootloader 864 flags: 0

Same escenario if trying to retrieve the whole flash:

~/Downloads/TK1/Linux_for_Tegra_tk1/bootloader$ sudo ./nvflash --rawdeviceread 0 3849216 /media/sf_2Tb/TK1/all.img --bl ardbeg/fastboot.bin --go
Nvflash 4.13.0000 started
BR_CID: 0x34001001741141021c000000150285c0
rcm version 0X400001
System Information:
   chip name: unknown
   chip id: 0x40 major: 1 minor: 1
   chip sku: 0x0
   chip uid: 0x00000001741141021c000000150285c0
   macrovision: disabled
   hdcp: disabled
   jtag: disabled
   sbk burned: false
   board id: 0
   warranty fuse: 0
   dk burned: false
   boot device: emmc
   operating mode: 3
   device config strap: 0
   device config fuse: 0
   sdram config strap: 0

RCM communication completed
downloading bootloader -- load address: 0x83d88000 entry point: 0x83d88000
download command failed NvError 0x120002
command failure/warning: bootloader download failed (bad data)
bootloader status: Bct file not found (code: 21) message: nverror:0x10 (0x10) DownloadBootloader 864 flags: 0

Then, I inspected ~/Downloads/TK1/Linux_for_Tegra_tk1/bootloader/flash.cfg to obtain the partition id of system.img (in my case, 12) but failed when trying to retrieve the partition with the following command:

sudo ./nvflash --read 9 system.img --bl fastboot.bin --go

When it says “downloading bootloader” it is referring to software necessary to put the Jetson in a useful mode…think of it as a mini-operating system with almost no functionality. The fact that this is happening immediately and from real+VM hosts does make me believe you now have solid reason to return for RMA. The only thing I can think of to further test is if you delete and reinstall the flash software and try clone again…there is a small possibility that the binary image which was being downloaded was inaccessible, but the packet NAK error would likely change if this were the case. It’s probably time to RMA.

Look for the RMA procedure near the top of this URL:
[url]https://devtalk.nvidia.com/default/topic/793798/embedded-systems/some-jetson-web-links/[/url]

I ran a full download from the board that works to the VM, and after 5h30m, it finished successfully.

So I think you’re right linuxdev, RMA is the way to go…

Thanks for your support!

sudo ./nvflash --rawdeviceread 0 3849216 /media/sf_2Tb/TK1/all.img --bl ardbeg/fastboot.bin --go
[sudo] password for ubuntu: 
ubuntu@ubuntu14-vm:~$ cd Downloads/
3.1.20928902-linux-x64-public/         host-x64-linux-public-3.7.224-e982b7b/ jetpack_docs/                          TK1/                                   VisionWorksDocs/
GameWorksOpenGLSamples/                _installer/                            jetpack_download/                      tmp/                                   
ubuntu@ubuntu14-vm:~$ cd Downloads/TK1/Linux_for_Tegra_tk1/bootloader/
ubuntu@ubuntu14-vm:~/Downloads/TK1/Linux_for_Tegra_tk1/bootloader$ sudo ./nvflash --rawdeviceread 0 3849216 /media/sf_2Tb/TK1/all.img --bl ardbeg/fastboot.bin --go
[sudo] password for ubuntu: 
Nvflash 4.13.0000 started
BR_CID: 0x3400100174114103180000000a030240
rcm version 0X400001
System Information:
   chip name: unknown
   chip id: 0x40 major: 1 minor: 1
   chip sku: 0x0
   chip uid: 0x0000000174114103180000000a030240
   macrovision: disabled
   hdcp: disabled
   jtag: disabled
   sbk burned: false
   board id: 0
   warranty fuse: 0
   dk burned: false
   boot device: emmc
   operating mode: 3
   device config strap: 0
   device config fuse: 0
   sdram config strap: 0

RCM communication completed
downloading bootloader -- load address: 0x83d88000 entry point: 0x83d88000
sending file: ardbeg/fastboot.bin
- 594363/594363 bytes sent
ardbeg/fastboot.bin sent successfully
waiting for bootloader to initialize
bootloader downloaded successfully
Bytes to receive 15766388736
Receiving file: /media/sf_2Tb/TK1/all.img, expected size: 15766388736 bytes
/ 15766388736/15766388736 bytes received
file received successfully
Time taken for flashing 19641 Secs

Out of warranty, out of luck.
Now I have a new expensive paperweight…