L4T sources have not included 32-bit (armhf) userspace libs since like r24, when single-target armhf libs were available and could be used in a chroot or pure 32-bit userspace. Unfortunately, this means no native hw acceleration for armhf-only apps or x86 translation. The AGX Orin is powerful enough to handle x86_64 translation quite well, but its x86 translation is crippled by this lack of 32-bit userspace libs. Many (albeit poorly written) applications are built only for armhf or for x86, and the ability to achieve native hw acceleration in these apps via multiarch or in a chroot would be incredibly beneficial for customers like myself attempting to run 32-bit applications on L4T. Multilib userspace libs compatible with aarch64 and armhf would be perfect, but if this is not possible, 32-bit standalone libs would be helpful in place of multilib, similar to r24.
The architecture itself changed from armhf/ARMv7-a to arm64/aarch64/ARMv8-a. The ARMv8-a specification does include a compatibility mode which works with ARMv7-a instructions, and includes NEON. This is 100% present in this hardware. In order to use this though the CPU has to be in that compatibility mode, and you’d have to also install any user space 32-bit software if needed (a kernel driver would not need this, user space software would). You can expect terrible performance.
Something you’d probably end up doing if you plan to just use 32-bit armhf software directly would be to install 32-bit linker and library support. This would be in parallel to the 64-bit software, and not as a replacement. I’m not sure of what all would be required, but it would not be easy or quick. 32-bit is actually considered crippling to 64-bit users since it would nearly double the required eMMC space used, and very very few people would use it. What is usually done is to port the older ARMv7 application to ARMv8 via what would mostly be a recompile (there might need to be actual source code changes if hardware-specific code is involved, e.g., if NEON or Thumb2 is used).
Incidentally, R24.x was the first release of any ARMv8 hardware and software. Previously there was nothing but ARMv7 hardware. This was the transition, and the kernel was still mostly ARMv8/64-bit, but I remember a vdso feature in the kernel was still running 32-bit. The user space had poor performance, but most of that was running in compatibility mode. Most of that software was simply recompiled to run 64-bit, which is by far the better method versus adding a lot of 32-bit library support.
I am well aware of the architectures lol. What I am talking about is what you were saying in the second paragraph to a degree. Of course if you get a 32-bit linker and lib it works, but there are no 32-bit userspace libs provided by nvidia, meaning yes you can run programs and possibly use some form of indirect rendering or software rendering, but no hardware rendering. In r24.x, for SoC’s like t210 (also aarch64), there were in fact nvidia-provided proprietary userspace libs compiled for armhf that allowed a user to run 32-bit apps with hardware rendering and acceleration in a chroot. Ideally, there would be some form of multilib like the x86/x86_64 driver packages, but r24.x just had standalone 32-bit libs in addition to the 64-bit libs. I do not mean run a fully 32-bit userspace or some compatability mode–just that there should be 32-bit libs or multilib for the NVIDIA proprietary GPU libs for applications or translation layers available only for 32-bit platforms. It would not even have to be installed by default, but the libs should be available for download. I apologize if my initial message or thread title was misleading.
Sorry to tell there is no plan to support 32bits userspace.
In theory you could use the 32-bit armhf libs and linker provided by Ubuntu if you were to add this to the
apt repository search list. The trick is that you shouldn’t replace anything with this, and would want to only add this content. I’m sure there would be a lot of glitches to get past, but in theory the
armhf linker and libs of Ubuntu 20.04 armhf could be added directly in package format from the Ubuntu repository. Make sure to back up first though as there is a good chance it won’t go smoothly.
This is not correct. Given that there does not exist a repository or even a tarball including NVIDIA armhf gpu driver userspace libs, no I could not in fact do that. Of course I could install armhf libs and linkers for various programs etc…but not for the NVIDIA libs. Which means of course, as I said previously, the 32-bit programs would run, but there would be no hardware acceleration etc… There do not exist such libs compatible with any kernel drivers past r24, which is not compatible with the Orin series and misses many features. I am not requesting anything except that NVIDIA release the 32-bit userspace libs for their gpu drivers, compatible with the latest r34 kernel driver, since there exist 0 32-bit userspace libs of this variety, and there do not exist sources so one could build them. You cannot add what doesn’t exist, and I’m asking for this to exist. Running 32-bit applications with software acceleration only is a waste. kayccc has informed us that these 32-bit libs are not planned.
armhf video driver would not be needed for most user space applications, but only for GPU applications. However, the GPU driver which was from L4T R24.x 32-bit is quite old. You could copy this from the rootfs of that release, and it would complete the ability to use the GPU (is is the sample rootfs after running “
sudo ./apply_binaries.sh”…the driver is in fact there). I do however wonder if this will conflict with the 64-bit setup…it seems likely there would be some conflict unless the 64-bit Xorg server and GPU driver were removed (it might work, I don’t know). However, the linker and system libraries for user space should be ok from the Ubuntu 20.04 armhf for just the 32-bit compatibility.
Note that the binary-only release back then is tied to a specific Xorg ABI. There is no possibility it would work with the most recent Xorg ABI. Similarly, there is no possibility that the current driver Xorg ABI would work with the older server. You might be able to find a way to run both, although it’d be one at a time I think, and it isn’t really worth the effort for most people. We’re talking about a driver that is around 8 years old.
There is a lot which breaks when you try to use a previous release of software with the current L4T release. There is not a lot which can be done about that since back then a lot of content was simply copied in via a tar archive and not available via a package. However, the CPU architecture should not require anything different for linker and user space libraries…it is the Xorg server which is an issue for that specific library, and not the Ubuntu linker.
Of course what I was requesting was to be able to use the GPU from 32-bit contexts. You seem to be fundamentally misunderstanding my request. I am well aware of how to utilize a chroot and most 32-libs to form a standalone 32-bit userspace within the OS. I am also quite well aware of the r24 libs and that they are not compatible, which was why I mentioned that several times, which is why I have been asking for 32-bit GPU driver userspace libs. You are purely telling me things that I stated originally. If there were another actual solution for the problem I am asking for a solution to, I would have done it already. Unfortunately, the only actual solution would be for NVIDIA to actually release armhf binaries. This would not be that difficult, and has been done before as seen in r24.x, but NVIDIA has decided not to continue to support this. Hence I have asked for it to be supported. Given that we have been told this is not happening, the answer is “no, the libs don’t exist and never will.” You do not have to tell me that the 8-year-old drivers for X1 etc. are incompatible, as I did in fact say that in the initial post.
BTW, the r24 libraries are certainly not compatible with the Jetson Orin line (t234), given the highest Tegra revision they supported to my knowledge was t210. They are compatible with thee 20.04 xorg ABI however, so none of that is an issue. The request was purely for NVIDIA to distribute 32-bit gpu userspace drivers for usage in 32-bit contexts, like a chroot for armhf or chroot + box86 for x86.
There is no GPU lib for the current Ubuntu 18.04/20.04 generation in 32-bit armhf (I do understand the original question, but am only able to point out the obstacles or the possibilities of working around the obstacles). It doesn’t exist. It is up to NVIDIA if they want to develop a 32-bit user space for ARMv8-a on Orin, but they’re previously stated they have moved to 64-bit. I don’t think getting new 32-bit is an option.
I don’t remember the details, nor do I remember if this applied only to desktop PC discrete GPUs, but I did read somewhere that NVIDIA was beginning to open source some of the previously closed source GPU driver code. It wouldn’t work on an iGPU unless the driver is specific to a Jetson with its integration to the memory controller, but maybe NVIDIA could comment on if there will be an open source available now (or in the near future) from which you could compile your own version. I don’t see any other possibility.
It is only rhetorical, but I would have to ask if you absolutely must use the 32-bit software since this is unlikely.
I do know what the obstacles are and was just hoping they would release the 32-bit-compiled libs. This would require no dev time, given armhf is already a buildable target internally and it should just be a minor
make command alteration, but they have expressed an unwillingness to release them unfortunately. I do have 32-bit-only software I’d like to run, and if I didn’t, I would have not made this thread to begin with.
For reference, your second paragraph is incorrect. There is an OSS official GPU driver, but it is the kernel driver and not the userspace libs. One of the source releases available in the L4T package does work on Jetson (Orin and up), but again, does not include source for the proprietary userspace libraries I’d need for acceleration to work. There is of course no other option for any of this to work, unless there is a plan to release sources for the userspace libs (@kayccc can you comment?). I do appreciate your recommendations for other options, but unfortunately there are none in this scenario.
AFAIK, there is no plan to support 32 bits userpace, all source packages we provided can be found at the release page, there is no other source release than those.
This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.