Re: armhf kernels on arm64 hardware
On Fri, Jul 15, 2022 at 9:55 PM Lennart Sorensen
<lsorense@csclub.uwaterloo.ca> wrote:
> On Fri, Jul 15, 2022 at 05:13:33PM +0100, Wookey wrote:
> > Ah thanks Paul. I was wondering why we were being accused of 'Debian
> > abandonning armhf' when it was news to me, and I'm just writing the
> > 'ARM ports status' talk for Debconf next week.
> >
> > Clearly one normally does not run foreign-arch kernels on hardware so
> > we don't have to support it, and Ben is right to say 'this is not a
> > bug'.
> >
> > On the other hand, if the armhf kernel does work on RPi4 with a few
> > config options, and there is an actual use case, then the question is
> > what is the downside of enabling the config options?
> >
> > Does this only work for the RPi4, or does it enable/prevent 32-bit kernels on other 64-bit machines?
>
> Certainly people have been running 32 bit kernels on the Pi 3 and 4 and
> it works fine. Some high end aarch64 CPUs don't support 32 bit mode,
> but that is certainly not the case for the Pi's CPU.
>
> > Do i386 kernels work on amd64 machines?
>
> Yes, but... They certainly don't work with more than 3.5GB or so of ram
> unless you use the pae version of the kernel then you can have some more.
> There have been issues in some cases with systems that had too much ram
> where rather than just ignoring it the kernel would fail to boot.
This is exactly the same situation on arm as on x86: without an (L)PAE-enabled
kernel, only the low (device specific) few GB are accessible, anything at
a higher physical address than 4GB disappears completely.
I don't know how much of the memory this affects on bcm2711, but at least
for the 8GB Raspberry Pi there is no point running with the default (non-LPAE)
kernel.
The other issues with running 32-bit kernels are also similar to x86:
- many new features are only added on 64-bit kernels or are only available
in 64-bit mode, so running a 32-bit kernel is less secure
- errata workarounds for newer CPU cores are often missing, and
the 32-bit kernel doesn't even officially support armv8 hardware,
though it mostly works in practice.
- virtual address space is somewhat more limited, with usually 3GB
(sometimes less) in 32-bit kernels, but the full 4GB for 32-bit processes
on 64-bit kernels.
- running with highmem is generally no fun, so anything above 768MB
of physical RAM can not easily be used. highmem support will eventually
go away. We have plans to still support up to 4GB of physical memory
using a new memory layout at a performance penalty for extra page table
switches.
> Of course it was very common a 15 or 20 years ago to run debian i386 with
> an amd64 kernel and was fully supported by debian including the installer
> which as far as I remember even recommended that kernel if supported by
> the host. Quite a bit of user space code still had issues with 64 bit,
> but you got to run a kernel that could take full advantage of your ram
> and other cpu features, while running 32 bit user space (since the amd64
> kernel of course can run i386 binaries just fine).
>
> For example this was very much in Debian:
> http://snapshot.debian.org/archive/debian/20050312T000000Z/pool/main/k/kernel-image-2.6.9-amd64/kernel-image-2.6.9-9-amd64-generic_2.6.9-4_i386.deb
Ah right, I forgot about that and only remembered the MIPS ones that
still do this.
> So an amd64 kernel in the i386 archive.
>
> > Sounds like something that might be worth discussion at debconf next week. I'll mention it in the talk.
>
> Well it would essentially mean treating arm like i386 used to be treated.
> It is certainly not a thing Debian hasn't supported before.
This probably also requires a 64-bit grub in addition to the kernel, but
should otherwise not be too difficult. In particular, I would hope that
the build infrastructure for the kernel package can be adapted so it builds
a near-identical image to the normal arm64 kernel package and not
require extra regression testing.
Arnd
Reply to: