Jetson TK1 Bootloader Fails

A while ago my Jetson TK1 froze and wouldn’t turn off, so I had to pull the plug on the power. After that, it wouldn’t boot up again, so I decided to try flashing it, but every time I try to flash it the terminal outputs the following error.

"RCM communication completed
BCT sent successfully
odm data: 0x6009c000
downloading bootloader – load address: 0x80108000 entry point: 0x80108000
sending file: fastboot.bin
data send failed NvError 0x120002
command failure/warning: bootloader download failed (bad data)
bootloader status: BCT is invalid or corrupted or SDRAM params may be wrong (code: 12) message: DownloadBootloader 1118 flags: 0

Failed flashing ardbeg."

I’ve flashed it before in the same manner without ever having this error.
Has anyone else had this problem? Is there any way to save this poor Jetson?

UPDATE: So, It seems every now and then (for reason I cannot discern) the flashing will not even reach the data send fail, and instead hang at “Nvflash 4.13.0000 started”. I’ve let it run for over an hour and it doesn’t seem to do anything… Here’s the terminal log for when this happens

Making system.img... /home/mike/Downloads/L4T/Linux_for_Tegra/rootfs 12884901888 
	populating rootfs from /home/mike/Downloads/L4T/Linux_for_Tegra/rootfs... done.
	Sync'ing... done.
