[PATCH 18/21] ARM: drop SMP support for ARM11MPCore

[Arnd Bergmann]

On Thu, Mar 30, 2023, at 13:28, Joel Stanley wrote:
> On Mon, 27 Mar 2023 at 12:18, Arnd Bergmann <arnd at kernel.org> wrote:
>
>> Take the easy way out here and drop support for multiprocessing on
>> ARMv6, along with the CONFIG_DMA_CACHE_RWFO option and the cache
>> management implementation for it. This also helps with other ARMv6
>> issues, but for the moment leaves the ability to build a kernel that
>> can run on both ARMv7 SMP and single-processor ARMv6, which we probably
>> want to stop supporting as well, but not as part of this series.
>
> Why's that? I currently build a kernel for the ast2600 (dual core
> cortex a7) and ast2500 (arm1176).

There are actually three generations of ARMv6:

- "armv6" arm1136r0, in practice only omap2 and i.mx31
- "armv6k" arm1136r1 and arm1176, common in ast2500, bcm2835,
  i.mx35, and s3c64xx
- "armv6k" arm11mpcore in oxnas and realview

The early armv6 ones are halfway between armv5 and armv6k, which
causes a number of problems:

- cannot use 8-bit and 16-bit sub-word atomics (strexh etc) and
  double-word atomics (strexd) that may be needed by some drivers

- need to use cp15 barriers instead of isb/dsb etc, which
  breaks compatibility with armv8 hardware in a multiplatform
  kernel

- missing TLS register requires horrid workarounds for
  CURRENT_POINTER_IN_TPIDRURO.

- Running an SMP-enabled kernel on armv6 requires SMP_ON_UP
  (this is also required for at least one ARMv7 SoC)

One idea that we have discussed as a long-term solution for
all of the above would be to change support for armv6 from
being compatible with armv7 to being compatible with armv5.

arm11mpcore is currently tied to armv7 because of SMP support,
but once we drop SMP support for it, we have more freedom
and can move armv6 and armv6k uniprocessor support together
with armv5. I already did an initial patch last year, but it
needs more work to ensure that it correctly addresses
everything that currently assumes that armv6 cannot coexist
with older cores in the same kernel.

If this works out, we'll be able to have a combined ast2400/
ast2500/omap1/omap2/imx2/imx3 kernel separate from ast2600/
omap3/imx5, but hopefully not more kernels that anyone needs
to test. For Debian, this would allow armel to ship a combined
kernel for Raspberry Pi and the ARMv5 parts in place of the
two separate kernels it currently has, but it's not clear
there will actually be another Debian armel release after
Bookworm.

    Arnd