[PATCH 0/3] ARM: Enable IXP4xx to use little endian mode

[PATCH 0/3] ARM: Enable IXP4xx to use little endian mode

[Linus Walleij]

This modifies the boot path for the IXP4xx, the remaining big
endian ARM system, to enable it to be booted into little
endian mode.

Motivation: big endian is less and less supported by the kernel
and for the ARM architecture, IXP4xx is carrying the entire load
since it is booting into big endian by default. After this there
is no currently supported ARM system that cannot be booted in
little endian mode, and the big endian support may be retired,
if so desired.

How this is done:

- Enable the XScale to switch to little endian mode from a big
  endian boot loader just as it can today switch into big endian
  mode from a little endian boot loader.

- This works fine because when we switch endianness all bus
  accesses are also endianness-switched (swap32) and everything
  will keep running as before from memory.

- The object file will boot in big endian mode. This is done
  by padding the file to an even number of bytes and then
  endianness-swap (swap32) the entire binary before it is loaded
  into memory. This means the file will "look as if it is
  big endian" when it starts executing, and the first few
  instrucions up until the endianness switch snippet are
  executed as big endian.

- Workarounds for addressing the last byte in 32bit address of
  the serial port at 0xc8000000 by pointing at 0xc8000003 were
  uniformly dropped. If the system shall actually boot in
  big endian mode again, we need to fix the serial driver
  instead of using this hack.

I did not add the logic to pad and byteswap the image to get a
bootable "big endian" object to the kernel build: just the bare
minimum. The missing pieces are:

  $(Q)size=$$(stat -c%s $(output_dir)/zImage); \
  pad=$$(( (4 - size % 4) % 4 )); \
  if [ $$pad -ne 0 ]; then \
      dd if=/dev/zero bs=1 count=$$pad >> $(output_dir)/zImage 2>/dev/null; \
  fi
  $(OBJCOPY) --reverse-bytes=4 -I binary -O binary zImage zImage-swap32

The resulting zImage-swap32 will boot on a big endian system
and switch itself into little endian mode.

Tested on the IXP4xx Avila platform with a little endian
OpenWrt root filesystem on flash.

Surprisingly all drivers on the IXP4xx appear to work just fine
in little endian mode, due to care taken when authoring them.

Signed-off-by: Linus Walleij <linusw@kernel.org>
---
Arnd Bergmann (1):
      ARM: decompressor: always set endianess on xscale

Linus Walleij (2):
      ARM: ixp4xx: Relax endianness
      ARM: dts: ixp4xx: Drop the reg-offset hack

 arch/arm/boot/compressed/Makefile             |  8 --------
 arch/arm/boot/compressed/big-endian.S         | 14 --------------
 arch/arm/boot/compressed/head-xscale.S        | 12 ++++++++++++
 arch/arm/boot/dts/intel/ixp/intel-ixp4xx.dtsi | 10 ----------
 arch/arm/mach-ixp4xx/Kconfig                  |  5 ++---
 5 files changed, 14 insertions(+), 35 deletions(-)
---
base-commit: aa4ffae4701cc6edf6303bf35c42e24f335d6899
change-id: 20260707-ixp4xx-little-endian-9930bd2f0325

Best regards,
--  
Linus Walleij <linusw@kernel.org>

[PATCH 1/3] ARM: decompressor: always set endianess on xscale

[Linus Walleij]

From: Arnd Bergmann <arnd@arndb.de>

In BE32 configurations, endianess is always set to BE in Control
Register C1, originally to allow booting BE kernels from a LE bootloader
on IXP12xx.

To also allow the opposite and allow booting LE kernels from a BE
IXP4xx bootloader, moving this code into head-xscale.S along with the
recommended serialization sequence and flip the B bit into the correct
position regardless of its original state.

Note that both the endianess switch sequence and the cp15wait I add
here should be harmless on all supported ARMv4/v4t/v5 CPUs, but the
existing cache flush code is not actually defined on ARM720 and may
cause problems in multiplatform kernels that include both Xscale
and CLPS711x.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Linus Walleij <linusw@kernel.org>
---
 arch/arm/boot/compressed/Makefile      |  8 --------
 arch/arm/boot/compressed/big-endian.S  | 14 --------------
 arch/arm/boot/compressed/head-xscale.S | 12 ++++++++++++
 3 files changed, 12 insertions(+), 22 deletions(-)

