Whether TX2 provide 32-bit tool chain or not? Thanks!
Yes, but that’s for R28.3 BSP, please get them from Jetson Download Center: https://developer.nvidia.com/embedded/downloads
That’s mean Jetpack4.2 can’t use it 32-bit tool chain, Jetpack3.2.1 and Jetpack3.3 can use 32-bit/64-bit tool chain?
If you mean a 32-bit host, then no. If you mean a toolchain outputting arm32/armhf, but running on x86_64/amd64, then yes. FYI, I think it was R24.1 which was the last release using a 32-bit chain (or close to R24.1…this was the transition between older 32-bit armhf/ARMv7-a and newer 64-bit ARMv8-a…this transition ran 64-bit kernel space and 32-bit user space because end user packages had not yet been created for 64-bit). None of the TX2s use 32-bit, they are a 64-bit architecture. The 64-bit has a 32-bit compatibility mode, but this is not used (and cannot be used unless you do a lot of foreign architecture installs).
I have two questions:
First, we use TX2 Jetpack4.2 32-bit tool chain, it has a 32-bit application running on TX2, and compiled successfully, but running the application failed, it had pointer problem. So I want to ask whether it is related to the Jetpack version? if we use Jetpack3.2 or 3.3, the problem can slove it?
Second, whether TX2 support direct compiling the 32-bit application?
There is a possibility that a host can use an i386 32-bit binary. This is considered a foreign architecture on the host PC, whereas native is called either of amd64 or x86_64 (these are “native” architecture). It just happens that the host PC often has “compatibility” (foreign architecture) support for 32-bit execution. The desktop PC is different than embedded systems in that it was well known ahead of time that both 32-bit and 64-bit would need support in order for 64-bit to succeed.
The TX2 has a foreign architecture possible for 32-bit, but this is not the default and installing everything needed for it is not trivial. It won’t happen by accident. For any 32-bit ARMv7 code to run on a TX2 (other than the R24.1 release) expect that it won’t happen without a lot of effort. It should be noted that no TX2 was ever released with the R24.x series…this was only for the TX1. Any document you may have read about this was not for the TX2, and any 32-bit application you are looking at is very likely intended to run on the desktop PC as i386.
The code produced by a cross compiler running on the PC, where the PC is executing 32-bit i386 code just depends on what the compiler is producing. If it turns out the code is for an R24.2 or later release TX2, then it implies the code being output is ARMv8-a/arm64/aarch64, and it is not 32-bit ARMv7-a/arm/armhf.
JetPack does install different software versions depending on what L4T version was being flashed by that JetPack. Various revisions of CUDA and other packages from one JetPack to the next are not compatible and are bound to the L4T release. The L4T release can be found with “head -n 1 /etc/nv_tegra_release”. Any JetPack3.x will be for 64-bit ARMv8-a/arm64/aarch64.
No release for the TX2 supports directly compiling or running any 32-bit application. All ARMv8-a CPUs support a non-native emulation (known as ARMv8, no “-a”) which can run 32-bit armhf. This is a compatibility mode which runs quite slow. However, one would need to also install an entire 32-bit linker environment, and all of the libraries would have to have duplicates added which are also 32-bit ARMv7 (ARMv8 32-bit is a superset of armhf…all armhf can run on ARMv8 32-bit, but only part of ARMv8 32-bit can run on armhf). The system would have to then be set up to use the correct 64-bit or 32-bit linker, and the linkers would have to be correctly set up to use the 64-bit or 32-bit library. Development tools for compiling 32-bit would also have to be added separately as a foreign architecture. Everything 32-bit on the TX2 is a foreign architecture.