You can be guaranteed that 100% of everything which was from a TK1 is 32-bit armhf. Anything CUDA on a TK1 is CUDA version 6.5 or earlier…no CUDA version was ever released beyond version 6.5 for 32-bit. Barring a need to update code to go from CUDA 6.5 to some newer CUDA (newer platforms don’t use the older CUDA), then recompiling should basically just make many parts “just work” (I won’t guarantee it, I have no idea of what the code actually links to or depends on).
You can clone the original root file system for later reference, but you couldn’t simply use it to flash the next system.
The meaning of “migrate the TX1” is to upgrade the version of L4T on the Jetson itself…to flash. The TX1 with 32-bit user space won’t do much good (this has been known to cause insanity! :P). You could stick to slightly older 64-bit releases, e.g., L4T R28.1. To do so though, you would also have to migrate any of your code to match this. If there is a dependency on CUDA, then this would be both the most work and the most meaningful gain against future pain by porting this (meaning by adjusting any older CUDA calls to the newer release). For example, you might have to port CUDA 6.5 code to CUDA 9…this would be more than just a recompile. Much of the migration would be a simple recompile, but not all would be a simple recompile.
About libraries: Most of what your applications will link to are part of the operating system. When you recompile, and if the libraries are part of the operating system, then you won’t have any “significant” (YMMV) work to deal with it…the compiler will simply link against the 64-bit version. In some cases (where for example new features are added and old features are altered) you may need to make changes. “Many” (speculation) of the libraries which you did not write and provide will “just work”. Many people have complicated builds and never create their own libraries, in which case you don’t need to port an actual library.
On an Ubuntu system, the “dpkg -S ” command can tell you what package a file comes from. On any Linux flavor, the “ldd ” command can tell you what libraries an executable is linked to. Combining ldd and dpkg commands you can get an idea of what dependencies are fulfilled by the operating system, versus which ones are custom requirements.
On a Jetson TX2, running R28.2 (this is an example…the commands will not differ with a TX1 on R28.1…this investigates “/bin/ls” only as an example), I can run “which ls” and see “/bin/ls”. If you see a symbolic link or alias, then you’d have to adjust for this, but ldd can then tell me what “ls” is linked to (FYI, I am in a root shell, “sudo -s” for all of this…in some cases this matters, in other cases it does not matter):
# ldd /bin/ls
linux-vdso.so.1 => (0x0000007fa2b92000)
libselinux.so.1 => /lib/aarch64-linux-gnu/libselinux.so.1 (0x0000007fa2b33000)
libc.so.6 => /lib/aarch64-linux-gnu/libc.so.6 (0x0000007fa29ec000)
/lib/ld-linux-aarch64.so.1 (0x0000005566599000)
libpcre.so.3 => /lib/aarch64-linux-gnu/libpcre.so.3 (0x0000007fa297b000)
libdl.so.2 => /lib/aarch64-linux-gnu/libdl.so.2 (0x0000007fa2967000)
<b>libpthread.so.0 => /lib/aarch64-linux-gnu/libpthread.so.0</b> (0x0000007fa293b000)
If I were to run “ls -l” against these, it might be a symbolic link…then I’d run “ls -l” again against the provider of that symbolic link until I see the hard file (if not familiar, a symbolic link just points at another file and stands in place for the other file…“ls -l” uses “=>” to name the file the link points to similar to dereferencing a C pointer). As an example, I see “libpthread”, and this points to “/lib/aarch64-linux-gnu/libpthread.so.0”. Using “ls -l /lib/aarch64-linux-gnu/libpthread.so.0”, on this release, it points to hard link “/lib/aarch64-linux-gnu/libpthread-2.23.so” (a symbolic link is a pointer, a hard link is the final actual file). Now I can use the package tool (“dpkg”) to tell me what package provided the file:
# dpkg -S /lib/aarch64-linux-gnu/libpthread-2.23.so
<b>libc6</b>:<b>arm64</b>: /lib/aarch64-linux-gnu/libpthread-2.23.so
Because I know a system package provided libpthread (via the arm64 version of the “libc6” package), I know I won’t need to recompile this library when I migrate…instead I’ll just rebuild my app and the compile itself will take care of linking. Should it turn out that the application is linked to something not provided by the system, then I would have to build the library myself before I could build my application.
If a library is provided by someone else and you do not have the source code, then if they also provide an arm64/aarch64 version, you do not need to worry about it…this too will simply be linked against when you recompile. If it turns out the provider of a proprietary binary library does not have a version for arm64/aarch64, then you must ask the provider of that binary to port it and provide it to you. You won’t have any other way of dealing with it other than sticking to the old 32-bit version.
FYI, most packages have a name, and a “name-dev”. The “-dev” version is the one used for development, e.g., header files. So if you were to port something which links to libc6, then you might (or might not) find you need to install “libc6-dev”. Sometimes you will need to set up the apt tool’s configuration to show the dev version, but you can ask about that when you get there. If the repositories are configured already, then the dev version of libc6 would be as simple as:
sudo apt update
sudo apt-get install libc6-dev
The list would be large, but you can search for “libc6” via:
apt search libc6
# Or more narrow search:
apt search libc6-dev