I have followed the procedure outlined in the following document: http://developer.download.nvidia.com/embedded/L4T/r23_Release_v1.0/NVIDIA_Jetson_TX1_Developer_Kit_User_Guide.pdf
I may have interrupted the copying process (i.e. when files get copied over to Jetson)
But I witnessed the ‘installation complete’ window shown in step 14 of the aforementioned document.
My problem is when I go to locate the samples ( /home/ubuntu/NVIDIA_CUDA-_Samples/bin/armv7l/linux/release/gnueabihf/ ) there is no ubuntu folder in my home directory.
Is there some way of confirming I have correctly installed everything that needed to be installed onto the Jetson?
Examples and extra packages are a different story, but for the Jetson itself, you can see if the direct hardware access files made it into place:
sha1sum -c /etc/nv_tegra_release
Thanks for your input ‘linuxdev’.
I executed the command you recommended ( sha1sum -c /etc/nv_tegra_release/ ) and 46 files were returned (see below) across 4 separate directories. All files were in the ‘ok’ state.
I’m assuming these are the “direct hardware access” files but I can’t find any list online to cross-reference against.
Could you send me a link to such a list (if one exists) otherwise, have you any ideas regarding the following:
(1) How can I confirm that i’m not missing some files ?
(2) If all else fails, how does one reset the Jetson to factory settings (I might go back and install the 32-bit version of Jetpack instead)
Directory 1: /usr/lib/aarch64-linux-gnu/tegra/
Directory 2: /usr/lib/aarch64-linux-gnu/libv4l/plugins/
Directory 3: /usr/lib/xorg/modules/drivers/
Directory 4: /usr/lib/xorg/extensions/
You are correct, files listed in “/etc/nv_tegra_release” are those which are needed for hardware access. The “ok” means the files match an exact checksum and are in the location they are required. These tend to be the files which an error in a package manager could end up overwriting and cause a video or other mysterious failure after an update…but it is safe to do updates, the checksum is only a way to validate and normally updates do not harm anything (there would have to be a bug for the package manager update to overwrite these).
There may be other files as well, e.g., kernel modules and firmware are separate. These tend to be files not managed by a package manager, and often adjusted by kernel compile for feature changes.
I do not know of a comprehensive list of file content. All of those files though are part of the driver package and populated to the sample rootfs via the apply_binaries.sh script (or else they become part of a hidden partition, e.g., the u-boot binary has its own partition without being in rootfs). To see the tar.bz2 archives used run this from your L4T driver package:
egrep 'tar.+tbz2' apply_binaries.sh
From there you can see the content of any one tarball archive:
bunzip2 < filename.tbz2 | tar --list
Other files intended for populating “/boot” are in an L4T driver package subdirectory. Generally speaking these are the dtb files and extlinux.conf. Most of what gets put in “/boot” is never used (files referenced in extlinux.conf need to exist, other files can be removed).
If JetPack is used for other software this is a separate case and not part of the driver package.