32 Bit ARM support on newer dev boards (like Nano, Xavier)

Let’s say I have some code that can’t compile for ARM64 without a significant development effort, but can compile on 32 Bit ARM and work fine.

Now I want to take that code and compile on a Jetson Nano (I’ve done this by pulling an armhf gcc compiler) – This is all possible, I’ve compiled 32 bit binary on the Nano.

Now, how do I run it? Like, specifically on the Nano assuming I have a JetPack version R32.2 installed, how do I reconfigure the system to run the 32 bit binaries I built?

Can I use an older Jetpack version on a Nano/Xavier that would enable AArch32 mode in some way? I hear that R24.1 still fully supported 32 bit stack.

I’ve seen some alluding to installing ‘foreign architecture support’ like this dpkg --add-architecture armhf then apt-get update – but this gives an error when pulling packages from nvidia website (sorry, don’t have the exact error code at this time, couldn’t copypaste it) – and I’m not even sure if this method is supposed to technically be supported.

Is there another way to just redo the whole userspace on a Nano/Xavier to be completely 32 bit? What would be the starting point to installing a 32 bit rootfs?

The nearest forum answer I can find is from here (but it seems rather dated now and I don’t know how to feasibly implement the approaches suggested on my dev boards)

https://devtalk.nvidia.com/default/topic/1024791/jetson-tx2/build-run-32bit-application-on-tx2/

Your thoughts are appreciated! Cheers -AD

I’m getting this error when running dpgk --add-architecture armhf then apt-get update:

Reading package lists... Done
N: Skipping acquire of configured file 'main/binary-armhf/Packages' as repository 'http://international.download.nvidia.com/jetson/repos/common r32 InRelease' doesn't support architecture 'armhf'
N: Skipping acquire of configured file 'main/binary-armhf/Packages' as repository 'http://international.download.nvidia.com/jetson/repos/t210 r32 InRelease' doesn't support architecture 'armhf'
1 Like

Yup same one I got… anyone ever deal with this issue?

After many lib installs…
possibly libc6-dev-armhf?

Got this fixed by:

cp /usr/arm-linux-gnueabihf/lib/ld-linux-armhf.so.3 /lib/

then running the 32 bit binary by using:

LD_LIBRARY_PATH=/usr/arm-linux-gnueabihf/lib/ ./BinaryFileName
1 Like

Indeed, so assuming I have a binary which looks like in terms of ld and libraries it needs (example below is showing how it links on desktop):

ldd myexecutable
	linux-vdso.so.1 (0x00007ffd19733000)
	libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f1c8ad13000)
	/lib64/ld-linux-x86-64.so.2 (0x00007f1c8b345000)

This structure has to be replicated on the arm64 target by having a 32 bit compatible version of ld in /lib/ … then also point to libc.so.6 which on the arm jetpack, after apt installing libc6-dev-armhf-cross on the Ubuntu system should have /usr/arm-linux-gnueabihf/lib/libc…so.6. This is when you override default arm64 .so’s by using LD_LIBRARY_PATH=/usr/arm-linux-gnueabihf/lib …

Sweet, this does work on latest Jetpack as of today (version 4.2.2 from Nvidia website on Jetson Nano!)

In my case, they are

libc6-dev-armhf-armel-cross
libstdc++-6-dev-armhf-cross