Jetson TK1 - NvError 0x120002

Hello

I have recently received Jetson TK1 development board but I am having some problems with flashing it.
The flashing always fails after the line: sending file: tegra124-jetson_tk1-pm375-000-c00-00.dtb with NvError 0x120002. I have included the log below.
I have tried flashing it from 3 different machines, using 3 different Ubuntu version and I always received the same error. I have also swaped the power supply with 2 others and the problem remained. I have used an ordinary USB to Micro usb cable for smartphones and tried switching it aswell. Same error.
I have tried flashing 3 different L4T version (19.3, 21.4 and 21.5) and nothing changed. The L4T was always extracted with the exact commands from the Quick Guide on NVidia website.
I managed to get the serial output of the Jetson and I would be glad if anyone knows what my situation or error means.

Have I overlooked some crucial step?

Flashing log:

copying bctfile(/home/themarpe/Downloads/Linux_for_Tegra/bootloader/ardbeg/BCT/PM375_Hynix_2GB_H5TC4G63AFR_H5TC4G63CFR_RDA_924MHz.cfg)... done.
copying bootloader(/home/themarpe/Downloads/Linux_for_Tegra/bootloader/ardbeg/u-boot.bin)... done.
	populating kernel to rootfs... done.
	populating jetson-tk1_extlinux.conf.emmc to rootfs... done.
done.
Reusing existing system.img... 
done.
copying dtbfile(/home/themarpe/Downloads/Linux_for_Tegra/kernel/dtb/tegra124-jetson_tk1-pm375-000-c00-00.dtb)... done.
copying cfgfile(/home/themarpe/Downloads/Linux_for_Tegra/bootloader/ardbeg/cfg/gnu_linux_fastboot_emmc_full.cfg) to flash.cfg... done.
creating gpt(ppt.img)... 

*** GPT Parameters ***
Device Sector Size ------- 512
device size -------------- 15766388736
bootpart size ------------ 8388608
userpart size ------------ 15758000128
Erase Block Size --------- 2097152
FS Buffer size ----------- 4096
Partition Config file ---- flash.cfg
Visible partition flag --- GP1
Primary GPT output ------- PPT->ppt.img
Secondary GPT output ----- GPT->gpt.img
Target device name ------- none

*** PARTITION LAYOUT(20 partitions) ***
[     BCT] BH            0        16383       8.0MiB 
[     PPT] UH            0         4095       2.0MiB ppt.img
[      PT] UH         4096         8191       2.0MiB 
[     EBT] UH         8192        16383       4.0MiB u-boot.bin
[     LNX] UH        16384        49151      16.0MiB 
[     SOS] UH        49152        61439       6.0MiB 
[     NVC] UH        61440        65535       2.0MiB 
[     MPB] UH        65536        77823       6.0MiB 
[     MBP] UH        77824        90111       6.0MiB 
[     GP1] UH        90112        94207       2.0MiB 
[     APP] UV        94208     29454335   14336.0MiB system.img
[     DTB] UV     29454336     29462527       4.0MiB tegra124-jetson_tk1-pm375-000-c00-00.dtb
[     EFI] UV     29462528     29593599      64.0MiB 
[     USP] UV     29593600     29601791       4.0MiB 
[     TP1] UV     29601792     29609983       4.0MiB 
[     TP2] UV     29609984     29618175       4.0MiB 
[     TP3] UV     29618176     29626367       4.0MiB 
[     WB0] UV     29626368     29630463       2.0MiB 
[     UDA] UV     29630464     30773247     558.0MiB 
[     GPT] UH     30773248     30777343       2.0MiB gpt.img
copying flasher(/home/themarpe/Downloads/Linux_for_Tegra/bootloader/ardbeg/fastboot.bin)... done.
Existing flashapp(/home/themarpe/Downloads/Linux_for_Tegra/bootloader/nvflash) reused.
*** Flashing target device started. ***
./nvflash  --bct PM375_Hynix_2GB_H5TC4G63AFR_H5TC4G63CFR_RDA_924MHz.cfg --setbct --configfile flash.cfg  --create --bl fastboot.bin --odmdata 0x6009C000 --go
Nvflash 4.13.0000 started
BR_CID: 0x3400100174114103180000000b020240
rcm version 0X400001
Skipping BoardID read at miniloader level
System Information:
   chip name: unknown
   chip id: 0x40 major: 1 minor: 1
   chip sku: 0x0
   chip uid: 0x0000000174114103180000000b020240
   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
