8

I just got my hands on a Raspberry Pi 3 and I would like to start experimenting on it, specially regarding the 64-bit instruction set.

I'm well aware of the pros and cons of the 32-bit versus the 64-bit instruction set, so please stick to the original question: Is it possible to run a 64-bit kernel utilizing the current 32-bit user space applications?

It is enough to compile the kernel with 64-bit compiler and upload the image to RasPi or are there any other steps involved that I should be aware of? Could you possible give me a high level overview of what should I be looking at as a roadmap? Like, modules/drivers that could/will break if I install the 64-bit kernel. Do I need to recompile everything?

Browsing the internet I know it's possible for some other classes of devices, and that usually running this "hybrid" configuration would break the package managers, but I'm not worried by manageability at this moment. So even if it breaks package managers and it's a hell to maintain I would like to understand how it's done.

Please be aware that I'm still learning how to compile the kernel, but still I have experience developing C/C++ applications for a long time. This is my pet project to have a deep understanding of linux architecture and kernel internals.

jdonald
  • 2,904
  • 12
  • 39
  • The dragonboard 410c use the same processor arm64 bit and have an ubuntu customized by linaro. –  Mar 23 '16 at 14:15

3 Answers3

3

Is it possible to run Raspberry Pi 3 with a 64-bit kernel and 32-bit user space?

Yes. Some pre-built images have this ready to go:

usually running this "hybrid" configuration would break the package managers, but I'm not worried by manageability at this moment. So even if it breaks package managers and it's a hell to maintain

It's not practical to use multiarch with Raspbian as it does not have 64-bit upstream packages, and the closest 64-bit relative (Debian arm64) has incompatible package versions. To run 64-bit programs under Raspbian you may use static binaries, containers (LXC, systemd-nspawn), or chroot[1]. Such isolation avoids typical package conflicts inherent in mutiarch.

You need not recompile anything because binaries for all of the above (Raspbian 32-bit userland, 64-bit kernel, Debian arm64 userland packages) are readily available.

Like, modules/drivers that could/will break if I install the 64-bit kernel.

At the time of writing the SoC camera, accelerated video decode with MMAL, and high-speed USB support (via FIQ) are known to be broken under Raspberry Pi 64-bit kernels.

[1] See 64-bit OS on Raspberry Pi 4 for instructions on how to create such a chroot.

jdonald
  • 2,904
  • 12
  • 39
2

Sure, it's possible. 64-bit operating systems do it all the time*. It happens when you're on a 64-bit OS and you open up a 32-bit app (aka 32-bit user space application).

But sometimes, there may be issues with libraries/dependencies. I once encountered an error on a PC, something about wrong ELF class. Solved by installing the appropriate 32-bit library ia32-libs.

I'm not quite sure how this would behave on an ARM machine since there's no official 64-bit kernel for the Pi that I can play with (yet).

Also, one does not simply compile the kernel with a 64-bit compiler the upload it on the Pi. If it was that simple, we would be already running the Pi 3 with a 64-bit kernel.

Aloha
  • 7,136
  • 1
  • 28
  • 52
  • +1 Windows makes this very obvious with the program files division. 64-bit applications are stored in C:\Program Files, and 32-bit applications are stored in C:\Program Files (x86). – Jacobm001 Mar 23 '16 at 16:14
  • 2
    @Jacobm001 There's a more subtle difference with Windows. In Linux, you simply needed the appropriate 32-bit libraries. For Windows, there are technically two Windows versions installed on your PC: the 32-bit version, which is stored in SysWOW64, and the 64-bit, which is stored in system32. Windows identifies the executable and makes it so that the 32-bit app sees SysWOW64 as system32. Same happens with Program Files and the registry. 32-bit apps see C:\Program Files (x86) as just plain C:\Program Files but any changes to it go to C:\Program Files (x86). – Aloha Mar 24 '16 at 06:52
  • 1
    @Jacobm001 I'm fun at parties. – Aloha Mar 24 '16 at 06:54
2

You need both sets of libraries and both architectures compiled against the right libraries, so 2 build environments. Look up multi arch and your prefered bsse to get pointers. Like

https://wiki.debian.org/MultiarchCrossToolchainBuild

So you would need to do something like that but in the Rasbian space. So building an arm64 kernel and armhf user land and both sets of libraries properly linked for each.

Here you can see someone doing it on a different board:

https://groups.google.com/forum/#!topic/linux.debian.ports.arm/ankucgztcI8

And see their experiences.

E.M.Smith
  • 29
  • 1