diff --git a/arch/arm/boot/compressed/Makefile b/arch/arm/boot/compressed/Makefile
index e3f550d62857..5993dd1d0ee9 100644
--- a/arch/arm/boot/compressed/Makefile
+++ b/arch/arm/boot/compressed/Makefile
@@ -41,14 +41,6 @@ ifeq ($(CONFIG_PXA_SHARPSL_DETECT_MACH_ID),y)
 OBJS		+= head-sharpsl.o
 endif
 
-ifeq ($(CONFIG_CPU_ENDIAN_BE32),y)
-ifeq ($(CONFIG_CPU_CP15),y)
-OBJS		+= big-endian.o
-else
-# The endian should be set by h/w design.
-endif
-endif
-
 #
 # We now have a PIC decompressor implementation.  Decompressors running
 # from RAM should not define ZTEXTADDR.  Decompressors running directly
diff --git a/arch/arm/boot/compressed/big-endian.S b/arch/arm/boot/compressed/big-endian.S
deleted file mode 100644
index 0e092c36da2f..000000000000
--- a/arch/arm/boot/compressed/big-endian.S
+++ /dev/null
@@ -1,14 +0,0 @@
-/* SPDX-License-Identifier: GPL-2.0 */
-/*
- *  linux/arch/arm/boot/compressed/big-endian.S
- *
- *  Switch CPU into big endian mode.
- *  Author: Nicolas Pitre
- */
-
-	.section ".start", "ax"
-
-	mrc	p15, 0, r0, c1, c0, 0	@ read control reg
-	orr	r0, r0, #(1 << 7)	@ enable big endian mode
-	mcr	p15, 0, r0, c1, c0, 0	@ write control reg
-
diff --git a/arch/arm/boot/compressed/head-xscale.S b/arch/arm/boot/compressed/head-xscale.S
index 20fa44d59f82..86705c865be6 100644
--- a/arch/arm/boot/compressed/head-xscale.S
+++ b/arch/arm/boot/compressed/head-xscale.S
@@ -14,6 +14,18 @@ __XScale_start:
 
 		@ Preserve r8/r7 i.e. kernel entry values
 
+		@ set correct endianness for ixp4xx regardless of bootloader
+		mrc p15, 0, r0, c1, c0, 0
+#ifdef CONFIG_CPU_BIG_ENDIAN
+		orr	r0, r0, #(1 << 7)       @ enable big endian mode
+#else
+		bic	r0, r0, #0x80
+#endif
+		mcr	p15, 0, r0, c1, c0, 0
+		mrc     p15, 0, r0, c2, c0, 0
+		mov	r0, r0
+		sub	pc, pc, #4		@ flush instruction pipeline
+
 		@ Data cache might be active.
 		@ Be sure to flush kernel binary out of the cache,
 		@ whatever state it is, before it is turned off.

-- 
2.55.0

[PATCH 2/3] ARM: ixp4xx: Relax endianness

[Linus Walleij]

The IXP4xx can now boot in little endian mode so relax the
endianness requirements.

This will make IXP4xx compile to little endian by default
like everyone else.

Signed-off-by: Linus Walleij <linusw@kernel.org>
---
 arch/arm/mach-ixp4xx/Kconfig | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/arch/arm/mach-ixp4xx/Kconfig b/arch/arm/mach-ixp4xx/Kconfig
index cb46802f5ce5..2bc8a497d318 100644
--- a/arch/arm/mach-ixp4xx/Kconfig
+++ b/arch/arm/mach-ixp4xx/Kconfig
@@ -2,7 +2,6 @@
 menuconfig ARCH_IXP4XX
 	bool "IXP4xx-based platforms"
 	depends on ARCH_MULTI_V5
-	depends on CPU_BIG_ENDIAN
 	select ARM_APPENDED_DTB # Old Redboot bootloaders deployed
 	select CPU_XSCALE
 	select GPIO_IXP4XX
@@ -12,8 +11,8 @@ menuconfig ARCH_IXP4XX
 	select I2C_IOP3XX
 	select IXP4XX_IRQ
 	select IXP4XX_TIMER
-	select USB_EHCI_BIG_ENDIAN_DESC
-	select USB_EHCI_BIG_ENDIAN_MMIO
+	select USB_EHCI_BIG_ENDIAN_DESC if CPU_BIG_ENDIAN
+	select USB_EHCI_BIG_ENDIAN_MMIO if CPU_BIG_ENDIAN
 	select USE_OF
 	help
 	  Support for Intel's IXP4XX (XScale) family of processors.

-- 
2.55.0

[PATCH 3/3] ARM: dts: ixp4xx: Drop the reg-offset hack

[Linus Walleij]

The reg-offset hack only works when the IXP4xx platform is
running in big endian mode, and it is there to byte-offset
the byte where the serial registers appear in the BE config.

