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