Unable to flash TK1 Board

I’m trying to reflash my TK1 board using the instructions provided by Nvidia (http://developer.download.nvidia.com/embedded/jetson/TK1/docs/2_GetStart/Jeston_TK1_User_Guide.pdf).

When I try to flash it, however, I get the following error.

sudo ./flash.sh -S 14GiB jetson-tk1 mmcblk0p1


sending file: tegra124-jetson_tk1-pm375-000-c00-00.dtb

  • 59637/59637 bytes sent
    tegra124-jetson_tk1-pm375-000-c00-00.dtb sent successfully
    odm data: 0x6009c000
    downloading bootloader – load address: 0x83d88000 entry point: 0x83d88000
    sending file: fastboot.bin
  • 594363/594363 bytes sent
    fastboot.bin sent successfully
    waiting for bootloader to initialize
    usb read error (71): Protocol error
    bootloader failed NvError 0x0
    command failure/warning: bootloader download failed
    Failed flashing ardbeg.

The reason I’m trying to flash it is because it fails to power on for more than a second. It was working for about 2 weeks prior to this.

I’m using Ubuntu 14.04 LTS and packages from R21.4.

Unrelated side note: You will get max use of eMMC if you change the “-S 14GiB” to “-S 14580MiB”.

It sounds like the unit is correctly in recovery mode, but something else is going on. For your Ubuntu 14.04 host, is this a standard x86_64 desktop install? Is there anything “unusual” about it, e.g., a virtual install instead of standard desktop?

Also, on the host, from where you are running flash.sh, how much available disk space is there? You can cd to that directory, then:

df -H .

The reason for wondering about this is that since fastboot.bin downloaded correctly (this is used internally even when end result is adding u-boot), then I have to believe that USB is “likely” working correctly, even if there is a USB error…that perhaps the error is related to data itself (such as not having access…flashboot.bin worked, but this file is only the start of data transfer).

Thanks for the help.

The host is a standalone 64bit Ubuntu install.

in ~/Linux_for_Tegra/ “df -H .” returns:

Filesystem                                              Size  Used Avail Use% Mounted on
/dev/disk/by-uuid/073b92d1-713f-4dd0-b1b0-a17d6b55d2a1   31G   13G   17G  44% /

Depending on which files already exist, there is a strong possibility disk space is the only issue.

During flash a loopback mountable file of the same size as the new root partition is created…in your case size 15,032,385,536 bytes (14GiB implies 14 * 1024 * 1024 * 1024). That file in turn is used to create a “sparse” file…something like a compressed version…at around 7 or 8 GB. The original loopback mountable file is the “raw” image, the compressed file is the “sparse” image. Sparse images exist to reduce time to flash, but also implies more host side disk use. Once the sparse image is created the raw image can be deleted…but both must exist for a period of time.

Does your flash directory contain file “bootloader/system.img”? What size is this? Mine is highly customized and so does not compress nearly as much as a stock sample rootfs; my sparse file is 12GB. If this file exists, you might have enough space…but then again, the file might be truncated, and you won’t know until flash fails. If the file does not exist, then there is no possibility of flash succeeding until more disk space is made available. With all of the temporary file requrements, I’d suggest having 30GB of free space to flash (an amount which is probably always going to succeed). You can safely remove “bootloader/system.img” prior to determining how much space you have (as well as any system.img.raw).

The bootloader folder contains system.img. The file size is 2.4 GB. Upon deleting system.img and system.img.raw I have about 19 GB of available space. I’ll try allocating more space and try the flash again.

That’s definitely the issue…30GB free space should be plenty, 24GB would be near the edge of success or failure.

I allocated more space this time (33 GB available) and still received the same error.

./nvflash  --bct PM375_Hynix_2GB_H5TC4G63AFR_RDA_924MHz.cfg --setbct --configfile flash.cfg  --create --bl fastboot.bin --odmdata 0x6009C000 --go
Nvflash 4.13.0000 started
BR_CID: 0x340010017410b10220000000130681c0
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: 0x000000017410b10220000000130681c0
   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
- 59637/59637 bytes sent
tegra124-jetson_tk1-pm375-000-c00-00.dtb sent successfully
odm data: 0x6009c000
downloading bootloader -- load address: 0x83d88000 entry point: 0x83d88000
sending file: fastboot.bin
- 594363/594363 bytes sent
fastboot.bin sent successfully
waiting for bootloader to initialize
usb read error (71): Protocol error
bootloader failed NvError 0x0
command failure/warning: bootloader download failed 
Failed flashing ardbeg.

Something to note is that when the flash fails, the board powers itself off. I’m not sure if this is supposed to happen, but I’m noting it because the board hasn’t been able to stay on during a normal boot. I’m wondering if this has to something to do with the board itself, or if it still might be a problem with how I’m trying to flash it. Thank you very much for the help.

Once again, it succeeds in setting up the initial state of the Jetson in preparation for other data. It seems that USB works. Notice that the usb read error and the bootloader failed error occur together…but the 0x0 bootloader NvError implies success. I think the smaller files are successful and probably so is USB. A side effect of when an error occurs sure makes it seem like USB is at fault, nothing would have sent correctly if USB were truly the issue.

Now that you finished a flash attempt, with temporary files still in place, how much is left on the disk (df -H)? What is the size of “bootloader/system.img” and “bootloader/system.img.raw”? Keep in mind that when I suggest 30GB extra, this implies at least that much space beyond everything else already installed…I’ve seen 30GB allocations which actually turned out to include operating system space, and thus it wasn’t really 30GB of free space.

However, if you have a system.img.raw, this can be tested via loopback mounting. This file should have an exactly predictable size as well (divide by 1024 until you reach exactly the size of the “-S” parameter…this should be an exact match). Should this file be correct, and if you have a sparse system.img variant, then there could actually be a Jetson issue (but USB will not be the issue, it’ll be something else which just happens to show up under USB). It could even be the host side software has an issue which could be fixed by re-downloading and installing the host-side software first.

Before the flash, df -H . returns

Filesystem                                              Size  Used Avail Use% Mounted on
/dev/disk/by-uuid/4087a49d-ea93-460b-9492-63fc68902112   43G  7.9G   33G  20% /

Then after attempting to flash, df -H . returns

/dev/disk/by-uuid/4087a49d-ea93-460b-9492-63fc68902112   43G   13G   28G  32% /
  • System.img.raws returns a size of 15,288,238,080 bytes, which after dividing by 1024 twice I get the original -S size of 14580. The system.img file is 2.4 GB.
  • I’ll try allocating as much space as I can on the next flash.
  • I have re-downloaded the the software and have still received the same error.

Can you loopback mount system.img.raw? Example:

sudo mount -o loop path/to/system.img.raw /mnt
cd /mnt
ls

The size of the system.img (sparse file) may also be correct when there is no customizing. At this point it looks like intermediate files are correctly generated. The “mount” test is to verify if loopback and raw image steps are working.

If loopback succeeds there may be other issues internal to the Jetson. At least you’ll know the data source used by USB was correct.

I ran the commands and ls into /mnt directory. Is there anything I need to test to verify that the loopback succeeded?

adam@xps:/mnt$ ls
bin   dev  home  lost+found  mnt  proc        root  sbin  sys  usr
boot  etc  lib   media       opt  README.txt  run   srv   tmp  var

What this indicates is that loopback succeeded during the flash process, as the image would not be loopback mountable if host-side flash had failed (the same loopback is used to populate the image during flash). At this point you also know that your base system has enough hard drive space to not worry about truncated data (it is possible for the raw image to succeed but have insufficient room to create the sparse image…under your original disk space this was an issue, but not now).

Prior messages also show that the device is correctly in recovery mode, and that the USB cable is correct…the initial fastboot download could not succeed as far as it got without this. You’ve also re-installed flash software, so you know it isn’t a corrupted file issue. My thoughts are that the data source on host is good, and that USB reports error because of failing memory it is trying to write to (USB wouldn’t know if it failed because of itself or because of destination). When beginning the actual image download, the address of the physical memory changes to where the partition is to be located…I believe that location is probably defective.

It may be time for RMA. If you go here, a short distance down is the RMA procedure:
https://devtalk.nvidia.com/default/topic/793798/embedded-systems/some-jetson-web-links/

I was worried it might be. Thank you very much for your help.