This is clearly wrong, workarounds need to be in the
drivers. Drop the reg-offset.

Signed-off-by: Linus Walleij <linusw@kernel.org>
---
 arch/arm/boot/dts/intel/ixp/intel-ixp4xx.dtsi | 10 ----------
 1 file changed, 10 deletions(-)

diff --git a/arch/arm/boot/dts/intel/ixp/intel-ixp4xx.dtsi b/arch/arm/boot/dts/intel/ixp/intel-ixp4xx.dtsi
index 0adeccabd4fe..b0f98da8def4 100644
--- a/arch/arm/boot/dts/intel/ixp/intel-ixp4xx.dtsi
+++ b/arch/arm/boot/dts/intel/ixp/intel-ixp4xx.dtsi
@@ -84,11 +84,6 @@ pci@c0000000 {
 		uart0: serial@c8000000 {
 			compatible = "intel,xscale-uart";
 			reg = <0xc8000000 0x1000>;
-			/*
-			 * The reg-offset and reg-shift is a side effect
-			 * of running the platform in big endian mode.
-			 */
-			reg-offset = <3>;
 			reg-shift = <2>;
 			interrupts = <15 IRQ_TYPE_LEVEL_HIGH>;
 			clock-frequency = <14745600>;
@@ -98,11 +93,6 @@ uart0: serial@c8000000 {
 		uart1: serial@c8001000 {
 			compatible = "intel,xscale-uart";
 			reg = <0xc8001000 0x1000>;
-			/*
-			 * The reg-offset and reg-shift is a side effect
-			 * of running the platform in big endian mode.
-			 */
-			reg-offset = <3>;
 			reg-shift = <2>;
 			interrupts = <13 IRQ_TYPE_LEVEL_HIGH>;
 			clock-frequency = <14745600>;

-- 
2.55.0

Re: [PATCH 3/3] ARM: dts: ixp4xx: Drop the reg-offset hack

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] Removing `reg-offset = <3>` without a driver workaround or `reg-io-width = <4>` breaks big-endian serial consoles on IXP4xx.
--

--- Patch [3]: [PATCH 3/3] ARM: dts: ixp4xx: Drop the reg-offset hack ---
commit 441a4bee18082ddbc2bc878dd7fd00a516e2cc30
Author: Linus Walleij <linusw@kernel.org>

ARM: dts: ixp4xx: Drop the reg-offset hack

This commit removes the reg-offset = <3> property from the UART nodes in the
IXP4xx device tree. The commit message notes that this was a hack for big
endian support and that such workarounds should be handled in the drivers.

> diff --git a/arch/arm/boot/dts/intel/ixp/intel-ixp4xx.dtsi b/arch/arm/boot/dts/intel/ixp/intel-ixp4xx.dtsi
> index 0adeccabd4fef..b0f98da8def47 100644
> --- a/arch/arm/boot/dts/intel/ixp/intel-ixp4xx.dtsi
> +++ b/arch/arm/boot/dts/intel/ixp/intel-ixp4xx.dtsi
> @@ -84,11 +84,6 @@ pci@c0000000 {
>  		uart0: serial@c8000000 {
>  			compatible = "intel,xscale-uart";
>  			reg = <0xc8000000 0x1000>;
> -			/*
> -			 * The reg-offset and reg-shift is a side effect
> -			 * of running the platform in big endian mode.
> -			 */
> -			reg-offset = <3>;

[Severity: High]
Does removing this break big-endian serial consoles on IXP4xx?

Without reg-offset = <3> or a replacement like reg-io-width = <4>, the 8250
UART driver will default to 8-bit memory access at offset 0. On big endian
systems, this reads from the wrong byte lane, resulting in invalid data and
loss of the serial console.

Is the driver workaround mentioned in the commit message already in place to
handle this?

>  			reg-shift = <2>;
>  			interrupts = <15 IRQ_TYPE_LEVEL_HIGH>;
>  			clock-frequency = <14745600>;
> @@ -98,11 +93,6 @@ uart0: serial@c8000000 {
>  		uart1: serial@c8001000 {
>  			compatible = "intel,xscale-uart";
>  			reg = <0xc8001000 0x1000>;
> -			/*
> -			 * The reg-offset and reg-shift is a side effect
> -			 * of running the platform in big endian mode.
> -			 */
> -			reg-offset = <3>;

[Severity: High]
Similarly for uart1, will this cause a regression on big endian configurations
if the driver side doesn't already compensate for the missing offset?

>  			reg-shift = <2>;
>  			interrupts = <13 IRQ_TYPE_LEVEL_HIGH>;
>  			clock-frequency = <14745600>;

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260709-ixp4xx-little-endian-v1-0-e9622d0ba9e4@kernel.org?part=3

Re: [PATCH 2/3] ARM: ixp4xx: Relax endianness

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] Removing `depends on CPU_BIG_ENDIAN` breaks the IXP4XX flash driver on little-endian builds due to missing MTD CFI byte swapping logic.
--

--- Patch [2]: [PATCH 2/3] ARM: ixp4xx: Relax endianness ---
commit b77eacff0c25c139068c8fb9c88772bc9af87ae3
Author: Linus Walleij <linusw@kernel.org>

ARM: ixp4xx: Relax endianness

The IXP4xx can now boot in little endian mode so relax the endianness
requirements. This will make IXP4xx compile to little endian by default
like everyone else.

> diff --git a/arch/arm/mach-ixp4xx/Kconfig b/arch/arm/mach-ixp4xx/Kconfig
> index cb46802f5ce52..2bc8a497d3180 100644
> --- a/arch/arm/mach-ixp4xx/Kconfig
> +++ b/arch/arm/mach-ixp4xx/Kconfig
> @@ -2,7 +2,6 @@
>  menuconfig ARCH_IXP4XX
>  	bool "IXP4xx-based platforms"
>  	depends on ARCH_MULTI_V5
> -	depends on CPU_BIG_ENDIAN

[Severity: High]
Does removing this big-endian restriction break the IXP4XX flash driver on
little-endian builds?

The physmap-ixp4xx.c driver documents a hard requirement for the byte swap
option on LE systems:

drivers/mtd/maps/physmap-ixp4xx.c:flash_read16()
 * This means that on LE systems each 16 bit word must be swapped. Note that
 * this requires CONFIG_MTD_CFI_BE_BYTE_SWAP to be enabled to 'unswap' the CFI
 * data and other flash commands which are always in D7-D0.

However, the MTD_PHYSMAP_IXP4XX configuration conditionally selects the swap
only for big-endian builds:

drivers/mtd/maps/Kconfig:MTD_PHYSMAP_IXP4XX
	select MTD_CFI_BE_BYTE_SWAP if CPU_BIG_ENDIAN

Because of this conditional, LE builds fail to select the requisite byte swap.
Without the byte swap, the CFI backend defaults to host endian and the driver
sends mangled commands to the flash, causing it to fail to probe.

>  	select ARM_APPENDED_DTB # Old Redboot bootloaders deployed
>  	select CPU_XSCALE
>  	select GPIO_IXP4XX

[ ... ]

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260709-ixp4xx-little-endian-v1-0-e9622d0ba9e4@kernel.org?part=2

Re: [PATCH 1/3] ARM: decompressor: always set endianess on xscale

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:

Pre-existing issues:
- [High] Unconditional execution of XScale-specific CP15 cache flush instructions causes undefined instruction crashes on ARM720T (CLPS711x) CPUs in multiplatform kernels.
--

--- Patch [1]: [PATCH 1/3] ARM: decompressor: always set endianess on xscale ---
commit 1aecbc0046cda85db7fa4420cfe0c46b23cbc505
Author: Arnd Bergmann <arnd@arndb.de>

ARM: decompressor: always set endianess on xscale

This commit moves the endianness switch code into head-xscale.S to support
booting BE kernels from LE bootloaders, and vice versa. It adds a serialization
sequence to flip the B bit regardless of its original state. The commit also
notes a potential issue with the existing cache flush code on ARM720T CPUs.

> diff --git a/arch/arm/boot/compressed/head-xscale.S b/arch/arm/boot/compressed/head-xscale.S
> index 20fa44d59f82d..86705c865be6d 100644
> --- a/arch/arm/boot/compressed/head-xscale.S
> +++ b/arch/arm/boot/compressed/head-xscale.S
> @@ -14,6 +14,18 @@ __XScale_start:
>  
>  		@ Preserve r8/r7 i.e. kernel entry values
>  
> +		@ set correct endianness for ixp4xx regardless of bootloader
> +		mrc p15, 0, r0, c1, c0, 0
> +#ifdef CONFIG_CPU_BIG_ENDIAN
> +		orr	r0, r0, #(1 << 7)       @ enable big endian mode
> +#else
> +		bic	r0, r0, #0x80
> +#endif
> +		mcr	p15, 0, r0, c1, c0, 0
> +		mrc     p15, 0, r0, c2, c0, 0
> +		mov	r0, r0
> +		sub	pc, pc, #4		@ flush instruction pipeline
> +
>  		@ Data cache might be active.
>  		@ Be sure to flush kernel binary out of the cache,
>  		@ whatever state it is, before it is turned off.

[Severity: High]
This isn't a bug introduced by this patch, but does this XScale-specific
cache flush sequence execute unconditionally on all CPUs in a multiplatform
build?

arch/arm/boot/compressed/head-xscale.S:__XScale_start()
    ...
    mcr p15, 0, r0, c7, c10, 4  @ drain WB
    mcr p15, 0, r0, c7, c7, 0   @ flush I & D caches
    ...

When booting a multiplatform kernel configured with both CONFIG_CPU_XSCALE and
CONFIG_CPU_ARM720T on an ARM720T CPU (such as CLPS711x), could this cause a
fatal undefined instruction exception during early boot?

Since these CP15 cache flush instructions are undefined on the ARM720T
architecture and execute before the exception vectors are set up, does this
lead to an unconditional system crash?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260709-ixp4xx-little-endian-v1-0-e9622d0ba9e4@kernel.org?part=1

Re: [PATCH 2/3] ARM: ixp4xx: Relax endianness

[Linus Walleij]

On Thu, Jul 9, 2026 at 12:37 AM <sashiko-bot@kernel.org> wrote:

> [Severity: High]
> Does removing this big-endian restriction break the IXP4XX flash driver on
> little-endian builds?
>
> The physmap-ixp4xx.c driver documents a hard requirement for the byte swap
> option on LE systems:
>
> drivers/mtd/maps/physmap-ixp4xx.c:flash_read16()
>  * This means that on LE systems each 16 bit word must be swapped. Note that
>  * this requires CONFIG_MTD_CFI_BE_BYTE_SWAP to be enabled to 'unswap' the CFI
>  * data and other flash commands which are always in D7-D0.
>
> However, the MTD_PHYSMAP_IXP4XX configuration conditionally selects the swap
> only for big-endian builds:
>
> drivers/mtd/maps/Kconfig:MTD_PHYSMAP_IXP4XX
>         select MTD_CFI_BE_BYTE_SWAP if CPU_BIG_ENDIAN
>
> Because of this conditional, LE builds fail to select the requisite byte swap.
> Without the byte swap, the CFI backend defaults to host endian and the driver
> sends mangled commands to the flash, causing it to fail to probe.

I have tested it and it works, so no.

Yours,
Linus Walleij

Re: [PATCH 3/3] ARM: dts: ixp4xx: Drop the reg-offset hack

[Linus Walleij]

On Thu, Jul 9, 2026 at 12:33 AM <sashiko-bot@kernel.org> wrote:

> [Severity: High]
> Does removing this break big-endian serial consoles on IXP4xx?

This is solved with an orthogonal patch to the serial driver.

Yours,
Linus Walleij

Re: [PATCH 1/3] ARM: decompressor: always set endianess on xscale

[Linus Walleij]

On Thu, Jul 9, 2026 at 12:48 AM <sashiko-bot@kernel.org> wrote:

> [Severity: High]
> This isn't a bug introduced by this patch, but does this XScale-specific
> cache flush sequence execute unconditionally on all CPUs in a multiplatform
> build?
>
> arch/arm/boot/compressed/head-xscale.S:__XScale_start()
>     ...
>     mcr p15, 0, r0, c7, c10, 4  @ drain WB
>     mcr p15, 0, r0, c7, c7, 0   @ flush I & D caches
>     ...
>
> When booting a multiplatform kernel configured with both CONFIG_CPU_XSCALE and
> CONFIG_CPU_ARM720T on an ARM720T CPU (such as CLPS711x), could this cause a
> fatal undefined instruction exception during early boot?
>
> Since these CP15 cache flush instructions are undefined on the ARM720T
> architecture and execute before the exception vectors are set up, does this
> lead to an unconditional system crash?

Hm.

I did originally patch it like this:

+               mrc p15, 0, r0, c1, c0, 0
+#ifdef CONFIG_CPU_BIG_ENDIAN
+               orr     r0, r0, #(1 << 7)       @ enable big endian mode
+#else
+               bic     r0, r0, #0x80
+#endif
+               mcr     p15, 0, r0, c1, c0, 0
+ 0:           mrc     p15, 0, r0, c1, c0, 0
+               tst       r0, #0x80
+               bne     0b
+               sub     pc, pc, #4              @ flush instruction pipeline

which works fine as well.

Shall we go for this version instead if it will be nicer on other CPUs?

It has the upside of just fiddling with a single bit.

Yours,
Linus Walleij