I see - I had somehow installed tensorflow in a virtualenv I think using instructions here: Installation issues with TensorFlow for the Jetson Nano on virtualenv(virtualenvwrapper) but what is the best way to install the latest version of Tensorflow for JetPack 4.6.2 on a Nano 4GB that does have GPU support?
If you are using Python 3.6 and your pip3 points to Python 3.6, then you original command should work for that:
pip3 install --pre --extra-index-url https://developer.download.nvidia.com/compute/redist/jp/v46 tensorflow
I think it didn’t work initially because you were setup with Python 3.8, and we don’t have Python 3.8 wheels under that URL, so it pulled them from PyPi instead.
Hi Dustin, If I understood it correctly, that is going to be a fully supported version of Jetpack for Jetson NX and Orin boards, isnt it?
Yes, JetPack 5.0 supports Xavier and Orin devices, including Jetson Xavier NX, Jetson AGX Xavier, and Jetson AGX Orin.
Is the nano going to receive no further updates?? This would be rather shocking - is a layer 5.x jetpack going to support the nano?
I mean a fully supported production release jetpack with ubuntu 20.04, so finally we can forget about ubuntu 18.04))))
Nano/TX1/TX2 will continue receiving maintenance and security fixes but will remain on JetPack 4.6.x. JetPack 5.x will not support Nano. For more information please refer to the Jetson Software Roadmap which announced this last year:
Hi @shahizat005, yes, JetPack 5.0.2 is a production release for Xavier/Orin with Ubuntu 20.04.
I will answer this as a fellow user, @trey if you need any bugs fixed on jetpack 4.X, don’t ever get your hopes up or expect anything from nvidia. These platforms are effectively dead.
I am celebrating the nearly 1.5 year anniversary of my critical bugfixes not being fixed in jetpack 4.X (and 5.X) with nvidia stating they will not fix them.
You are welcome to follow the journey of xorg rotation/composition stutter/framepacing issues (present on all jetsons, all jetpack releases, as well as desktop GPUs):
and wayland hang/crashes:
How long it will be?
We don’t have a date planned yet for EOL of the JetPack 4.6.x codeline.
Can I assume that the EOL of JetPack 4.6.x will be the same as a Ubuntu 18.04 EOL?
I don’t necessarily believe that to be the case, as stated we don’t have an EOL planned for JetPack 4.6.x
These platforms as of now do get support from nVidia - but in form of upstreaming (to linux kernel etc.). Actually you can run Ubuntu 20.04 with v4.9.x kernel with the BSP from latest Jetpack 4.6 (but need to adjust config / and hack a few things) - currently running this w/o issues.
Ubuntu 22.04 will need upstream kernel at this point. Upstream kernel (5.15+) does get an open-source GPU driver (host1x) but I haven’t tested that yet.
If you’re not familiar with Linux kernel internals, check out armbian (runs on nano with upstream kernel).
see my linked issues… both of these are BSP issues with all released versions (r32.X, r34.X, and r35.X). These are not kernel issues, they are both issues with nvidia’s closed source proprietary userspace drivers.
also, the BSP does NOT function 100% on 20.04. cuda does not work unless you do modifications. the nvidia gstreamer plugins are not compatible with the gstreamer version in focal (resulting in seeking being broken), among other issues.
22.04 also will never work with jetpack r32.X unless nvidia updates the BSP xorg drivers to be compatible with ABI 21.X
part from what you have been told, I add my discontent compared to other odroid boards, rpi4 or adreno chips in which you can have Multilib run 32bits and 64bits without problem and easy run with mainline support.
You are wasting a bit of time to bring it up to date with “Hackly” without real fixes and the L4T structure is not at all portable.
Some stuff nvidia-l4t are broken for example nvidia-l4t-weston can’t load under Ubuntu 20.04 conexion reset broken probably with recent wayland versions with weston 6.0 in 32.x jetpack.
The drivers L4T unfinished under wayland see How status working Wayland with the curret Jetpack 32.6/32.7+ - #6 by DaneLLL
Only work for OpenGL but not for Vulkan.
For not working Wayland correctly cause some errors when run with X11 with l4t driver eglinfo under X11 error failed Aethersx2 some issues with Nvidia tegra driver
Switch session to wayland + Tegra udrm under Ubuntu 20.04 can prevent this error only affected by l4t it’s working on all mesa3d drivers with opengl es 3.2 / opengl 4.6 or vulkan 1.1 minimal (recommended some extensions in vulkan 1.3 spec for better perfomance)
There is a lot of work to do and I no longer tell you to install the drivers outside of Ubuntu
Or the official debs cannot be installed on debian by default because they have dpkg zstd compression and debian dpkg np supported zstd .
Compared to the PC nvidia installer .run installation system that you can install on any distro with almost no problems
Here you are tied to Ubuntu having canonical instability in many aspects with broken libraries or packages without testing there are binaries that you have to recompile as SDL2 or QT5/qt6 for corrected flags or newer functions (qt6 only available official under ubuntu 22.04) mandatory recompile or needed ppa , vulkan headers very old 1.1.70 due ubuntu 18.04 needed rebuild vulkan-headers make install .
So there are so many things that it doesn’t make sense to rely on 18.04 only at this point several ppa needed and waitng time and the very old libc it’s hard “fix” without update .
I manually updated my install from 18.04 to 20.04… then to 22.04 with some work. I have supported x11 (not using GUI though) and the NVIDIA 4.9 Tegra kernel. I needed the newer libs. It’s running stable and fine as is, however, long run it will not be workable. Not sure what to do next from here.
You can update the problem is that everything works without breaking
For example tegra udrm may stop working on Ubuntu 22.04 required for Wayland and the current standards for some applications.
Cuda 10 not working with higher than GCC8 .
The Graphics l4t tegra driver sometimes has some weird bugs that cause segment fault without debug because the libs have no symbol debug and don’t happen on other devices (Rpi4 , adreno with freeadreno or mali gpu )
Also Qualcomm Adreno 650+ mostly done for mainline Vulkan 1.3 support and partially done for rpi4 https://mesamatrix.net/
There is no support for TX1 and lack and needed for current/future development.
And yes, you quite right in the long run development this is sustainable
If nvidia were smart it would give full support in linux to standadrd install to all distributions these boards as a PC for daily use and would compete in the market that Apple has done with M1/m2.
These boards have potential you need to file the correct flexible support
Using as my “best pi” SBC right now and hosting services. The GPU is not utilized but the fast memory and decent CPU is working for me with 22.04. Yes as soon as something better comes along I will replace it. I’m not sure it wil be NVIDIA unless they intend to have active dev and open more community support. This is why I don’t like buying non-RPi boards but figured wouldn’t be an issue with NVIDIA. :/
Been using my Apple Silicon machine for newer ARM dev and using the Apple-optimized build of Tensor for what I used the nano for before.
This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.