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
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.
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?
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.
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.
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?
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.
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.