Hello, i was trying to flash my jetson tk1 but i get to the line sudo ./flash.sh -S 14GiB jetson-tk1 mmcblk0p1 and it gives me Error: Invalid target board - jetson-tk1. any help would be apreciated, i already checked that the jetson is detected by the linux pc. Thanks
Maybe you downloaded wrong files?
Maybe you didnt do sudo ./apply_binaries.sh before?
The micro-B USB cable which comes with it must be plugged in, and the unit powered on while holding the “force recovery” button down.
I thought i had done the sudo ./apply_biaries.sh, i did it wrong or it didnt work the first time, but i did it again ad it worked thanks
I just flashed mine recently and it went very well. It is described in some detail here:
@MODS: is there a way to change the title of a topic? I should have added “solved” and “jetson tk1”
I had to flash it again from scratch, i figured out it that if i dont apply_binaries.sh as root it says succes but it seams not to work and it gives me Error: Invalid target board thanks for the help tho
Is it possible to flash it from Apple?
If you use Linux, yes. Dual boot would be the best solution. Virtual machine might work, too.
On the VM front, I have flashed from VMWare Fusion but I’d imagine VirtualBox works as well.
VirtualBox works for me.
Just make sure you have a device filter set to assign the TK1 to the Ubuntu VM:
I’m flashing a TK1 using the JetPack L4T, running a Macbook Pro hosted Virtual Machine Ubuntu 14.04 LTS. Everything seems to be going well, but I’m wondering how long it should take? I’ve been waiting for about an hour an half…
An ordinary flash takes quite some time. It creates a file the size of the partition to be added, so roughly 15GB in size on your host o/s. Then it formats this, then it populates it with the entire install sample rootfs (with a few edits for the boot loader). This is then converted to a “sparse” file (basically compressed), and only then is the flash process started. The sparse file is usually about 2-3GB, and so the whole process would rarely take less than an hour. Once the rootfs sparse file is created it can be re-used, which dramatically decreases install time.
Thanks for the reply. I think something is going on though, because I keep getting stuck at
" u-boot.bin sent successfully
sending file: system.img
| 200278016 / 2373145292
"
It just hangs at this state for hours… :(
This is correct behavior. The file is several gigabytes in size, being sent slowly over USB2…and the eMMC being flashed may not even accept the data as fast as the USB2 pipe. Before the sparse/compressed version of system.img was used it seemed like flash was an all day event…at the very least it was about 4 times longer than the sparse version. Even now it may not be abnormal for it to take an hour or two for that one file. The fact that the tiny u-boot.bin was sent means it is working. Just let it go for several hours, this is normal.
Linuxdev… thanks again for the comment.
I let it sit at this state all night and I’m still getting the same result: it’s hung up.
I think it might have something to do with my virtual machine? I really have no idea. I’ve just been fighting this thing for days.
Just FYI I dual boot my Macbook with bootcamp Windows and El Capitan. I tried installing Ubuntu after partitioning the drive, only to have my Bootcamp stop working. I fought that for a while. Finally I just removed Ubuntu. I can boot Ubuntu from my SD card but it’s not large enough to fit all of the files I need to flash the TK1.
All night is obviously wrong, but it is odd that the smaller files transmitted correctly without error while the larger file did not, even on a VM. However, there have been a LOT of VM issues people have run into, a VM has a lot of odd issues people run into which are not expected until digging into tiny details. For example, having a wrong file system type where the sample rootfs was unpacked will make things look like they are working, but in reality not working. If you didn’t have enough file space on the VM (or a native Linux), then some things get truncated and you may also run into odd issues (using “df -H -T .” in the driver flash program directory gives a good idea of how much space is left, and whether the file system type is correct).
If everything else seems ok (check the “df -H -T”) I would say it looks like things were going correctly and that if your procedure was correct, then it is likely an issue of the VM environment. It could still be something simple like needing a shorter cable if it was a USB problem.
What is the command to reuse the rootfs file once it is already created? How do I realize the mentioned decrease in install time? Thanks!
The “-r” flag skips rebuild of system.img. Note that during original flash system.img is created as an uncompressed raw file, roughly 15GB in size. This is then moved to file name system.img.raw, and system.img.raw is used to create a sparse/compressed file of the original name system.img. The flasher is actually capable of using either raw or sparse file, and will re-use whichever file is named system.img without rebuilding either raw or sparse file.
I am uncertain if it is necessary or even has an effect to restate the “-S” size when reusing an image, but I do know it doesn’t hurt. Some partition layout would change depending on root partition size, so it doesn’t hurt to be reminded on command line what size was originally used. Since I normally flash with “-S 14580MiB”, when I reuse an image (either a sparse image or a raw cloned image), I do this:
sudo ./flash.sh -S 14580MiB -r jetson-tk1 mmcblk0p1
If you reuse the original sparse image named system.img, flash time is fast. If you rename a cloned raw image to be system.img, flash is slow. It is possible to manually convert a raw image to a sparse image, but then you can’t loopback mount it anymore, and cannot rsync update it, which kind of defeats the purpose of cloning for most developers.
I’m having trouble flashing the TK1 in recovery mode.
I get to the point where it says:
sending file: system.img
382730240 / 2733145532 bytes sent
Then it just hangs there. I’ve let it run overnight and it never changes.
About my setup:
I’m using VirtualBox 5.1.2 on a Windows laptop (Windows 7 Professional, SP1).
I create a virtual machine, Ubuntu (32-bit), with 2048 RAM, and a VHD 32gig (fixed, not dymanic)
The Ubuntu version is 12.04 32-bit PC (i386) desktop CD.
#Once Ubuntu is installed (not the trial, full installation), I open a terminal window:
mkdir reflash
cd reflash
wget https://developer.nvidia.com/embedded/dlc/l4t-Jetson-TK1-Driver-Package-R21-5
wget https://developer.nvidia.com/embedded/dlc/l4t-Jetson-TK1-Sample-Root-Filesystem-R21-5
#Then I extract the Driver Package tarball:
sudo tar xpf l4t-Jetson-TK1-Driver-Package-R21-5
#Then I extract the File System tarball into a specific sub-directory:
cd Linux_for_Tegra/rootfs
sudo tar xpf …/…/l4t-Jetson-TK1-Sample-Root-Filesystem-R21-5
#Then I apply binaries
cd …/
sudo ./apply_binaries.sh
#Then I plug in the USB cable and put the TK1 into recovery mode.
#Verify the board is connected with:
lsusb
#Finally, I’ve tried each of the following without success:
sudo ./flash.sh jetson-tk1 mmcblk0p1
sudo ./flash.sh -S 8GiB jetson-tk1 mmcblk0p1
sudo ./flash.sh -S 14580MiB jetson-tk1 mmcblk0p1
sudo ./flash.sh -S 14580MiB -r jetson-tk1 mmcblk0p1
#The flash process starts, gets to the point where it is sending data, but then it hangs.
Any suggestions?
If it hangs at the same “bytes sent” of system.img, then I’d say it has bad eMMC in that partition offset. If the location of failure differs when flashing the exact same way it may be something else, e.g., cable problems.
One subtle issue to be careful with though is that each command to a Jetson in recovery mode potentially invalidates “starting over” without restarting the Jetson in recovery mode again. So for example, it won’t work to flash twice or clone twice or clone then flash without tapping the power reset button with recovery button held down between those operations. I doubt you would have ever got any successful write if this were the case, but I wanted to point it out to be thorough.
In the case of hanging at a specific spot each time, RMA is probably required. RMA info is near the top of this:
[url]https://devtalk.nvidia.com/default/topic/793798/embedded-systems/some-jetson-web-links/[/url]