BCT sent successfully
sending file: tegra124-jetson_tk1-pm375-000-c00-00.dtb
data send failed NvError 0x120002
sending dtbfile failed NvError 0x0
command failure/warning: bootloader download failed (bad data)
bootloader status: BCT is invalid or corrupted or SDRAM params may be wrong (code: 12) message:  DownloadFile 1130 flags: 0

Failed flashing ardbeg.

Serial output log:

[0000.000] [TegraBoot] (version UNDEF_BUILD)
                                  
[0000.004] Reset reason: power on reset
                                       
[0000.007] Processing in recovery mode
                                        
[0000.011] Established communication link with host
                           
[0001.088] Downloaded bct successfully 
                                       
[0001.104] No Battery Present
                                                 
[0001.107] Sdram initialization is successful 
                                
[0001.172] verify checksum failed with error 0x120000 in NvTboot3pDataReceive fu
nc at 988 line 
                                                               
[0001.181] Data receive failed
                                                
[0001.183] data receive for download file failed with error 0x120000 in Download
File func at 1130 line 
                                                       
[0001.192] Downloading file failed with 0x120000 error

This error:
0x00120002, “packet was nacked”

A packet was not acknowledged…this seems to happen a lot with a VM host. Sometimes a VM can have USB settings adjusted to get around this. Is the host a native Linux install, or is it virtual? FYI, we know basic setup is correct since parts of the flash did succeed.

I have tried on one more machine this time with kubuntu 14.04 and the same error happend.

The same error shows up when using VM or native Linux install.

On both machines, VM and native, use this command to get the device number of the Jetson in recovery mode:

lsusb -d -955:7140

This will produce a “Device” number (if you change anything in the USB this number will change). For example, I have a recovery mode Jetson which is currently showing “Device 009”. Next, track it down via “lsusb -t” and find the device number. “lsusb -t” will show a tree view…the “Device” number will identify which is the Jetson, but is abbreviated “Dev”. In my case I select the specific device 9 via:

lsusb -t | egrep 'Dev 9'

Do either the VM or the native Linux machine end that lsusb tree view line with anything other than “480M”? This indicates USB2 mode…other modes won’t work.

Also, can you give a detailed description of the native Linux computer? Was this through command line flash.sh, or was it via the JetPack front end?

Both the VM and native Linux reported 480M on the lsusb -t command.

I have made fresh install of Ubuntu 16.04 in the first try and used JetPack installer. I got the same error.
After that I have made a fresh install of Ubuntu 14.04 and tried with flash.sh and same thing appeared. Also tried on Ubuntu 12.04 and nothing changed.
This was on my PC running x58 motherboard, i7 950 CPU, 6GB RAM and booting the linux OS from SSD. The Jetson was attached to native USB2.0 connector on the motherboard.

I have also tried of an live Ubuntu running from USB stick on 1 laptop and received the same error.
Then I went ahead and tried on VM and lastly on native linux from second laptop and everything remained the same.

JetPack with Ubuntu 16.04 is not supported…this may be unrelated, I know some people have had this work…it isn’t a lot different than 14.04 hosts, but I have not tried. Command line flash won’t care about which Linux distribution is used, but the flash stage you mention is essentially JetPack calling the command line, so this too is unlikely to matter.

What I am curious about is if you had any issue getting JetPack to run on an Ubuntu 16.04 host? It’s just something that has to be looked at.

Note that a USB stick will only work if it was formatted to a native Linux file system type, e.g., ext3 or ext4. Default USB stick type uses VFAT, and is guaranteed to cause problems (not necessarily during installer stage, but the booted Jetson flashed from VFAT will fail).

Does the flash always fail in exactly the same place? Changing where it fails at tends to point to USB, changing in one place tends to point at host or Jetson. What follows may help in the case of failing at the same place by narrowing host or Jetson end.

