I think the R21.x series was the last release for TK1s. The whole JetPack concept still did not exist. Try directly with the R21.8 release. Basically you’d download the driver package and sample rootfs. You’d unpack the driver package as a regular user, then the created directory of “Linux_for_Tegra/” would have most of what you’d need. You’d then cd to “Linux_for_Tegra/rootfs/”, and then at that location as root/sudo unpack the sample rootfs. Basically:
sudo tar xvfj /where/ever/Tegra_Linux_Sample-Root-Filesystem_R21.8.0_armhf.tbz
# Now finish preparing the rootfs from "Linux_for_Tegra/":
At this point the “flash.sh” script would be ready. You’d attach the recovery mode TK1 and run the command from host PC: sudo ./flash.sh jetson-tk1 mmcblk0p1
You’d have to manually deal with the extra/optional packages, e.g., CUDA.
In fact, my colleagues had installed the Jetpack 3.1 on TK1 (R21.8 release) successfully by the application before. But we have no idea why the application that on his host PC can’t be executed in this time…
I would like to solve it. So I installed this application on pure host PC(Ubuntu 14.04). It had the same problem.
Is there a reason you don’t want to use command line via flash.sh? JetPack is just a front end. You can (if that JetPack release is still working) manually download any “optional” packages, e.g., CUDA, and install those via command line if you have patience (those early packages were not in a package format, they were just tar archive files to unpack). Using flash.sh would bypass any JetPack failures.
Then we could install those packages into TK1 successfully by the application in previous time.
We think that it is easier way to install packages for client, so we provided this method to client for installing those packages.
It worked fine before, but it gets the error at step 6 of the documentation in this time, the application shows “fopen failed with file local.db, errno = 2” message.
I have no idea how to solve it. Thanks.
In these older releases the install is basically just unpacking a tar archive file. Most of that content will unpack into a subdirectory of “/usr/local”, and perhaps in some cases also into “/opt”. If you’ve run a JetPack which is for the correct version of your release (which I’m not sure of which is correct since this is a custom release), then I think you would find that content might be in: ~/Downloads/nvidia
(I am unsure because this was from long ago before SDK Manager existed, and JetPack was itself still somewhat “experimental”…and if not there, then a “.json” file would provide information about where certain downloads are found)
I don’t remember exactly what the CUDA install setup was, but the docs for R21.8 should have that information (that was many years ago, my brain is starting to forget). What you won’t find is a compatible release under R23.x+ since TK1 support stopped after R21.x. If you use one of the releases based on actual “.deb” packages, then it isn’t compatible with 32-bit armhf (not due to the package, but due to the fact that the “.deb” versions only started development under 64-bit).
One thought is to just flash a stock TK1 system and examine what is there (including logs of the flash and seeing what shows up in “~/Downloads/nvidia/” as a result).
I assume it is only a typo, but “Download” should be plural, “Downloads”.
Note that unless the host PC has the repositories enabled (either manually or via using JetPack/SDKM, probably SDKM), then the “apt-get” commands won’t be able to see the content. Some of the download ability evolved in what because SDK Manager, although JetPack by itself did have some ability to figure out downloads via its “repository.json” file. This was many years ago, and I’m not absolutely certain of what should be where if you run JetPack. You’d have had to have run it at least once to get downloads content.
The “driver package” is most of the content which unpacks and creates “Linux_for_Tegra/”.
The content of “Linux_for_Tegra/rootfs/” is initially populated by a separate purely Ubuntu package, the “sample rootf file system”.
You would normally (if not using a front end for automation) unpack the driver package first as your regular user (don’t use sudo).
You would then upack (as root, so do use sudo) the sample rootfs into the “Linux_for_Tegra/rootfs/” location.
Then, from “Linux_for_Tegra/”, you would complete the addition of NVIDIA’s hardware accelerated content via the command “sudo ./apply_binaries.sh”.
Once the above is done, then flash.sh can be used. Do note though that this is the base operating system, and this does not include many of the extras, e.g., it doesn’t include CUDA.
I am thinking that the URL to this release is missing the “extra” content, e.g., probably CUDA and others should be available there since this is not via SDKM.
Could someone here verify if the older R21.8 required CUDA and other optional packages to be downloaded separately since this was only the beginning of JetPack?
I do see JetPack 3.1 was the most recent JetPack capable of working with L4T R21.8, and so if R21.8 was just a patch release, then it is possible that you could run JetPack 3.1 to install extras like CUDA if you first tell JetPack you are not flashing and not adding to the host PC…the optional packages, like CUDA, might be correct with JetPack 3.1 and L4T R21.8. I am uncertain about this, but it is worth checking out. Should you succeed in telling JetPack 3.1 to install CUDA to a fully running Jetson (not in recovery mode), then probably the content which we didn’t see in the host PC’s “~/Downloads/nvidia/” would then exist and be populated. You are definitely correct that flashing does not install this content, and that you can install to a fully running Jetson without flashing provided you uncheck the flash of o/s step.
The use of automated downloads only started with JetPack