[PATCH] arm64: Kconfig: Make CPU_BIG_ENDIAN depend on BROKEN

[A. Wilcox]

On Sep 19, 2025, at 13:40, Will Deacon <will at kernel.org> wrote:
> 
> Big-endian arm64 configurations are vanishingly rare, yet we still claim
> to support them in Linux despite very limited testing or visible
> interest. Supporting big-endian adds unnecessary burden to reviewers and
> contributors which, without any known active users, is hard to justify.
> For example, recent work to improve our futex routines and to implement
> nested virtualisation support is non-trivially complicated by having to
> support both big- and little-endianness.
> 
> Back in 2019 [1], it was claimed that Huawei were using arm64 big-endian
> machines in their telecommunication products but I don't know whether
> that's still the case and certainly haven't seen any patch contributions
> to help support or maintain it.
> 
> Make CPU_BIG_ENDIAN depend on BROKEN as an initial deprecation step
> towards its removal.
> 
> Cc: Catalin Marinas <catalin.marinas at arm.com>
> Cc: Marc Zyngier <maz at kernel.org>
> Cc: Ard Biesheuvel <ardb at kernel.org>
> Cc: Arnd Bergmann <arnd at arndb.de>
> Cc: Hanjun Guo <guohanjun at huawei.com>
> Cc: Jonathan Cameron <Jonathan.Cameron at huawei.com>
> Cc: Guenter Roeck <linux at roeck-us.net>
> Link: https://lore.kernel.org/linux-arm-kernel/73701e9f-bee1-7ae8-2277-7a3576171cd4@huawei.com/ [1]
> Signed-off-by: Will Deacon <will at kernel.org>
> ---
> 
> Cc'ing Guenter as a heads-up in case he needs to turn down his testing
> to avoid this causing a false regression report.
> 
> Cc'ing Hanjun and Jonathan for clarity on the telecommunication
> situation.
> 
> arch/arm64/Kconfig | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
> index e9bbfacc35a6..5ac670d41604 100644
> --- a/arch/arm64/Kconfig
> +++ b/arch/arm64/Kconfig
> @@ -1493,7 +1493,7 @@ choice
> config CPU_BIG_ENDIAN
> bool "Build big-endian kernel"
> # https://github.com/llvm/llvm-project/commit/1379b150991f70a5782e9a143c2ba5308da1161c
> - depends on AS_IS_GNU || AS_VERSION >= 150000
> + depends on (AS_IS_GNU || AS_VERSION >= 150000) && BROKEN
> help
>  Say Y if you plan on running a kernel with a big-endian userspace.
> 
> -- 
> 2.51.0.470.ga7dc726c21-goog


Hi Will (and others),

We at Wilcox Technologies Inc. have actually laid out multiple
projects and initiatives based on Linux aarch64_be support.  They
aren't yet ready for public release or consumption, but they are
definitely being actively planned and developed.  One of them is a
full port of a Linux distribution.  There have been successful runs
of Gentoo[1] as well.  The musl libc intends[2] support.

What would need to be done to help keep aarch64_be alive in Linux
while we continue our internal work and finish other projects?
Would standing up a CI builder help any?  Are there existing known
issues?  I've personally been experimenting with aarch64_be since
the early 5.x kernel series and I've never found kernel-level bugs,
only userland ones.  The kernel has been solid.

aarch64_be is quite useful to have as it allows developers to have
access to BE hardware "at home" without needing a S390x or PPC64
system that can cost many thousands of dollars.

If it's simply a matter of waiting for our initiatives to launch
to show actual interest and testing, then I can try to advocate for
those initiatives to be started sooner.

In summary, Linux aarch64_be works well on Raspberry Pi 3, RockPro
64, PINE A64, among other SBCs and SoCs.  We are looking forward
to multiple future developments using it and are willing to help
out where and how we can to ensure it is not removed from the Linux
kernel.

Best,
-Anna


[1]: https://github.com/rorybolt/Gentoo-aarch64_be
[2]: https://git.musl-libc.org/cgit/musl/commit/?id=dfc1a37c441fe271dfb19c7de62acadc73e255aa


--
Anna Wilcox (she/her)
SW Engineering: C++/Rust, DevOps, POSIX, Py/Ruby
Wilcox Technologies Inc.