How would I go about restoring the board to a good state if I completely hose the Linux install? I remembered seeing somewhere that the micro usb host port could be used for this purpose. Or did I imagine that?
I’m building the kernel and iwlwifi drivers from source and I’d like to give my build a shot. I just don’t want to brick the board if it doesn’t go as planned.
I don’t think you can completely brick the board, you should be always able to boot it to a recovery mode and flash everything back.
For instructions, see:
https://developer.nvidia.com/sites/default/files/akamai/mobile/files/L4T/l4t_quick_start_guide.txt
The Linux-for-Tegra link off of the Jetson Support Page will not let you take it back to the factory system as it is an upgrade to the Ubuntu 14.04 base filesystem.
However, if you download the Drivers package as well as the Example File System and expand both according to instructions in the Quick Start Guide, you will have a rootfs ready for flashing, and also flashing utilities and some scripts and configuration files essential to flashing. It does use the micro-USB port to do this.
By adjusting those config files, it is possible to install to an external harddrive and this is what I did after about the third time flashing it. In my case, I both ran out of space and wanted the convenience of simply untarring a new OS load onto the external drive and then rebooting. I don’t know if the kernel is flashed to the onboard eMMC as well as the bootloader, or if only the bootloader is flashed in this case, leaving the kernel to be loaded from the harddrive. We’ll be interested to know if you figure it out.
I should add that right now most electronics stores (in the States) have really good prices on outrageously high-capacity external laptop drives. A WD “my passport” could be had in the 1Tb size for about U$70.00 at several different “big box” stores that sell computer peripherals. Or get a SATA internal bare drive and use that, the board has a SATA port and drive-power plug, though it may be better to use an external laptop drive via a powered USB port to reduce load on the board.
Unfortunately, the links in this thread were all broken by a web site redesign. It would be nice if the current versions of the files mentioned in the thread could be found. I couldn’t find them. Google couldn’t, either.
Are you looking for the older sample rootfs files? If so here is a listing of available versions of L4T…you will find a sample rootfs with each:
[url]https://developer.nvidia.com/embedded/linux-tegra-archive[/url]
FYI, the TK1 originally shipped with R19.2. R19.3 is the oldest supported. For various reasons of bugs I would not suggest R19.2 anyway.
I want to get my Jetson TK1 boards working. (R19.2 was unusable.) I’ll take any rev that works.
I found https://developer.nvidia.com/embedded/linux-tegra-archive and followed a link from there to
https://developer.nvidia.com/linux-tegra-r216, but now that I’m there I don’t know what to make of the links on that page. I would guess that a “Driver Package” is not the same thing as a “sample root file system” but there is no way for me to know for sure. The items named in the “quick start guide” do not have names that match the link labels at https://developer.nvidia.com/linux-tegra-r216. Is there a way to map “Tegra124_Linux_R21.6.0_armhf.tbz2” (the name in the quick start guide) to a filename linked at https://developer.nvidia.com/linux-tegra-r216 such as perhaps “sample-root-filesystem-r216” ?
I’d be a lot more confident I’m not going to completely brick the board if the names matched in some way.
Basically you have a driver package which understands a Jetson when it is connected by micro-B USB cable. Under those circumstances the host sees the Jetson as a custom device, and it is the driver package which talks to that device.
The other basic necessity is the sample rootfs. This is purely Ubuntu, but when you run the “apply_binaries.sh” script from the driver package it will overlay NVIDIA hardware-specific drivers onto that file system to enable hardware acceleration. This separates distribution of proprietary software from a purely Ubuntu distribution and allows the end user to be the one which puts the drivers into Ubuntu. This also makes it possible to use any other custom root file system…which is why it is a “sample” rootfs instead of “the” rootfs.
If you were flashing on command line you would need the driver package plus sample rootfs, and the Jetson connected via the micro-B USB connector. JetPack unifies many of the operations, and one of the things it does is download the correct packages and act as a front end to the flash.sh driver. So if you download JetPack, then you don’t need to download other packages. If you want to flash on command line, then you need driver package plus sample rootfs. JetPack also adds wired ethernet as a requirement for extra package installs after flash is done and the Jetson reboots.
Note that if you manually unpack things that you must use sudo to unpack the sample rootfs, and also when running the apply_binaries.sh script (additionally when you run the actual flash.sh command). Other unpack steps should not use sudo (e.g., unpacking the driver package should not be done with sudo). If you use JetPack do not use sudo…JetPack will ask for passwords when needed.
If you are flashing on command line here are some notes (adjust for TK1 versus TX1 versus TX2):
[url]https://devtalk.nvidia.com/default/topic/982779/jetson-tk1/how-to-perform-a-correct-fresh-ubuntu-install-on-jetson-tk1/post/5040584/#5040584[/url]
It is actually pretty simple, it’s all of the precautions to unpack things correctly which get the attention.
NOTE: Placing a Jetson in recovery mode does nothing to alter the Jetson. You have to run a flash before it alters the Jetson.