Glad it is working. Sounds like you don’t need more work for this task, but if you are interested, read what follows as you mentioned something which sounds strange (and interesting to me…this is an issue I have not seen before for JetPack/SDKM, but have seen many times with other unrelated software running on a PC).
uname -r” of
4.9.140-tegra is correct for
R32.4.3, and is very recent, you said you used JetPack3.3. I suppose it is possible JetPack3.3 somehow got hold of a JetPack/SDKM 4.4
repository.json file, which would imply that JetPack3.3 is using JetPack4.4 content (
repository.json is a file which gets updated frequently at the NVIDIA server and names URLs and package names). This seems unlikely though. If you happen to have both JetPack3.3 and JetPack4.4 installed on your host PC (perhaps via SDK Manager for the latter), then I could see the possibility that you are really running JetPack4.4 when you think it is 3.3.
You definitely have
R32.4.3 installed on the Jetson, and it is easy to work with this even if we ignore how you ended up with
R32.4.3 from JetPack3.3. However, do know that if you install optional components such as CUDA from mixed releases, then this will fail (the operating system won’t fail, but the optional components should not be allowed to install…CUDA from JetPack3.3 is quite different from JetPack4.4, and the two cannot be mixed…there is a strong dependency on the o/s version). If you always use JetPack4.4/SDKM, then this will never be a problem, but if you somehow do execute JetPack3.3 to install optional packages to the Jetson, then you could have a problem with the optional packages.
Note that if you have two executable files installed, the one which is found first in the search path is used. Perhaps you have tow JetPack or SDKM files installed, and got the 4.4 version.
In some cases the file to execute has its version in the name, and a symbolic link to a “generic” non-versioned file is created to act as a “default”. If you only had JetPack3.3 installed, then you might have a file with
3.3 in its name, plus a symbolic link to the same name less “
3.3”; if you then installed a
4.4 version, then you would have both a
4.4 executable and a
3.3 executable, plus a new symbolic link without a version name pointing at
4.4. Executing the generic unversioned name would execute
4.4 despite thinking it is
3.3. I really don’t know if this is what is going on, but you might want to be suspicious of which JetPack you are really using in the future if something seems a bit off.