arm64: Kconfig: Make CPU_BIG_ENDIAN depend on BROKEN
Will Deacon
maintainerPATCH 1/1 arm64: Kconfig: Make CPU_BIG_ENDIAN depend on BROKEN
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'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(-)
arch/arm64/Kconfig +1 -1
@@ -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.
Signature · 1 line
2.51.0.470.ga7dc726c21-goog
Quoted 26 lines · Will Deacon
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_ENDIANdepend on BROKEN as an initial deprecation step towards its removal.Cc Catalin Marinas <[email protected]>Cc Marc Zyngier <[email protected]>Cc Ard Biesheuvel <[email protected]>Cc Arnd Bergmann <[email protected]>Cc Hanjun Guo <[email protected]>Cc Jonathan Cameron <[email protected]>Cc Guenter Roeck <[email protected]>Signed-off-by Will Deacon <[email protected]>
Quoted 2 lines
---
Quoted 25 lines
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(-)arch/arm64/Kconfig +1
-2@@ -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
Quoted 17 lines · Will Deacon
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_ENDIANdepend on BROKEN as an initial deprecation step towards its removal.
Quoted 9 lines
Cc Catalin Marinas <[email protected]>Cc Marc Zyngier <[email protected]>Cc Ard Biesheuvel <[email protected]>Cc Arnd Bergmann <[email protected]>Cc Hanjun Guo <[email protected]>Cc Jonathan Cameron <[email protected]>Cc Guenter Roeck <[email protected]>Signed-off-by Will Deacon <[email protected]>
It's about time.
M.
Signature · 1 line
Jazz isn't dead. It just smells funny.
Quoted 16 lines · Will Deacon
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_ENDIANdepend on BROKEN as an initial deprecation step towards its removal.
Quoted 9 lines
Cc Catalin Marinas <[email protected]>Cc Marc Zyngier <[email protected]>Cc Ard Biesheuvel <[email protected]>Cc Arnd Bergmann <[email protected]>Cc Hanjun Guo <[email protected]>Cc Jonathan Cameron <[email protected]>Cc Guenter Roeck <[email protected]>Signed-off-by Will Deacon <[email protected]>
Quoted 25 lines · Will Deacon
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_ENDIANdepend on BROKEN as an initial deprecation step towards its removal.Cc Catalin Marinas <[email protected]>Cc Marc Zyngier <[email protected]>Cc Ard Biesheuvel <[email protected]>Cc Arnd Bergmann <[email protected]>Cc Hanjun Guo <[email protected]>Cc Jonathan Cameron <[email protected]>Cc Guenter Roeck <[email protected]>Signed-off-by Will Deacon <[email protected]>
Quoted 4 lines
---
Cc'ing Guenter as a heads-up in case he needs to turn down his testing to avoid this causing a false regression report.
Cool, one more architecture to drop. I wonder if I should drop arm64 big endian testing for all kernel releases. That would simplify my test infrastructure substantially, and it would avoid useless regressions due to bitrot for older kernel releases if no one is using it anyway. Thoughts ?
Thanks,
Guenter
Quoted 20 lines
Cc'ing Hanjun and Jonathan for clarity on the telecommunication situation.
arch/arm64/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)arch/arm64/Kconfig +1
-1@@ -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.
Will Deacon
maintainerQuoted 28 lines · Guenter Roeck
Quoted 27 lines · Will Deacon
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_ENDIANdepend on BROKEN as an initial deprecation step towards its removal.Cc Catalin Marinas <[email protected]>Cc Marc Zyngier <[email protected]>Cc Ard Biesheuvel <[email protected]>Cc Arnd Bergmann <[email protected]>Cc Hanjun Guo <[email protected]>Cc Jonathan Cameron <[email protected]>Cc Guenter Roeck <[email protected]>Signed-off-by Will Deacon <[email protected]>---
Quoted 7 lines
Quoted 2 lines
Cc'ing Guenter as a heads-up in case he needs to turn down his testing to avoid this causing a false regression report.
Cool, one more architecture to drop. I wonder if I should drop arm64 big endian testing for all kernel releases. That would simplify my test infrastructure substantially, and it would avoid useless regressions due to bitrot for older kernel releases if no one is using it anyway. Thoughts ?
It's entirely up to you, but I'd suggest leaving it running until 6.18 is out and then turning it all off if nobody has chimed in to say they're using this stuff.
Will
Quoted 32 lines · Will Deacon
Quoted 31 lines · Guenter Roeck
Quoted 29 lines · Will Deacon
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_ENDIANdepend on BROKEN as an initial deprecation step towards its removal.Cc Catalin Marinas <[email protected]>Cc Marc Zyngier <[email protected]>Cc Ard Biesheuvel <[email protected]>Cc Arnd Bergmann <[email protected]>Cc Hanjun Guo <[email protected]>Cc Jonathan Cameron <[email protected]>Cc Guenter Roeck <[email protected]>Signed-off-by Will Deacon <[email protected]>---
Cc'ing Guenter as a heads-up in case he needs to turn down his testing to avoid this causing a false regression report.
Quoted 9 lines
Quoted 4 lines
Cool, one more architecture to drop. I wonder if I should drop arm64 big endian testing for all kernel releases. That would simplify my test infrastructure substantially, and it would avoid useless regressions due to bitrot for older kernel releases if no one is using it anyway. Thoughts ?
It's entirely up to you, but I'd suggest leaving it running until 6.18 is out and then turning it all off if nobody has chimed in to say they're using this stuff.
Makes sense. I'll do that.
Thanks,
Guenter
Quoted 9 lines · Will Deacon
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.
[...]
Applied to arm64 (for-next/misc), thanks!
[1/1] arm64: Kconfig: Make CPU_BIG_ENDIAN depend on BROKEN
https://git.kernel.org/arm64/c/1cf89b6bf660
Cheers,
Signature · 5 lines
Will https://fixes.arm64.dev https://next.arm64.dev https://will.arm64.dev
Hi Will,
Quoted 25 lines · Will Deacon
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_ENDIANdepend on BROKEN as an initial deprecation step towards its removal.Cc Catalin Marinas <[email protected]>Cc Marc Zyngier <[email protected]>Cc Ard Biesheuvel <[email protected]>Cc Arnd Bergmann <[email protected]>Cc Hanjun Guo <[email protected]>Cc Jonathan Cameron <[email protected]>Cc Guenter Roeck <[email protected]>Signed-off-by Will Deacon <[email protected]>
Quoted 7 lines
---
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.
Sorry for the late reply, the current products are still using the ARM64 big-endian architecture on Linux, but the future evolution will not.
It will take quite a while (for years) for the end of the product life cycle, please keep it as BROKEN.
Thanks
Hanjun
Quoted 8 lines · Will Deacon
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.
Quoted 7 lines
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_ENDIANdepend on BROKEN as an initial deprecation step towards its removal.
As of this month (September 2025) there's a new community project [1,2] to revive aarch64_be. Jens Reidel (CC'd) and I are involved in it. We've been fixing several aarch64_be-related bugs, but mostly[3] in userspace, because the kernel support is pretty solid.
So, just so it doesn't go unmentioned, there is interest in keeping big-endian ARM64 alive.
Best regards,
J. Neuschäfer
[1]: https://aarch64.be/ (binary packages)
[2]: https://codeberg.org/neuschaefer/porting/src/branch/main/aarch64_be.md
(status and documentation)
[3]: https://lore.kernel.org/lkml/[email protected]/
Catalin Marinas
maintainerQuoted 17 lines · J. Neuschäfer
Quoted 8 lines · Will Deacon
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.
Quoted 7 lines
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_ENDIANdepend on BROKEN as an initial deprecation step towards its removal.
Quoted 7 lines
As of this month (September 2025) there's a new community project [1,2] to revive
aarch64_be. Jens Reidel (CC'd) and I are involved in it. We've been fixing several aarch64_be-related bugs, but mostly[3] in userspace, because the kernel support is pretty solid.So, just so it doesn't go unmentioned, there is interest in keeping big-endian ARM64 alive.
It's nice to see it gets testing but is there any actual beyond you and Jens (i.e. in production somewhere like Huawei's case)? We want to assess whether it's worth the kernel maintenance and testing hassle and for how long.
Signature · 1 line
Catalin
Quoted 23 lines · Catalin Marinas
Quoted 22 lines · J. Neuschäfer
Quoted 8 lines · Will Deacon
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.
Quoted 7 lines
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_ENDIANdepend on BROKEN as an initial deprecation step towards its removal.As of this month (September 2025) there's a new community project [1,2] to revive
aarch64_be. Jens Reidel (CC'd) and I are involved in it. We've been fixing several aarch64_be-related bugs, but mostly[3] in userspace, because the kernel support is pretty solid.
Quoted 7 lines
Quoted 2 lines
So, just so it doesn't go unmentioned, there is interest in keeping big-endian ARM64 alive.
It's nice to see it gets testing but is there any actual beyond you and Jens (i.e. in production somewhere like Huawei's case)? We want to assess whether it's worth the kernel maintenance and testing hassle and for how long.
We don't have any commercial or large deployments, no. It's currently one build host and manual testing on additional machines.
I'd be sad to see big-endian arm64 support removed because it's an opportunity to test for endian-related bugs (in various packages, not just the kernel) on widely available and reasonably fast hardware.
I understand the maintenance cost argument, and I'm fine with the CONFIG_BROKEN dependency, even if it might be applied to features that cause problems in the future (such as nested virt) — it's easy to work around, and features can be fixed as needed. A complete removal will likely be harder to revert, though, especially once code simplifications are made based on supporting only little-endian. That's my concern.
Best regards,
J. Neuschäfer
Quoted 5 lines · J. Neuschäfer
I understand the maintenance cost argument, and I'm fine with the
CONFIG_BROKENdependency, even if it might be applied to features that cause problems in the future (such as nested virt) — it's easy to work around, and features can be fixed as needed.
Not really. Cross-endianness support is completely incompatible with nested virt *by design*, and can't be worked around by SW. You'd need to introduce incompatible changes in the architecture to support this.
Yes, this is a shame, but also a sign that architecture and implementations have moved on.
M.
Signature · 1 line
Without deviation from the norm, progress is not possible.
Quoted 42 lines · Will Deacon
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_ENDIANdepend on BROKEN as an initial deprecation step towards its removal.Cc Catalin Marinas <[email protected]>Cc Marc Zyngier <[email protected]>Cc Ard Biesheuvel <[email protected]>Cc Arnd Bergmann <[email protected]>Cc Hanjun Guo <[email protected]>Cc Jonathan Cameron <[email protected]>Cc Guenter Roeck <[email protected]>Signed-off-by Will Deacon <[email protected]>---
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(-)arch/arm64/Kconfig +0
-0@@ -1493,7 +1493,7 @@ choice
Quoted 10 lines
config
CPU_BIG_ENDIAN
bool "Build big-endian kernel"
# https://github.com/llvm/llvm-project/commit/1379b150991f70a5782e9a143c2ba5308da1161c
- depends onAS_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.Signature · 1 line
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.