On Tue, Dec 8, 2020 at 10:09 PM Lennart Sorensen
<lsore...@csclub.uwaterloo.ca> wrote:
>
> On Tue, Dec 08, 2020 at 09:53:11PM +0100, Arnd Bergmann wrote:
> > I wonder if this is something we should address in the kernel, and make
> > the behavior in compat mode resemble native 32-bit kernels more closely.
> >
> > I think in general we should give as much incentive as possible for
> > using 64-bit kernels even when running legacy user space, in
> > particular as the 32-bit kernel is also missing some pieces for
> > running 32-bit user space on 64-bit hardware.
> >
> > Right, most importantly, the ones that do not work include
> >
> > - ThunderX
> > - ThunderX2
> > - Apple M1
> >
> > while the ones that do have aarch32 mode include
> >
> > - All Ampere servers
> > - Amazon EC2
> > - NXP LX2160, as used in Solidrun LX2K machines
> > - All other Cortex-A72 and A76 based servers
>
> But does aarch32 mode imply full support for armv4 instructions?
> armhf at armv7 should be fine I would think, but is armel still v4 or did
> it move to v5? I can't remember. At least it appears the kernel has
> options for emulating things like SWP and SWPB if they are missing.
> Perhaps the future for armhf and even armel isn't totally hopeless.
I'm fairly sure it does work for little-endian, but it would not work
if there was a big-endian port, since the old be32 instruction format
was incompatible. For even older (armv3? don't remember which)
binaries, there would also be a problem with emulating the unaligned
accesses, which did not trap but instead had different behavior.
Arnd