System.img built successfully. 
copying bctfile(/home/mike/Downloads/L4T/Linux_for_Tegra/bootloader/ardbeg/BCT/PM375_Hynix_2GB_H5TC4G63AFR_RDA_924MHz.cfg) to bct.cfg... done.
copying cfgfile(/home/mike/Downloads/L4T/Linux_for_Tegra/bootloader/ardbeg/cfg/gnu_linux_fastboot_emmc_full.cfg) to flash.cfg... done.
creating gpt(ppt.img)... 
*** GPT Parameters ***
device size -------------- 15766388736
bootpart size ------------ 8388608
userpart size ------------ 15758000128
Erase Block Size --------- 2097152
sector 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(16 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 fastboot.bin
[     LNX] UH        16384        32767       8.0MiB boot.img
[     SOS] UH        32768        45055       6.0MiB 
[     GP1] UH        45056        49151       2.0MiB 
[     APP] UV        49152     25214975   12288.0MiB system.img
[     DTB] UV     25214976     25223167       4.0MiB tegra124-pm375.dtb
[     EFI] UV     25223168     25354239      64.0MiB 
[     USP] UV     25354240     25362431       4.0MiB 
[     TP1] UV     25362432     25370623       4.0MiB 
[     TP2] UV     25370624     25378815       4.0MiB 
[     TP3] UV     25378816     25387007       4.0MiB 
[     UDA] UV     25387008     30773247    2630.0MiB 
[     GPT] UH     30773248     30777343       2.0MiB gpt.img
done.
copying bootloader(/home/mike/Downloads/L4T/Linux_for_Tegra/bootloader/ardbeg/fastboot.bin)... done.
Bootloader(/home/mike/Downloads/L4T/Linux_for_Tegra/bootloader/ardbeg/fastboot.bin) used as flasher.
Existing flash application(/home/mike/Downloads/L4T/Linux_for_Tegra/bootloader/nvflash) reused.
making zero initrd... 
done.
Making Boot image... done
*** Flashing target device started. ***
./nvflash --bct bct.cfg --setbct --configfile flash.cfg --create --bl fastboot.bin --odmdata 0x6009C000 --go
Nvflash 4.13.0000 started

What was your flash.sh command line? If this was incorrect, it may be as simple as trying again with the right command. Also, what version of L4T did you flash with?

This isn’t much help now, but rather than pulling the plug or cycling power try the magic sysrq key combos from a keyboard plugged directly in:
alt-sysrq-s
This syncs
alt-sysrq-r
This remounts read-only
alt-sysrq-b
This boots.

The system would have to be fairly bad to fail this.

I flashed it with sudo ./flash.sh -S 8GiB jetson-tk1 mmcblk0p10 , as it said in the documentation. I flashed with the following L4T packages: Tegra124_Linux_R19.2.0_armhf and Tegra_Linux_Sample-Root-Filesystem_R19.2.0_armhf. I successfully flashed it once before using this configuration, which makes it more confusing to me as to why it no longer works. Thanks for your help on this.

“mmcblk0p10” is incorrect. Should end with a “1” instead of “10”…“mmcblk0p1”. If this is not a typo here, and is in fact how you flashed, then you just found the cause. So…was “10” what was actually used?

I’d also like to suggest that the R19.2 actually requires more space than the 8GiB specification. I’m sure the original L4T had smaller requirements, and perhaps they didn’t even put developer tools on it (like kernel source). My running Jetson currently shows it uses almost exactly all of those 8GiB (via df -H); mine is from the factory with 8.0G used, and 4.0G available on “/”…thus they likely created it via “12GiB” instead of “8GiB”. This is unlikely to cause an install failure though, as my running system includes unpacked and rebuilt kernel code and a few packages added.

It turns out that I did have ‘10’ instead of ‘1’, but flashing with “flash.sh -S 12GiB jetson-tk1 mmcblk0p1” doesn’t change the error.

Here’s the full log if it helps.

copying dtbfile(/home/mike/Downloads/Tegra_Flash/Linux_for_Tegra/kernel/dtb/tegra124-pm375.dtb) to tegra124-pm375.dtb... done.
Making system.img... 
	populating rootfs from /home/mike/Downloads/Tegra_Flash/Linux_for_Tegra/rootfs... done.
	Sync'ing... done.
System.img built successfully. 
copying bctfile(/home/mike/Downloads/Tegra_Flash/Linux_for_Tegra/bootloader/ardbeg/BCT/PM375_Hynix_2GB_H5TC4G63AFR_RDA_924MHz.cfg) to bct.cfg... done.
copying cfgfile(/home/mike/Downloads/Tegra_Flash/Linux_for_Tegra/bootloader/ardbeg/cfg/gnu_linux_fastboot_emmc_full.cfg) to flash.cfg... done.
creating gpt(ppt.img)... 
*** GPT Parameters ***
device size -------------- 15766388736
bootpart size ------------ 8388608
userpart size ------------ 15758000128
Erase Block Size --------- 2097152
sector 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(16 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 fastboot.bin
[     LNX] UH        16384        32767       8.0MiB boot.img
[     SOS] UH        32768        45055       6.0MiB 
[     GP1] UH        45056        49151       2.0MiB 
[     APP] UV        49152     16826367    8192.0MiB system.img
[     DTB] UV     16826368     16834559       4.0MiB tegra124-pm375.dtb
[     EFI] UV     16834560     16965631      64.0MiB 
[     USP] UV     16965632     16973823       4.0MiB 
[     TP1] UV     16973824     16982015       4.0MiB 
[     TP2] UV     16982016     16990207       4.0MiB 
[     TP3] UV     16990208     16998399       4.0MiB 
[     UDA] UV     16998400     30773247    6726.0MiB 
[     GPT] UH     30773248     30777343       2.0MiB gpt.img
done.
copying bootloader(/home/mike/Downloads/Tegra_Flash/Linux_for_Tegra/bootloader/ardbeg/fastboot.bin)... done.
Bootloader(/home/mike/Downloads/Tegra_Flash/Linux_for_Tegra/bootloader/ardbeg/fastboot.bin) used as flasher.
Existing flash application(/home/mike/Downloads/Tegra_Flash/Linux_for_Tegra/bootloader/nvflash) reused.
making zero initrd... 
done.
Making Boot image... done
*** Flashing target device started. ***
./nvflash --bct bct.cfg --setbct --configfile flash.cfg --create --bl fastboot.bin --odmdata 0x6009C000 --go
Nvflash 4.13.0000 started
chip uid from BR is: 0x340010017408f042100000000efc8340
rcm version 0X400001
Skipping BoardID read at miniloader level
System Information:
   chip name: unknown
   chip id: 0x40 major: 1 minor: 1
   chip sku: 0x81
   chip uid: 0x000000017408f042100000000efc8340
   macrovision: disabled
   hdcp: enabled
   jtag: enabled
   sbk burned: false
   board id: 0
   warranty fuse: 0
   dk burned: true
   boot device: emmc
   operating mode: 3
   device config strap: 0
   device config fuse: 0
   sdram config strap: 3

RCM communication completed
BCT sent successfully
odm data: 0x6009c000
downloading bootloader -- load address: 0x80108000 entry point: 0x80108000
sending file: fastboot.bin
data send failed NvError 0x120002
command failure/warning: bootloader download failed (bad data)
bootloader status: BCT is invalid or corrupted or SDRAM params may be wrong (code: 12) message:  DownloadBootloader 1118 flags: 0

Failed flashing ardbeg.

I had the same problem finally found that it was because i was using ubuntu 13.03. Ive now successfully flashed my board with the 19.3 by using vmware on a mac and ubuntu 12.04. If you have access to another linux box specifically 12.04 try this and let us know if it works. Further note that i set the partition to 12GiB on the flash instruction line. Ive tried two different linux distros at 13.03 and the errors varied. However the 12.04.4 ubuntu distro worked like a charm. Hope this solves your issue.

Are you referring to putting 12.04 on the Jetson or on the host computer? I’ve been running 12.04 on the host the entire time. If you’re referring to putting 12.04 on the Jetson, how? Don’t you need a specialized kernel?

Update added to original post.

No I’m referring 12.04 on the host. Maybe try I fresh copy in a VM if possible.

L4T version R19.3 was very recently released, and I noticed under section 1.3 “top issues fixed since last release” (TegraLinux Driver Package R19.3 Release Notes document) this note comparing R19.3 to R19.2:
Default partition size no longer must be increased.

It seems like no “-S” size option would be a starting point…which should consume the entire eMMC for the installation. If that succeeds, then back down 1GiB at a time.

any solutions? or i have to RMA it

Use another USB cable. If your USB cable is even slightly dirty or deformed, the flash will fail. Buy a brand new, 3-6 foor USB cable… No longer… and only use this USB cable for flashing this board.

Thank you all for the responses. I have tried messing with the partition size, including leaving off -S; I’ve also tried using a fresh USB cable, and I’ve tried a fresh install of Ubuntu 12.04. None of the aforementioned solutions have yielded any success, nor have any of the things I’ve come up with. I think at this point I may just have to RMA it…

EDIT: I tried flashing it again leaving off -S, and… it still didn’t work. But I got a different error, and it made it past where it had previously. It started looping errors like the one shown below and then ended with a simple “failed” message. Plus it’s only creating a 1.6 gig partition…

tar: var/cache/apt/archives/partial: Cannot mkdir: No such file or directory
tar: var: Cannot mkdir: No space left on device
tar: var/cache/cracklib: Cannot mkdir: No such file or directory
tar: var: Cannot mkdir: No space left on device
tar: var/cache/cracklib/src-dicts: Cannot open: No such file or directory
tar: var: Cannot mkdir: No space left on device
tar: var/cache/cracklib/cracklib_dict.pwd: Cannot open: No such file or directory
tar: var: Cannot mkdir: No space left on device
tar: var/cache/cracklib/cracklib_dict.pwi: Cannot open: No such file or directory
tar: var: Cannot mkdir: No space left on device
tar: var/cache/cracklib/cracklib_dict.hwm: Cannot open: No such file or directory
tar: var: Cannot mkdir: No space left on device
tar: var/crash: Cannot mkdir: No such file or directory
tar: var: Cannot mkdir: No space left on device
tar: var/local: Cannot mkdir: No such file or directory
tar: Exiting with failure status due to previous errors
failed.

If this gives anyone any ideas let me know.

Probably the only “simple” thing left to try is to be sure that all of the source on the host machine should be unpacked as root or sudo. If tar is used manually for anything, make sure the -p for preserve permissions is used. Then be sure root or sudo was used for the actual flash command on the host. Some operations (like creating device special files) could require this and not necessarily be obvious. Was the entire operation done as root or sudo root on the host machine?

Yah, it was all done sudo with “sudo tar xpf”. Looks like it’s going to have to be RMA…

Can you see ‘No space left on device’ error?

Basically, you’ve ran out of space.

Also, it would be beneficial, if you post the command line, so that people don’t have to guess, what kind of typos could have been preceding the errors.

Can you see ‘No space left on device’ error?

Basically, you’ve ran out of disk space.

Also, it would be beneficial, if you post the command line, so that people don’t have to guess, what kind of typos could have been preceding the errors.

It does make me wonder if the prior mmcblk0p10 error actually altered the eMMC in some way that using the correct mmcblk0p1 no longer works. Not sure how he’d test that though.

I just had another thought about this. Obviously I won’t be testing this on my board, but in recovery mode (micro-B connector connected to host, reset held down while bringing up power), the “parted” application from host machine might be able to partition eMMC.

If I simply use “parted -l” to list block devices, eMMC does not show up with jetson in recovery mode. lsusb does show an nVidia device connected via USB this way, so something in the flash.sh scripts might describe a way to read existing eMMC partitioning or configuration. If this could be read, then comparing the failed system to the working ones might show if it is merely an eMMC configuration issue after using the wrong mmcblk0p10 (should have been mmcblk0p1). If there is no failure of the setup from this, it might be RMA time.

When M_squared does get to RMA stage, it is possible that whoever issues the RMA might be able to offer a way to validate if it is just eMMC setup failing.