One possible host side issue is if the image being sent does not exist, or perhaps permissions stopped reading. Consideration of whether the image is truncated would also need consideration; I don’t see any of the image being sent at all, but I’ve seen only one log post. In the installer directory you will see directory “Linux_for_Tegra”. Within that how much disk space is there, and of what type? Run “df -H -T /wherever/installed/Linux_for_Tegra/”. Additionally, what is the exact byte size of “Linux_for_Tegra/bootloader/system.img.raw”? Use “ls -l system.img.raw” (this will be approximately 15GB in size).

I haven’t had any issues with JetPack on Ubuntu 16.04 only a warning in the beggining that this OS is not supported and the error in flashing. I didn’t proceed from this point on so I don’t know if the rest of the JetPack installation would fail or no.

I am currently testing from 2 machines, 1 running VM Ubuntu 14.04 and another running kubuntu 14.04 from 64GB USB but fully installed (like a bootable hard drive, formated as ext4) for another point of view of problem for testing purposes.

The error shown in host log is always the same, but I have done the serial log only on the machine running the VM.

This was the command df -H -T executed in Linux_for_Tegra folder on machine running Ubuntu from USB

Filesystem     Type      Size  Used Avail Use% Mounted on
udev           devtmpfs  2,0G  4,1k  2,0G   1% /dev
tmpfs          tmpfs     400M  1,4M  399M   1% /run
/dev/sdb1      ext4       57G   14G   41G  25% /
none           tmpfs     4,1k     0  4,1k   0% /sys/fs/cgroup
none           tmpfs     5,3M     0  5,3M   0% /run/lock
none           tmpfs     2,0G   82k  2,0G   1% /run/shm
none           tmpfs     105M   21k  105M   1% /run/user

And this is output of the command ls -l system.img.raw from the same machine

-rw-r--r-- 1 root root 15032385536 jan 31 10:25 system.img.raw

I will post the outputs of the same commands on the VM machine in a couple of minutes

The posted disk space and system.img.raw size look correct. My gut feeling at this point is that the software being installed is corrupt…here’s why…

The packet NAK is rarely an issue with the Jetson hardware if some portion of the download succeeded, and some of it did. This line could mean a hardware issue, but in many cases the issue has been elsewhere (sometimes as a result of a bad download):

bootloader status: BCT is invalid or corrupted or SDRAM params may be wrong (code: 12) message:  DownloadFile 1130 flags: 0

I’d hate to tell you to RMA the board if it was just a download. To be certain here’s what I’d suggest:

First, completely delete your JetPack installer on the host. Download it and try again.

If this fails, delete this and download just the command line flash to simplify requirements (this is the driver package plus sample rootfs…you can later use JetPack to install other packages without flashing again if desired):
https://developer.nvidia.com/linux-tegra-r215

To flash by command line, here is a recipe:

tar xjfv Tegra124_Linux_R21.5.0_armhf.tbz2
cd Linux_for_Tegra/rootfs
sudo tar xjfp /whereever/samplerootfs/is/Tegra_Linux_Sample-Root-Filesystem_R21.5.0_armhf.tbz2
cd ..
sudo ./apply_binaries.sh
# Place JTK1 in recovery mode with micro-B USB cable.
# Verify it is found on the host:
lsusb -d 0955:7140
# Verify you have approximately 25GB or more space available as ext4:
df -H -T .
# Actual flash with sudo.
sudo ./flash.sh -S 14580MiB jetson-tk1 mmcblk0p1

You can log the flash by modifying that last command:

sudo ./flash.sh -S 14580MiB jetson-tk1 mmcblk0p1 2>&1 | tee flash_log.txt

…if you log and it succeeds beware that one of the progress bar indicators ends up being one very long line for just that line. Typically you could view a log like this:

less -r flash_log.txt

After you’ve flashed verify the file system was not filled up and truncated with another “df -H”.

Okey I have redownloaded the driver package and the root file system, execute the given commands exactly and ended up with the same error.

Looks like my board probably has some sort of a hardware issue and I will try to get it replaced.

Thank you very much linuxdev for your time and assistance in examination of my problem, I greatly appreciate it.

RMA information is near the top of this:
https://devtalk.nvidia.com/default/topic/793798/embedded-systems/some-jetson-web-links/