It says:
"sudo ./flash.sh -S 8GiB ${BOARD} mmcblk0p1 "
But I saw “-S 14GiB” in many posts - why NOT to do that? And what info gave people the idea that 14GiB works as option?
Also, can I run the flash.sh on ANY machine? I.e. another ARM-based machine? Or are there binaries involved that require x86?
I read that I would have to enable USB3 in that config file. Why is it not on by default? Any good reason? Stability/power?
My current system (LXDE Desktop) on the Tk1 freezes every now and then - I hope/guess its the gfx driver and will be better/fixed in 19.3.
“5. Installing the graphical desktop on your target board (if not already installed):”
I dont understand that line. From my understanding the flash.sh will rewrite the whole memory. So graphical desktops are either installed or not. Or is that text supposed to be generic for future/other releases? I found that confusing, sorry :(
I would appreciate any help/confirmation of my assumptions.
I believe there should be a ‘sticky thread’ on the flash-update with clear statements of the options and a ‘what most people would want’ walkthrough.
Thanks alot, I am using the Tk1 also as full Desktop system.
It should be safe to use -S 14GiB, it just takes a lot longer. But it’s worth the time, if you are not flashing it frequently. The size was found by someone just by trying it out, 15GiB didn’t work anymore.
I think the flash.sh uses some binaries, so running it from an ARM machine probably won’t work.
I recently flashed r19.3 and it seems better, maybe slightly faster/smoother.
For flash.sh I used this
sudo ./flash.sh -S 14GiB jetson-tk1 mmcblk0p1
Also before you execute flash.sh make sure you prepared rootfs on a ext4 partition with atleast 15gb free space as host (x86) Linux computer created 14 gib partiton that is later flashed onto Jetson.
Thank you so far. Both is new to me and exactly the kind of information I was looking for and hoping to see them in ONE combined place/document. Maybe Im just missing something…
But I am not sure I got the last one:
I need to set up a new partition with Ext4 on the HOST than I run flash.sh from?
How does flash.sh know which one to use?
Is that not dangerous for the ‘host’ system?
The flash.sh will create the Jetson rootfs image in a single 15GB file and then send that file to the board. So no need to do any partitioning on the host computer.
FYI, if you run flash.sh with no arguments, it gives a small help list on options. The -S is simply for how large of a partition to use, and this is how we find out what the purpose of the nVidia document is when specifying -S 8 GiB. The eMMC flash “hard drive” is 16 GB, but there are inefficiencies such as small partitions which use up space and are not normally visible, so 14 GiB was the largest it took before the image was too big to fit.
During flash, the exact image of the entire Jetson file system is created on your host, and the file permissions have to be preserved. This means only root authority (e.g., sudo) will do this (try making device special files without it), and only a native linux filesystem will understand permissions (NTFS has no understanding of linux permissions).
The original L4T which has evolved did not require this much space…it has grown. Used to be 8 GiB was fine, but it might still be useful to increase it even then (unless you wanted to make another partition which didn’t go away after flash). I simply want my system to use the whole flash, and so 14 GiB is what I use. If the size is too small, flash will fail when the partition on the Jetson is fully consumed and flash is still trying to put more there…new and changed packages tend to mean 8 GiB will be too small or on the edge of too small…especially if you update packages after the install.
I have doubts about non-x86 host install because x86-only binary files are likely involved, but it would be interesting to try to flash from one ARM system to another, e.g., Jetson to Jetson (the front end programming is all portable script). You’d have to use an external hard drive or SD card though, since Jetson doesn’t have enough space for its own file system plus a full image of the other Jetson.
Thanks for all the info/help!
I managed to flash my Tk1 yesterday including USB3. Havent set up LXDE yet etc, but it seems all worked fine. I will post what I did exactly later in case other newbies on the TK1 like me read this and were confused/overwhelmed by different information.
I like to upgrade to 19.3 too but I am a bit afraid that the board will not work anymore after flashing (a lot of people seems to have problems with the procedure).
I did:
export RELEASE_NAME=Tegra124_Linux_R19.3.0_armhf.tbz2
(just for the sake of compability, you can just use the name itself in the next lines)
(this is step 2)
sudo tar xpf ${RELEASE_NAME}
cd Linux_for_Tegra/rootfs/
sudo tar xpf …/…/Tegra_Linux_Sample-Root-Filesystem_R19.3.0_armhf.tbz2
cd …/
now I changed the jetson-tk1.conf file first.
Just uncomment the line for USB2 and comment in the line for USB3. Then:
sudo ./apply_binaries.sh
Now I connected the TK1 to my big linux machine.
My tk1 powers up as soon as the PSU is connected. I did ignore that.
Pressed the RECOVERY button, kept it pressed and once pressed the RESET button during that. Then I released the RECOVERY button again and had NO feedback of success which is normal.
I flashed the device twice (forgot the USB3 thing first) once with NOTHING but the USB-cable connected to the tk1 and then again with HDMI, ethernet, USB-hub+kb/mouse. Both works.
To the main linux machine I connected JUST the one USB-cable that came with the kit.
On my intel machine the tk1 shows up properly ONCE in recovery mode (so this is the feedback you get).
Then I issued as root on the intel:
sudo ./flash.sh -S 14GiB jetson-tk1 mmcblk0p1
I made sure to have at least 15 GB free drive space available on the partition I launch all this.
The verbosity of the process is very nice. To get further information on whats happening I opened up two further terminal windows.
One running ‘htop’ for CPU usage, and one with ‘watch -d df’ which constantly watched drive-space.
You can follow the process VERY WELL then.
It took quite some time. Around 1 hour I would say. Maybe a bit less.
But I got some update on bytes sent or so every couple of seconds so that gave me some confidence ;-)
(you see how the rootfs fills up nicely with the watch -d command :)
It ended with ‘success’. The tk1 rebooted itself but I ran it again nontheless.
It booted straight away into the (ugly) unity-desktop.
Next steps will be to setup LXDE (again) and some other things.
I suggest this site: http://elinux.org/Jetson_TK1
I believe it is safe to add the ‘universe’ repository. If someone objects, please let me/us know.
Thanks,
Martin
I don’t have another Linux machine to function as a host machine. Can I use my macbook pro with OSX maverick on it?
Alternatively, if I use a windows pc with a linux vm, (Oracle Linux VM or Parallels VM) would it work as a host machine?