[RFC PATCH v2 0/7] Add support for ZTE zx297520v3

[RFC PATCH v2 0/7] Add support for ZTE zx297520v3

[Stefan Dösinger]

Hi,

In the past few weeks I worked on booting my own kernel on ZTE/Sanechip's 
zx297520v3 SoC. This SoC is a relative of the zx296718 that was once 
supported by the kernel. It is in use in a lot of LTE to WiFi routers in 
Africa, China and Eastern Europe, although some devices were sold or 
distributed by ISPs in the EU too. My goal is to make OpenWRT run on these 
devices.

I would like to ask for comments on these 7 patches to make sure they are 
going in the right direction. They are the bare minimum to get the kernel 
to start and run an interactive busybox on the UART.

Here are a few questions that I couldn't answer myself:

1) The GIC is a GICv3, but there are some extra registers (probably on a 
different chip) to switch PPIs and SPIs between level high/level low or 
rising edge/falling edge. The only device where this matters appears to 
the timer. It uses level low IRQs, but the GIC has PPIs configured to 
level-high by default. By setting some non-standard registers, I can get 
the PPIs to level-low and the timer works OK. Is there any precedence on 
how to handle this? I am tempted to make a zte,zx29-gic-v3 .compatible 
glue that sets the PPIs to level-low on init.

2) The boot loader doesn't set up the secure/non-secure world properly and 
doesn't enable register access to the GIC CPU interface. I found the 
Raspberry Pi 3 boot stub as a good guidance and put sample code in 
Documentation/arch/arm/zte/zx297520v3.rst . An e.g. OpenWRT build for this 
device would have to include a similar setup sequence that it runs from 
U-Boot before jumping to the kernel. Did I miss any alternatives here?

3) The SoC has clock and reset controls in the same MMIO space, even the 
same 32 bit registers. What is the preferred way to handle this? Two 
separate clk and reset drivers that write into the same place? One 
multifunction driver that exposes clock and resets? One syscon that 
contains the reg values and two separate clk and reset drivers that 
consume the syscon?

4) The CPU is a Cortex A53 running in arm32 mode (in the shipped firmware 
too). It doesn't appear to have an FPU. Reading FPSID results in an 
exception (so vfpmodule.c/vfp_init says VFP is not available). I tried 
enabling p10 and p11 in NSACR, but without success. NSACR seems to always 
read 0 too. Is this really a Cortex A53 without FPU or did I miss 
something?

5) Relatedly, are there any advantages to running in arm64 mode? The 
devices are relatively memory constrained (64mb), so the larger binary 
size from 64 bit pointers is probably a negative, while the larger 
register set might be a positive. I doubt switching to arm64 mode is 
possible at all, but I'm nevertheless curious.

6) The old removed zx29 code used "zte," as the vendor for the 
compatibles. Sanechips is a subsidiary of ZTE that designed these chips. 
Are there any preferences for either "zte," or "sanechips,"?

As for the rest of the hardware, my entire patchset can be found here: 
https://gitlab.com/stefandoesinger/zx297520-kernel/ . So far 3 people from 
the OpenWRT community are helping with testing on different routers (Tecno 
TR118, ZTE K10, ZLT S10 in addition to my D-Link DWR932 and HGSD R310).

USB: Standard dwc2 WiFi: rtl8192, but in the SDIO version. I hacked sdio 
into rtl8xxxu but it'll need major cleanup. ethernet: STMicro stmmac. ZTE 
wrote their own driver for it. I spent a week re-implementing it before I 
was able to match the HW to stmmac. SDIO: standard dw-mshc NAND: A 128 MB 
SPI NAND chip connected to a homebrew QSPI controller. The driver is 
copypasta from stm32-qspi, but the hardware registers seem incompatible 
LTE: A Cortex M0 is doing the heavy lifting and talks to the main CPU via 
RPMsg. I hope to be able to handle this in userspace, but I haven't looked 
into it yet. clk, pinctrl, pmdomain: My own code based on the zx2967xx 
code.

Patch changelog v2: checkpatch.pl fixes.

Stefan Dösinger (7):
  ARM: zte: Add zx297520v3 platform support.
  dt-bindings: arm: Add zx297520v3 board binding.
  ARM: dts: Add D-Link DWR-932M support.
  ARM: zte: Add support for zx29 low level debug.
  ARM: dts: Add an armv7 timer for zx297520v3.
  ARM: zte: Bring back ZX29 UART support.
  ARM: dts: Declare UART1 on zx297520v3 boards.

 Documentation/arch/arm/zte/zx297520v3.rst     | 106 ++++++++++++++++++
 .../devicetree/bindings/arm/zx29.yaml         |  20 ++++
 MAINTAINERS                                   |   6 +
 arch/arm/Kconfig                              |   2 +
 arch/arm/Kconfig.debug                        |  12 ++
 arch/arm/Makefile                             |   1 +
 arch/arm/boot/dts/Makefile                    |   1 +
 arch/arm/boot/dts/zte/Makefile                |   3 +
 arch/arm/boot/dts/zte/dlink-dwr-932m.dts      |  21 ++++
 arch/arm/boot/dts/zte/zx297520v3.dtsi         |  83 ++++++++++++++
 arch/arm/include/debug/pl01x.S                |   7 ++
 arch/arm/mach-zte/Kconfig                     |  23 ++++
 arch/arm/mach-zte/Makefile                    |   2 +
 arch/arm/mach-zte/zx297520v3.c                |  19 ++++
 drivers/tty/serial/amba-pl011.c               |  37 ++++++
 include/linux/amba/bus.h                      |   6 +
 16 files changed, 349 insertions(+)
 create mode 100644 Documentation/arch/arm/zte/zx297520v3.rst
 create mode 100644 Documentation/devicetree/bindings/arm/zx29.yaml
 create mode 100644 arch/arm/boot/dts/zte/Makefile
 create mode 100644 arch/arm/boot/dts/zte/dlink-dwr-932m.dts
 create mode 100644 arch/arm/boot/dts/zte/zx297520v3.dtsi
 create mode 100644 arch/arm/mach-zte/Kconfig
 create mode 100644 arch/arm/mach-zte/Makefile
 create mode 100644 arch/arm/mach-zte/zx297520v3.c


base-commit: 7d0a66e4bb9081d75c82ec4957c50034cb0ea449
-- 
2.52.0

[RFC PATCH v2 1/7] ARM: zte: Add zx297520v3 platform support.

[Stefan Dösinger]

This SoC is used in low end LTE-to-WiFi routers, for example some D-Link
DWR 932 revisions, ZTE K10, ZLT S10 4G, but also models that are branded
and sold by ISPs themselves. They are widespread in Africa, China,
Russia and Eastern Europe.

This SoC is a relative of the zx296702 and zx296718 that had some
upstream support until commit 89d4f98ae90d ("ARM: remove zte zx
platform"). My eventual goal is to enable OpenWRT to run on these
devices.

Signed-off-by: Stefan Dösinger <stefandoesinger@gmail.com>
---
 Documentation/arch/arm/zte/zx297520v3.rst | 106 ++++++++++++++++++++++
 MAINTAINERS                               |   4 +
 arch/arm/Kconfig                          |   2 +
 arch/arm/Makefile                         |   1 +
 arch/arm/mach-zte/Kconfig                 |  23 +++++
 arch/arm/mach-zte/Makefile                |   2 +
 arch/arm/mach-zte/zx297520v3.c            |  19 ++++
 7 files changed, 157 insertions(+)
 create mode 100644 Documentation/arch/arm/zte/zx297520v3.rst
 create mode 100644 arch/arm/mach-zte/Kconfig
 create mode 100644 arch/arm/mach-zte/Makefile
 create mode 100644 arch/arm/mach-zte/zx297520v3.c

diff --git a/Documentation/arch/arm/zte/zx297520v3.rst b/Documentation/arch/arm/zte/zx297520v3.rst
new file mode 100644
index 000000000000..cfa40ca6baaf
--- /dev/null
+++ b/Documentation/arch/arm/zte/zx297520v3.rst
@@ -0,0 +1,106 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+====================================
+Booting Linux on ZTE zx297520v3 SoCs
+====================================
+
+...............................................................................
+
+Author:	Stefan Dösinger
+
+Date  : 27 Jan 2026
+
+1. Hardware description
+---------------------------
+Zx297520v3 SoCs use a 64 bit capable Cortex-A53 CPU and GICv3, although they
+run in aarch32 mode only. The CPU has support EL3, but no hypervisor (EL2) and
+it seems to lack VFP and NEON.
+
+The SoC is used in a number of cheap LTE to Wifi routers, both battery powered
+MiFis and stationary CPEs. In addition to the CPU these devices usually have
+64 MB Ram (although some is shared with the LTE chip), 128 MB NAND flash, an
+SDIO connected RTL8192-type Wifi chip limited to 2.4 ghz operation, USB 2,
+and buttons.
+
+Some devices, especially the stationary ones, have 100 mbit Ethernet, and an
+Ethernet switch.
+
+Usually the devices have LEDs for status indication, although some have SPI-
+connected displays.
+
+Some have an SD card slot. If it exists, it is a better choice for the root
+file system because it easily outperforms the built-in NAND.
+
+The LTE interface appears to be run by a separate Cortex-M0 CPU that runs a
+non-Linux binary blob and communicates with the main CPU via RPMsg.
+
+2. Booting
+---------------------------
+
+Generally CPU and GICv3 need to be set up according to the requirements spelled
+out in Documentation/arch/arm64/booting.rst. For zx297520v3 this means:
+
+1. GICD_CTLR.DS=1 to disable GIC security
+2. Enable access to ICC_SRE
+3. Disable trapping IRQs into monitor mode
+4. Configure EL2 and below to run in insecure mode.
+
+And an unrelated: This needs to be moved into a driver eventually:
+5. Configure timer PPIs to active-low.
+
+The kernel sources provided by ZTE do not boot either (interrupts do not work
+at all). They are incomplete in other aspects too, so it is assumed that there
+is some workaround similar to the one described in this document somewhere in
+the binary blobs.
+
+The assembly code below is given as an example of how to achieve this:
+
+```
+#include <linux/irqchip/arm-gic-v3.h>
+#include <asm/assembler.h>
+#include <asm/cp15.h>
+
+@ This allows EL1 to handle ints hat are normally handled by EL2/3.
+ldr     r3, =0xf2000000
+ldr     r4, =#(GICD_CTLR_ARE_NS | GICD_CTLR_DS)
+str     r4, [r3]
+
+cps     #MON_MODE
+
+@ Work in non-secure physical address space: SCR_EL3.NS = 1. At least the UART
+@ seems to respond only to non-secure addresses. I have taken insipiration from
+@ Raspberry pi's armstub7.S here.
+@
+@ ARM docs say modify this bit in monitor mode only...
+mrc     p15, 0, r3, c1, c1, 0
+mov	r3, #0x131			@ non-secure, Make F, A bits in CPSR writeable
+					@ Allow hypervisor call.
+mcr     p15, 0, r3, c1, c1, 0
+
+@ AP_PPI_MODE_REG: Configure timer PPIs (10, 11, 13, 14) to active-low.
+ldr	r3, =0xF22020a8
+ldr	r4, =0x50
+str	r4, [r3]
+ldr	r3, =0xF22020ac
+ldr	r4, =0x14
+str	r4, [r3]
+
+@ Enable EL2 access to ICC_SRE (bit 3, ICC_SRE_EL3.Enable). Enable system reg
+@ access to GICv3 registers (bit 0, ICC_SRE_EL3.SRE) for EL1 and EL3.
+mrc     p15, 6, r3, c12, c12, 5         @ ICC_SRE_EL3
+orr     r3, #0x9                        @ FIXME: No defines for SRE_EL3 values?
+mcr     p15, 6, r3, c12, c12, 5
+mrc     p15, 0, r3, c12, c12, 5         @ ICC_SRE_EL1
+orr     r3, #(ICC_SRE_EL1_SRE)
+mcr     p15, 0, r3, c12, c12, 5
+
+@ Like ICC_SRE_EL3, enable EL1 access to ICC_SRE and system register access
+@ for EL2.
+mrc     p15, 4, r3, c12, c9, 5          @ ICC_SRE_EL2 aka ICC_HSRE
+orr     r3, r3, #(ICC_SRE_EL2_ENABLE | ICC_SRE_EL2_SRE)
+mcr     p15, 4, r3, c12, c9, 5
+isb
+
+@ Back to SVC mode. TODO: Doesn't safe_svcmode_maskall do this for us anyway?
+cps     #SVC_MODE
+```
diff --git a/MAINTAINERS b/MAINTAINERS
index e8f06145fb54..225392cf3b5b 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -28392,6 +28392,10 @@ F:	lib/zstd/
 N:	zstd
 K:	zstd
 
+ZX29
+M:	Stefan Dösinger <stefandoesinger@gmail.com>
+F:	arch/arm/mach-zte/
+
 ZSWAP COMPRESSED SWAP CACHING
 M:	Johannes Weiner <hannes@cmpxchg.org>
 M:	Yosry Ahmed <yosry.ahmed@linux.dev>
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 4fb985b76e97..bd2cae242603 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -463,6 +463,8 @@ source "arch/arm/mach-versatile/Kconfig"
 
 source "arch/arm/mach-vt8500/Kconfig"
 
+source "arch/arm/mach-zte/Kconfig"
+
 source "arch/arm/mach-zynq/Kconfig"
 
 # ARMv7-M architecture
diff --git a/arch/arm/Makefile b/arch/arm/Makefile
index b7de4b6b284c..573813ef5e77 100644
--- a/arch/arm/Makefile
+++ b/arch/arm/Makefile
@@ -223,6 +223,7 @@ machine-$(CONFIG_ARCH_SUNXI)		+= sunxi
 machine-$(CONFIG_ARCH_TEGRA)		+= tegra
 machine-$(CONFIG_ARCH_U8500)		+= ux500
 machine-$(CONFIG_ARCH_VT8500)		+= vt8500
+machine-$(CONFIG_ARCH_ZTE)		+= zte
 machine-$(CONFIG_ARCH_ZYNQ)		+= zynq
 machine-$(CONFIG_PLAT_VERSATILE)	+= versatile
 machine-$(CONFIG_PLAT_SPEAR)		+= spear
diff --git a/arch/arm/mach-zte/Kconfig b/arch/arm/mach-zte/Kconfig
new file mode 100644
index 000000000000..373889b72005
--- /dev/null
+++ b/arch/arm/mach-zte/Kconfig
@@ -0,0 +1,23 @@
+# SPDX-License-Identifier: GPL-2.0
+menuconfig ARCH_ZTE
+	bool "ZTE ZX family"
+	depends on ARCH_MULTI_V7
+	help
+	  Support for ZTE ZX-based family of processors.
+
+if ARCH_ZTE
+
+config SOC_ZX297520V3
+	default y if ARCH_ZTE
+	bool "ZX297520v3"
+	select ARM_GIC_V3
+	select HAVE_ARM_ARCH_TIMER
+	select PM_GENERIC_DOMAINS if PM
+	help
+	  Support for ZTE ZX297520v3 SoC. It a single core SoC used in cheap LTE to WiFi routers.
+	  These devices can be Identified by the occurrence of the string "zx297520v3" in the boot
+	  output and /proc/cpuinfo of their stock firmware.
+
+	  Please read Documentation/arch/arm/zte/zx297520v3.rst on how to boot the kernel.
+
+endif
diff --git a/arch/arm/mach-zte/Makefile b/arch/arm/mach-zte/Makefile
new file mode 100644
index 000000000000..1bfe4fddd6af
--- /dev/null
+++ b/arch/arm/mach-zte/Makefile
@@ -0,0 +1,2 @@
+# SPDX-License-Identifier: GPL-2.0-only
+obj-$(CONFIG_SOC_ZX297520V3) += zx297520v3.o
diff --git a/arch/arm/mach-zte/zx297520v3.c b/arch/arm/mach-zte/zx297520v3.c
new file mode 100644
index 000000000000..e8db18c2f665
--- /dev/null
+++ b/arch/arm/mach-zte/zx297520v3.c
@@ -0,0 +1,19 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Copyright 2026 Stefan Dösinger
+ */
+
+#include <asm/mach/arch.h>
+#include <asm/mach/map.h>
+
+#include <linux/of_address.h>
+#include <linux/of_platform.h>
+
+static const char *const zx297520v3_dt_compat[] __initconst = {
+	"zte,zx297520v3",
+	NULL,
+};
+
+DT_MACHINE_START(ZX, "ZTE ZX297520v3 (Device Tree)")
+	.dt_compat	= zx297520v3_dt_compat,
+MACHINE_END
-- 
2.52.0

[RFC PATCH v2 2/7] dt-bindings: arm: Add zx297520v3 board binding.

[Stefan Dösinger]

Add a compatible for boards based on the ZTE zx297520v3 SoC.

Signed-off-by: Stefan Dösinger <stefandoesinger@gmail.com>
---
 .../devicetree/bindings/arm/zx29.yaml         | 20 +++++++++++++++++++
 MAINTAINERS                                   |  1 +
 2 files changed, 21 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/arm/zx29.yaml

diff --git a/Documentation/devicetree/bindings/arm/zx29.yaml b/Documentation/devicetree/bindings/arm/zx29.yaml
new file mode 100644
index 000000000000..717ca6413993
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/zx29.yaml
@@ -0,0 +1,20 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/arm/zx29.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: ZTE zx29
+
+maintainers:
+  - Stefan Dösinger <stefandoesinger@gmail.com>
+
+properties:
+  $nodename:
+    const: "/"
+  compatible:
+    oneOf:
+      - items:
+          - const: zte,zx297520v3
+
+additionalProperties: true
diff --git a/MAINTAINERS b/MAINTAINERS
index 225392cf3b5b..0989b2c6c157 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -28394,6 +28394,7 @@ K:	zstd
 
 ZX29
 M:	Stefan Dösinger <stefandoesinger@gmail.com>
+F:	Documentation/devicetree/bindings/arm/zx29.yaml
 F:	arch/arm/mach-zte/
 
 ZSWAP COMPRESSED SWAP CACHING
-- 
2.52.0

[RFC PATCH v2 3/7] ARM: dts: Add D-Link DWR-932M support.

[Stefan Dösinger]

This adds DT bindings for zx297520v3 and one board that consumes it.

Signed-off-by: Stefan Dösinger <stefandoesinger@gmail.com>
---
 MAINTAINERS                              |  1 +
 arch/arm/boot/dts/Makefile               |  1 +
 arch/arm/boot/dts/zte/Makefile           |  3 ++
 arch/arm/boot/dts/zte/dlink-dwr-932m.dts | 21 ++++++++++++++
 arch/arm/boot/dts/zte/zx297520v3.dtsi    | 37 ++++++++++++++++++++++++
 5 files changed, 63 insertions(+)
 create mode 100644 arch/arm/boot/dts/zte/Makefile
 create mode 100644 arch/arm/boot/dts/zte/dlink-dwr-932m.dts
 create mode 100644 arch/arm/boot/dts/zte/zx297520v3.dtsi

diff --git a/MAINTAINERS b/MAINTAINERS
index 0989b2c6c157..2682ad06a0f1 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -28395,6 +28395,7 @@ K:	zstd
 ZX29
 M:	Stefan Dösinger <stefandoesinger@gmail.com>
 F:	Documentation/devicetree/bindings/arm/zx29.yaml
+F:	arch/arm/boot/dts/zte
 F:	arch/arm/mach-zte/
 
 ZSWAP COMPRESSED SWAP CACHING
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index efe38eb25301..28fba538d552 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -39,3 +39,4 @@ subdir-y += unisoc
 subdir-y += vt8500
 subdir-y += xen
 subdir-y += xilinx
+subdir-y += zte
diff --git a/arch/arm/boot/dts/zte/Makefile b/arch/arm/boot/dts/zte/Makefile
new file mode 100644
index 000000000000..416c24a489cd
--- /dev/null
+++ b/arch/arm/boot/dts/zte/Makefile
@@ -0,0 +1,3 @@
+# SPDX-License-Identifier: GPL-2.0
+dtb-$(CONFIG_SOC_ZX297520V3) += \
+	dlink-dwr-932m.dtb
diff --git a/arch/arm/boot/dts/zte/dlink-dwr-932m.dts b/arch/arm/boot/dts/zte/dlink-dwr-932m.dts
new file mode 100644
index 000000000000..b38b0f2bee8b
--- /dev/null
+++ b/arch/arm/boot/dts/zte/dlink-dwr-932m.dts
@@ -0,0 +1,21 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * D-Link DWR-932M Board
+ *
+ * (C) Copyright 2026 Stefan Dösinger
+ *
+ */
+
+/dts-v1/;
+
+#include "zx297520v3.dtsi"
+
+/ {
+	model = "D-Link DWR-932M";
+	compatible = "zte,zx297520v3";
+
+	memory@20000000 {
+		device_type = "memory";
+		reg = <0x20000000 0x04000000>;
+	};
+};
diff --git a/arch/arm/boot/dts/zte/zx297520v3.dtsi b/arch/arm/boot/dts/zte/zx297520v3.dtsi
new file mode 100644
index 000000000000..d6c71d52b26c
--- /dev/null
+++ b/arch/arm/boot/dts/zte/zx297520v3.dtsi
@@ -0,0 +1,37 @@
+// SPDX-License-Identifier: GPL-2.0-only
+
+#include <dt-bindings/interrupt-controller/arm-gic.h>
+
+/ {
+	#address-cells = <1>;
+	#size-cells = <1>;
+
+	cpus {
+		#address-cells = <1>;
+		#size-cells = <0>;
+
+		cpu@0 {
+			device_type = "cpu";
+			compatible = "arm,cortex-a53";
+			reg = <0>;
+		};
+	};
+
+	soc {
+		#address-cells = <1>;
+		#size-cells = <1>;
+		compatible = "simple-bus";
+		interrupt-parent = <&gic>;
+		ranges;
+
+		gic: interrupt-controller@f2000000 {
+			compatible = "arm,gic-v3";
+			interrupt-controller;
+			#interrupt-cells = <3>;
+			#address-cells = <1>;
+			#size-cells = <1>;
+			reg = <0xf2000000 0x10000>,
+			      <0xf2040000 0x20000>;
+		};
+	};
+};
-- 
2.52.0

[RFC PATCH v2 4/7] ARM: zte: Add support for zx29 low level debug.

[Stefan Dösinger]

TODO: I am not sure about the virtual address.

Signed-off-by: Stefan Dösinger <stefandoesinger@gmail.com>
---
 arch/arm/Kconfig.debug         | 12 ++++++++++++
 arch/arm/include/debug/pl01x.S |  7 +++++++
 2 files changed, 19 insertions(+)

diff --git a/arch/arm/Kconfig.debug b/arch/arm/Kconfig.debug
index 366f162e147d..98d8a5a60048 100644
--- a/arch/arm/Kconfig.debug
+++ b/arch/arm/Kconfig.debug
@@ -1331,6 +1331,16 @@ choice
 		  This option selects UART0 on VIA/Wondermedia System-on-a-chip
 		  devices, including VT8500, WM8505, WM8650 and WM8850.
 
+	config DEBUG_ZTE_ZX
+		bool "Kernel low-level debugging via zx29 UART"
+		select DEBUG_UART_PL01X
+		depends on ARCH_ZTE
+		help
+		  Say Y here if you are enabling ZTE zx297520v3 SOC and need
+		  debug UART support. This UART is a PL011 with different
+		  register addresses. The UART for boot messages on zx29 boards
+		  is usually UART1 and is operating at 921600 8N1.
+
 	config DEBUG_ZYNQ_UART0
 		bool "Kernel low-level debugging on Xilinx Zynq using UART0"
 		depends on ARCH_ZYNQ
@@ -1545,6 +1555,7 @@ config DEBUG_UART_8250
 
 config DEBUG_UART_PHYS
 	hex "Physical base address of debug UART"
+	default 0x01408000 if DEBUG_ZTE_ZX
 	default 0x01c28000 if DEBUG_SUNXI_UART0
 	default 0x01c28400 if DEBUG_SUNXI_UART1
 	default 0x01d0c000 if DEBUG_DAVINCI_DA8XX_UART1
@@ -1701,6 +1712,7 @@ config DEBUG_UART_VIRT
 	default 0xf31004c0 if DEBUG_MESON_UARTAO
 	default 0xf4090000 if DEBUG_LPC32XX
 	default 0xf4200000 if DEBUG_GEMINI
+	default 0xf4708000 if DEBUG_ZTE_ZX
 	default 0xf6200000 if DEBUG_PXA_UART1
 	default 0xf7000000 if DEBUG_SUN9I_UART0
 	default 0xf7000000 if DEBUG_S3C64XX_UART && DEBUG_S3C_UART0
diff --git a/arch/arm/include/debug/pl01x.S b/arch/arm/include/debug/pl01x.S
index c7e02d0628bf..0c7bfa4c10db 100644
--- a/arch/arm/include/debug/pl01x.S
+++ b/arch/arm/include/debug/pl01x.S
@@ -8,6 +8,13 @@
 */
 #include <linux/amba/serial.h>
 
+#ifdef CONFIG_DEBUG_ZTE_ZX
+#undef UART01x_DR
+#undef UART01x_FR
+#define UART01x_DR     0x04
+#define UART01x_FR     0x14
+#endif
+
 #ifdef CONFIG_DEBUG_UART_PHYS
 		.macro	addruart, rp, rv, tmp
 		ldr	\rp, =CONFIG_DEBUG_UART_PHYS
-- 
2.52.0

[RFC PATCH v2 5/7] ARM: dts: Add an armv7 timer for zx297520v3.

[Stefan Dösinger]

The stock kernel does not use this timer, but it seems to work fine. The
board has other board-specific timers that would need a driver and I see
no reason to bother with them since the arm standard timer works.

The caveat is the non-standard GIC setup needed to handle the timer's
level-low PPI.

Signed-off-by: Stefan Dösinger <stefandoesinger@gmail.com>
---
 arch/arm/boot/dts/zte/zx297520v3.dtsi | 24 ++++++++++++++++++++++++
 1 file changed, 24 insertions(+)

diff --git a/arch/arm/boot/dts/zte/zx297520v3.dtsi b/arch/arm/boot/dts/zte/zx297520v3.dtsi
index d6c71d52b26c..ecd07f3fb8b3 100644
--- a/arch/arm/boot/dts/zte/zx297520v3.dtsi
+++ b/arch/arm/boot/dts/zte/zx297520v3.dtsi
@@ -24,6 +24,15 @@ soc {
 		interrupt-parent = <&gic>;
 		ranges;
 
+		/* The GIC has a non-standard way of configuring ints between level-low/level
+		 * high or rising edge/falling edge at 0xf2202070 and onwards. See AP_INT_MODE_BASE
+		 * and AP_PPI_MODE_REG in the ZTE kernel, although the offsets in the kernel source
+		 * seem wrong.
+		 *
+		 * Everything defaults to active-high/rising edge, but the timer is active-low. We
+		 * currently rely on the boot loader to change timer IRQs to active-low for us for
+		 * now.
+		 */
 		gic: interrupt-controller@f2000000 {
 			compatible = "arm,gic-v3";
 			interrupt-controller;
@@ -33,5 +42,20 @@ gic: interrupt-controller@f2000000 {
 			reg = <0xf2000000 0x10000>,
 			      <0xf2040000 0x20000>;
 		};
+
+		timer {
+			compatible = "arm,armv7-timer";
+			interrupts = <GIC_PPI 13 IRQ_TYPE_LEVEL_LOW>,
+				<GIC_PPI 14 IRQ_TYPE_LEVEL_LOW>,
+				<GIC_PPI 11 IRQ_TYPE_LEVEL_LOW>,
+				<GIC_PPI 10 IRQ_TYPE_LEVEL_LOW>;
+			clock-frequency = <26000000>;
+			interrupt-parent = <&gic>;
+			/* I don't think uboot sets CNTVOFF and the stock kernel doesn't use the
+			 * arm timer at all. Since this is a single CPU system I don't think it
+			 * really matters that the offset is random though.
+			 */
+			arm,cpu-registers-not-fw-configured;
+		};
 	};
 };
-- 
2.52.0

[RFC PATCH v2 6/7] ARM: zte: Bring back ZX29 UART support.

[Stefan Dösinger]

This is based on code removed in commit 89d4f98ae90d ("ARM: remove zte
zx platform"). I did not bring back the zx29-uart .compatible as the
arm,primecell-periphid does the job.

Signed-off-by: Stefan Dösinger <stefandoesinger@gmail.com>
---
 drivers/tty/serial/amba-pl011.c | 37 +++++++++++++++++++++++++++++++++
 include/linux/amba/bus.h        |  6 ++++++
 2 files changed, 43 insertions(+)

diff --git a/drivers/tty/serial/amba-pl011.c b/drivers/tty/serial/amba-pl011.c
index 7f17d288c807..858a0edd3e3b 100644
--- a/drivers/tty/serial/amba-pl011.c
+++ b/drivers/tty/serial/amba-pl011.c
@@ -216,6 +216,38 @@ static struct vendor_data vendor_st = {
 	.get_fifosize		= get_fifosize_st,
 };
 
+static const u16 pl011_zte_offsets[REG_ARRAY_SIZE] = {
+	[REG_DR] = ZX_UART011_DR,
+	[REG_FR] = ZX_UART011_FR,
+	[REG_LCRH_RX] = ZX_UART011_LCRH,
+	[REG_LCRH_TX] = ZX_UART011_LCRH,
+	[REG_IBRD] = ZX_UART011_IBRD,
+	[REG_FBRD] = ZX_UART011_FBRD,
+	[REG_CR] = ZX_UART011_CR,
+	[REG_IFLS] = ZX_UART011_IFLS,
+	[REG_IMSC] = ZX_UART011_IMSC,
+	[REG_RIS] = ZX_UART011_RIS,
+	[REG_MIS] = ZX_UART011_MIS,
+	[REG_ICR] = ZX_UART011_ICR,
+	[REG_DMACR] = ZX_UART011_DMACR,
+};
+
+static unsigned int get_fifosize_zte(struct amba_device *dev)
+{
+	return 16;
+}
+
+static struct vendor_data vendor_zte = {
+	.reg_offset		= pl011_zte_offsets,
+	.access_32b		= true,
+	.ifls			= UART011_IFLS_RX4_8 | UART011_IFLS_TX4_8,
+	.fr_busy		= ZX_UART01x_FR_BUSY,
+	.fr_dsr			= ZX_UART01x_FR_DSR,
+	.fr_cts			= ZX_UART01x_FR_CTS,
+	.fr_ri			= ZX_UART011_FR_RI,
+	.get_fifosize		= get_fifosize_zte,
+};
+
 /* Deals with DMA transactions */
 
 struct pl011_dmabuf {
@@ -3081,6 +3113,11 @@ static const struct amba_id pl011_ids[] = {
 		.mask	= 0x00ffffff,
 		.data	= &vendor_st,
 	},
+	{
+		.id	= AMBA_LINUX_ID(0x00, 0x1, 0xffe),
+		.mask	= 0x00ffffff,
+		.data	= &vendor_zte,
+	},
 	{ 0, 0 },
 };
 
diff --git a/include/linux/amba/bus.h b/include/linux/amba/bus.h
index 9946276aff73..854c962d70f5 100644
--- a/include/linux/amba/bus.h
+++ b/include/linux/amba/bus.h
@@ -103,8 +103,14 @@ enum amba_vendor {
 	AMBA_VENDOR_ST = 0x80,
 	AMBA_VENDOR_QCOM = 0x51,
 	AMBA_VENDOR_LSI = 0xb6,
+	AMBA_VENDOR_LINUX = 0xfe,	/* This value is not official */
 };
 
+/* This is used to generate pseudo-ID for AMBA device */
+#define AMBA_LINUX_ID(conf, rev, part) \
+	(((conf) & 0xff) << 24 | ((rev) & 0xf) << 20 | \
+	AMBA_VENDOR_LINUX << 12 | ((part) & 0xfff))
+
 extern const struct bus_type amba_bustype;
 
 #define to_amba_device(d)	container_of_const(d, struct amba_device, dev)
-- 
2.52.0

[RFC PATCH v2 7/7] ARM: dts: Declare UART1 on zx297520v3 boards.

[Stefan Dösinger]

This is the UART that sends Uboot messages and is accessible via pins on
the boards I have seen so far. UART0 and UART2 exist as well, but don't
have pins enabled by the bootloader. They will be added later.

Signed-off-by: Stefan Dösinger <stefandoesinger@gmail.com>
---
 arch/arm/boot/dts/zte/zx297520v3.dtsi | 22 ++++++++++++++++++++++
 1 file changed, 22 insertions(+)

diff --git a/arch/arm/boot/dts/zte/zx297520v3.dtsi b/arch/arm/boot/dts/zte/zx297520v3.dtsi
index ecd07f3fb8b3..09fbb1d052e3 100644
--- a/arch/arm/boot/dts/zte/zx297520v3.dtsi
+++ b/arch/arm/boot/dts/zte/zx297520v3.dtsi
@@ -6,6 +6,10 @@ / {
 	#address-cells = <1>;
 	#size-cells = <1>;
 
+	aliases {
+		serial1 = &uart1;
+	};
+
 	cpus {
 		#address-cells = <1>;
 		#size-cells = <0>;
@@ -57,5 +61,23 @@ timer {
 			 */
 			arm,cpu-registers-not-fw-configured;
 		};
+
+		/* The UART clock defaults to 26 mhz. It will be replaced when the zx29 clock
+		 * framework is added.
+		 */
+		uartclk: uartclk: clock-26000000 {
+			#clock-cells = <0>;
+			compatible = "fixed-clock";
+			clock-frequency = <26000000>;
+		};
+
+		uart1: serial@1408000 {
+			compatible = "arm,pl011", "arm,primecell";
+			arm,primecell-periphid = <0x001feffe>;
+			reg = <0x01408000 0x1000>;
+			interrupts = <GIC_SPI 1 IRQ_TYPE_LEVEL_HIGH>;
+			clocks = <&uartclk>;
+			clock-names = "apb_pclk";
+		};
 	};
 };
-- 
2.52.0

Re: [RFC PATCH v2 0/7] Add support for ZTE zx297520v3

[Arnd Bergmann]

On Wed, Jan 28, 2026, at 21:34, Stefan Dösinger wrote:

> 4) The CPU is a Cortex A53 running in arm32 mode (in the shipped firmware 
> too). It doesn't appear to have an FPU. Reading FPSID results in an 
> exception (so vfpmodule.c/vfp_init says VFP is not available). I tried 
> enabling p10 and p11 in NSACR, but without success. NSACR seems to always 
> read 0 too. Is this really a Cortex A53 without FPU or did I miss 
> something?

I've never seen a Cortex-A53 without FPU and NEON, but since this
is optional, it was a matter of time before we got one ;-)

I assume that you were in EL3 when you tried to write to NSACR?
From EL2/EL1 it would still appear the same as not-implemented
even if it is there but disabled in EL3.

> 5) Relatedly, are there any advantages to running in arm64 mode? The 
> devices are relatively memory constrained (64mb), so the larger binary 
> size from 64 bit pointers is probably a negative, while the larger 
> register set might be a positive. I doubt switching to arm64 mode is 
> possible at all, but I'm nevertheless curious.

Support for 64-bit cores is actually quite rudimentary in 32-bit
more, as we are missing a lot of the errata workarounds and ARMv8
specific features in the kernel. If you can figure out how to
use 64-bit kernel mode, that would be ideal. There is a
noticeably higher memory usage even with 32-bit userspace though,
so you'd lose several megabytes of memory as you said, and 64-bit
userspace would be impossible since the aarch64 toolchain only
supports hardfloat.

You would also have to deal with a practical problem in OpenWRT,
which as far as I know does not support building kernel
and userland with different toolchains.

> 6) The old removed zx29 code used "zte," as the vendor for the 
> compatibles. Sanechips is a subsidiary of ZTE that designed these chips. 
> Are there any preferences for either "zte," or "sanechips,"?

I would stay with the previously used one

      Arnd

Re: [RFC PATCH v2 0/7] Add support for ZTE zx297520v3

[Stefan Dösinger]

[-- Attachment #1: Type: text/plain, Size: 2438 bytes --]

Am Donnerstag, 29. Januar 2026, 01:00:08 Ostafrikanische Zeit schrieb Arnd 
Bergmann:
> On Wed, Jan 28, 2026, at 21:34, Stefan Dösinger wrote:

> I assume that you were in EL3 when you tried to write to NSACR?
> From EL2/EL1 it would still appear the same as not-implemented
> even if it is there but disabled in EL3.
Yes, and I just double checked, it does read 0 in all cases. Here's what I did 
- abusing the head.S error handling code a bit for printing:

cps	#MON_MODE
mrc	p15, 0, r9, c1, c1, 2
b	__error_p			@ abuse for print
Error: unrecognized/unsupported processor variant (0x00000000).

cps	#MON_MODE
ldr	r1, =0x63fff
mcr	p15, 0, r1, c1, c1, 2
mrc	p15, 0, r9, c1, c1, 2
b	__error_p
Error: unrecognized/unsupported processor variant (0x00000000).

And just to make sure I didn't get __error_p wrong:

cps	#MON_MODE
ldr	r9, =0xdeadbeef
b	__error_p
Error: unrecognized/unsupported processor variant (0xdeadbeef).

I am certain switching to EL3 is working here because I am using it in the 
same way to set up ICC_SRE_EL*. (And yes, I know this code doesn't belong in 
this place. It's just more comfortable for my development tree for now)

> I've never seen a Cortex-A53 without FPU and NEON, but since this
> is optional, it was a matter of time before we got one ;-)

The ZTE 3.4 kernel code suggests that there is/was a zx297520v2 that was 
Cortex A9 based, and then ZTE replaced the Cortex-A9 with a Cortex-A53 and 
left the rest of the system unchanged.

A later version of this SoC, zx298501 switched to 64 bit, including kernel + 
userland. But I don't have any hardware based on either of them.

> Support for 64-bit cores is actually quite rudimentary in 32-bit
> more, as we are missing a lot of the errata workarounds and ARMv8
> specific features in the kernel. If you can figure out how to
> use 64-bit kernel mode, that would be ideal.

One of my co-hackers is giving it another try. Pairing a 64 bit kernel with 32 
bit userspace seems reasonable. Of course the other question is what quirks 
are hiding in the hardware when we run them in a mode the vendor never tested.

> > 6) The old removed zx29 code used "zte," as the vendor for the
> > compatibles. Sanechips is a subsidiary of ZTE that designed these chips.
> > Are there any preferences for either "zte," or "sanechips,"?
> 
> I would stay with the previously used one

Check

Cheers,
Stefan

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 870 bytes --]

Re: [RFC PATCH v2 0/7] Add support for ZTE zx297520v3

[Arnd Bergmann]

On Thu, Jan 29, 2026, at 20:38, Stefan Dösinger wrote:
> Am Donnerstag, 29. Januar 2026, 01:00:08 Ostafrikanische Zeit schrieb Arnd 
> Bergmann:
>> On Wed, Jan 28, 2026, at 21:34, Stefan Dösinger wrote:
>
> I am certain switching to EL3 is working here because I am using it in the 
> same way to set up ICC_SRE_EL*. (And yes, I know this code doesn't belong in 
> this place. It's just more comfortable for my development tree for now)

Ok

>> I've never seen a Cortex-A53 without FPU and NEON, but since this
>> is optional, it was a matter of time before we got one ;-)
>
> The ZTE 3.4 kernel code suggests that there is/was a zx297520v2 that was 
> Cortex A9 based, and then ZTE replaced the Cortex-A9 with a Cortex-A53 and 
> left the rest of the system unchanged.
>
> A later version of this SoC, zx298501 switched to 64 bit, including kernel + 
> userland. But I don't have any hardware based on either of them.

Right, it's quite possible that v3 was a node shrink and Cortex-A9
was not available for the new process.

>> Support for 64-bit cores is actually quite rudimentary in 32-bit
>> more, as we are missing a lot of the errata workarounds and ARMv8
>> specific features in the kernel. If you can figure out how to
>> use 64-bit kernel mode, that would be ideal.
>
> One of my co-hackers is giving it another try. Pairing a 64 bit kernel with 32 
> bit userspace seems reasonable. Of course the other question is what quirks 
> are hiding in the hardware when we run them in a mode the vendor never tested.

Right, that is clearly a risk. I see that we do support FPU-less
systems, e.g. 82e0191a1aa1 ("arm64: Support systems without
FP/ASIMD"), but I doubt that this code path is well tested.

For the core itself, I would expect fewer problems with 64-bit
kernels than 32-bit ones, but the problems are going to be different
of course.

For 32-bit compat userspace, there is a chance that you have
device drivers missing compat ioctl handlers, especially if you
need non-upstream drivers. There are also a few differences in
handling of deprecated instructions like ARMv6 style barriers
or unaligned ldm/stm data accesses, which require you to enable
the workarounds at boot time on 64-bit kernels.

     Arnd

Re: [RFC PATCH v2 1/7] ARM: zte: Add zx297520v3 platform support.

[Linus Walleij]

Hi Stefan,

thanks for your patch!

On Wed, Jan 28, 2026 at 9:35 PM Stefan Dösinger
<stefandoesinger@gmail.com> wrote:

> This SoC is used in low end LTE-to-WiFi routers, for example some D-Link
> DWR 932 revisions, ZTE K10, ZLT S10 4G, but also models that are branded
> and sold by ISPs themselves. They are widespread in Africa, China,
> Russia and Eastern Europe.
>
> This SoC is a relative of the zx296702 and zx296718 that had some
> upstream support until commit 89d4f98ae90d ("ARM: remove zte zx
> platform"). My eventual goal is to enable OpenWRT to run on these
> devices.

This is a noble goal.

> +Zx297520v3 SoCs use a 64 bit capable Cortex-A53 CPU and GICv3, although they
> +run in aarch32 mode only. The CPU has support EL3, but no hypervisor (EL2) and
> +it seems to lack VFP and NEON.

The practice to run 32bit kernels on 64bit capable hardware has been
pushed back in the past. When you say "they run aarch32 mode only" this
sounds like a choice, not a mandatory demand from the hardware, i.e.
it *could* run in 64bit mode.

We can see why the vendor does this because the board has only 64MB
of memory, and 64bit code is known to take up more memory.

What we recommend is usually to run a 64bit kernel with a 32bit userspace,
so the userspace still isn't too demanding in memory.

Have you been able to try this?

If it seems hard we might need to bring people in who can help with
enabling 64bit mode for the kernel.

I think Arnd might have pointers to previous conversations on the topic.

Yours,
Linus Walleij

Re: [RFC PATCH v2 0/7] Add support for ZTE zx297520v3

[Linus Walleij]

[Sorry for missing this discussion on 0/7 and posting on 1/7 instead]

On Fri, Jan 30, 2026 at 9:59 AM Arnd Bergmann <arnd@arndb.de> wrote:
> On Thu, Jan 29, 2026, at 20:38, Stefan Dösinger wrote:

> > The ZTE 3.4 kernel code suggests that there is/was a zx297520v2 that was
> > Cortex A9 based, and then ZTE replaced the Cortex-A9 with a Cortex-A53 and
> > left the rest of the system unchanged.
> >
> > A later version of this SoC, zx298501 switched to 64 bit, including kernel +
> > userland. But I don't have any hardware based on either of them.
>
> Right, it's quite possible that v3 was a node shrink and Cortex-A9
> was not available for the new process.

Would it be possible that the DRAM IP on the next version could not
even deal with such a small memory (64MB) making the in-between
SoC a desireable choice?

> >> Support for 64-bit cores is actually quite rudimentary in 32-bit
> >> more, as we are missing a lot of the errata workarounds and ARMv8
> >> specific features in the kernel. If you can figure out how to
> >> use 64-bit kernel mode, that would be ideal.
> >
> > One of my co-hackers is giving it another try. Pairing a 64 bit kernel with 32
> > bit userspace seems reasonable. Of course the other question is what quirks
> > are hiding in the hardware when we run them in a mode the vendor never tested.
>
> Right, that is clearly a risk. I see that we do support FPU-less
> systems, e.g. 82e0191a1aa1 ("arm64: Support systems without
> FP/ASIMD"), but I doubt that this code path is well tested.

I'm checking with Suzuki to see if he has tested that recently.

Yours,
Linus Walleij

Re: [RFC PATCH v2 0/7] Add support for ZTE zx297520v3

[Andre Przywara]

Hi Stefan,

On 1/28/26 21:34, Stefan Dösinger wrote:
> Hi,
> 
> In the past few weeks I worked on booting my own kernel on ZTE/Sanechip's
> zx297520v3 SoC. This SoC is a relative of the zx296718 that was once
> supported by the kernel. It is in use in a lot of LTE to WiFi routers in
> Africa, China and Eastern Europe, although some devices were sold or
> distributed by ISPs in the EU too. My goal is to make OpenWRT run on these
> devices.
> 
> I would like to ask for comments on these 7 patches to make sure they are
> going in the right direction. They are the bare minimum to get the kernel
> to start and run an interactive busybox on the UART.
> 
> Here are a few questions that I couldn't answer myself:
> 
> 1) The GIC is a GICv3, but there are some extra registers (probably on a
> different chip) to switch PPIs and SPIs between level high/level low or
> rising edge/falling edge. The only device where this matters appears to
> the timer. It uses level low IRQs, but the GIC has PPIs configured to
> level-high by default. By setting some non-standard registers, I can get
> the PPIs to level-low and the timer works OK. Is there any precedence on
> how to handle this? I am tempted to make a zte,zx29-gic-v3 .compatible
> glue that sets the PPIs to level-low on init.

Wouldn't it be possible to fix this up in firmware and not bother the 
kernel with it? It would treat this like some very platform specific 
setup, as there is probably also very little point it ever doing it any 
other way?

> 2) The boot loader doesn't set up the secure/non-secure world properly and
> doesn't enable register access to the GIC CPU interface. I found the
> Raspberry Pi 3 boot stub as a good guidance and put sample code in
> Documentation/arch/arm/zte/zx297520v3.rst . An e.g. OpenWRT build for this
> device would have to include a similar setup sequence that it runs from
> U-Boot before jumping to the kernel. Did I miss any alternatives here?

The arm64 booting.rst specifies the expectations of the kernel very 
clearly, for instance it demands the GIC to be setup correctly and be 
booted in non-secure state. The arm(32) kernel was much more forgiving, 
mostly because many firmwares couldn't be fixed, so there was no choice.
But I feel like for "new" devices we should lean on the safe side and 
use the firmware to bring the system in a sane state (pun intended).

It looks like you have access to the firmware and can change it?

> 3) The SoC has clock and reset controls in the same MMIO space, even the
> same 32 bit registers. What is the preferred way to handle this? Two
> separate clk and reset drivers that write into the same place? One
> multifunction driver that exposes clock and resets? One syscon that
> contains the reg values and two separate clk and reset drivers that
> consume the syscon?

That's quite common, and the solution is to have one driver, that acts 
as both a clock and reset controller (registers to both subsystems). 
Look at sunxi, for instance (from the sun50i-a64.dtsi):
	ccu: clock@1c20000 {
		compatible = "allwinner,sun50i-a64-ccu";
		reg = <0x01c20000 0x400>;
		#clock-cells = <1>;
		#reset-cells = <1>;
	};
	uart0: serial@1c28000 {
		....
		clocks = <&ccu CLK_BUS_UART0>;
		resets = <&ccu RST_BUS_UART0>;
	};

Find code in drivers/clk/sunxi-ng/ccu_common.c:sunxi_ccu_probe().

> 4) The CPU is a Cortex A53 running in arm32 mode (in the shipped firmware
> too). It doesn't appear to have an FPU. Reading FPSID results in an
> exception (so vfpmodule.c/vfp_init says VFP is not available). I tried
> enabling p10 and p11 in NSACR, but without success. NSACR seems to always
> read 0 too. Is this really a Cortex A53 without FPU or did I miss
> something?
> 
> 5) Relatedly, are there any advantages to running in arm64 mode? The
> devices are relatively memory constrained (64mb), so the larger binary
> size from 64 bit pointers is probably a negative, while the larger
> register set might be a positive. I doubt switching to arm64 mode is
> possible at all, but I'm nevertheless curious.

Allwinner cores also reset into EL3/AArch32, there an RMR reset brings 
it into AArch64 state. For this to work Allwinner provides a writable 
MMIO register that backs the architecturally read-only RVBAR, so you can 
program the AArch64 entry point.
https://github.com/u-boot/u-boot/blob/master/arch/arm/mach-sunxi/rmr_switch.S
Not sure if this works here, of course, but just FYI.
In any case I feel this beast is better left in arm32 land ;-)

Cheers,
Andre

> 6) The old removed zx29 code used "zte," as the vendor for the
> compatibles. Sanechips is a subsidiary of ZTE that designed these chips.
> Are there any preferences for either "zte," or "sanechips,"?
> 
> As for the rest of the hardware, my entire patchset can be found here:
> https://gitlab.com/stefandoesinger/zx297520-kernel/ . So far 3 people from
> the OpenWRT community are helping with testing on different routers (Tecno
> TR118, ZTE K10, ZLT S10 in addition to my D-Link DWR932 and HGSD R310).
> 
> USB: Standard dwc2 WiFi: rtl8192, but in the SDIO version. I hacked sdio
> into rtl8xxxu but it'll need major cleanup. ethernet: STMicro stmmac. ZTE
> wrote their own driver for it. I spent a week re-implementing it before I
> was able to match the HW to stmmac. SDIO: standard dw-mshc NAND: A 128 MB
> SPI NAND chip connected to a homebrew QSPI controller. The driver is
> copypasta from stm32-qspi, but the hardware registers seem incompatible
> LTE: A Cortex M0 is doing the heavy lifting and talks to the main CPU via
> RPMsg. I hope to be able to handle this in userspace, but I haven't looked
> into it yet. clk, pinctrl, pmdomain: My own code based on the zx2967xx
> code.
> 
> Patch changelog v2: checkpatch.pl fixes.
> 
> Stefan Dösinger (7):
>    ARM: zte: Add zx297520v3 platform support.
>    dt-bindings: arm: Add zx297520v3 board binding.
>    ARM: dts: Add D-Link DWR-932M support.
>    ARM: zte: Add support for zx29 low level debug.
>    ARM: dts: Add an armv7 timer for zx297520v3.
>    ARM: zte: Bring back ZX29 UART support.
>    ARM: dts: Declare UART1 on zx297520v3 boards.
> 
>   Documentation/arch/arm/zte/zx297520v3.rst     | 106 ++++++++++++++++++
>   .../devicetree/bindings/arm/zx29.yaml         |  20 ++++
>   MAINTAINERS                                   |   6 +
>   arch/arm/Kconfig                              |   2 +
>   arch/arm/Kconfig.debug                        |  12 ++
>   arch/arm/Makefile                             |   1 +
>   arch/arm/boot/dts/Makefile                    |   1 +
>   arch/arm/boot/dts/zte/Makefile                |   3 +
>   arch/arm/boot/dts/zte/dlink-dwr-932m.dts      |  21 ++++
>   arch/arm/boot/dts/zte/zx297520v3.dtsi         |  83 ++++++++++++++
>   arch/arm/include/debug/pl01x.S                |   7 ++
>   arch/arm/mach-zte/Kconfig                     |  23 ++++
>   arch/arm/mach-zte/Makefile                    |   2 +
>   arch/arm/mach-zte/zx297520v3.c                |  19 ++++
>   drivers/tty/serial/amba-pl011.c               |  37 ++++++
>   include/linux/amba/bus.h                      |   6 +
>   16 files changed, 349 insertions(+)
>   create mode 100644 Documentation/arch/arm/zte/zx297520v3.rst
>   create mode 100644 Documentation/devicetree/bindings/arm/zx29.yaml
>   create mode 100644 arch/arm/boot/dts/zte/Makefile
>   create mode 100644 arch/arm/boot/dts/zte/dlink-dwr-932m.dts
>   create mode 100644 arch/arm/boot/dts/zte/zx297520v3.dtsi
>   create mode 100644 arch/arm/mach-zte/Kconfig
>   create mode 100644 arch/arm/mach-zte/Makefile
>   create mode 100644 arch/arm/mach-zte/zx297520v3.c
> 
> 
> base-commit: 7d0a66e4bb9081d75c82ec4957c50034cb0ea449

Re: [RFC PATCH v2 0/7] Add support for ZTE zx297520v3

[Robin Murphy]

On 2026-01-30 8:58 am, Arnd Bergmann wrote:
> On Thu, Jan 29, 2026, at 20:38, Stefan Dösinger wrote:
>> Am Donnerstag, 29. Januar 2026, 01:00:08 Ostafrikanische Zeit schrieb Arnd
>> Bergmann:
>>> On Wed, Jan 28, 2026, at 21:34, Stefan Dösinger wrote:
>>
>> I am certain switching to EL3 is working here because I am using it in the
>> same way to set up ICC_SRE_EL*. (And yes, I know this code doesn't belong in
>> this place. It's just more comfortable for my development tree for now)
> 
> Ok

If you can do that, then:

a) You're starting in Secure SVC, which explains the GIC issues (since 
we usually expect to be dealing with the Non-Secure side of the GIC)

b) Monitor mode exists, which means EL3 is in AArch32 state (and I would 
imagine the SoC is wired to boot that way), which means you'd need to 
rewrite the entire firmware for AArch64 (most likely including an 
AArch32 stub to RMR itself into AArch64 state initially) before you 
could consider running lower ELs in AArch64.

>>> I've never seen a Cortex-A53 without FPU and NEON, but since this
>>> is optional, it was a matter of time before we got one ;-)

They certainly exist in various networking gear and other embedded 
applications, they've just never (directly) asked to run mainline Linux ;)

Cheers,
Robin.

>> The ZTE 3.4 kernel code suggests that there is/was a zx297520v2 that was
>> Cortex A9 based, and then ZTE replaced the Cortex-A9 with a Cortex-A53 and
>> left the rest of the system unchanged.
>>
>> A later version of this SoC, zx298501 switched to 64 bit, including kernel +
>> userland. But I don't have any hardware based on either of them.
> 
> Right, it's quite possible that v3 was a node shrink and Cortex-A9
> was not available for the new process.
> 
>>> Support for 64-bit cores is actually quite rudimentary in 32-bit
>>> more, as we are missing a lot of the errata workarounds and ARMv8
>>> specific features in the kernel. If you can figure out how to
>>> use 64-bit kernel mode, that would be ideal.
>>
>> One of my co-hackers is giving it another try. Pairing a 64 bit kernel with 32
>> bit userspace seems reasonable. Of course the other question is what quirks
>> are hiding in the hardware when we run them in a mode the vendor never tested.
> 
> Right, that is clearly a risk. I see that we do support FPU-less
> systems, e.g. 82e0191a1aa1 ("arm64: Support systems without
> FP/ASIMD"), but I doubt that this code path is well tested.
> 
> For the core itself, I would expect fewer problems with 64-bit
> kernels than 32-bit ones, but the problems are going to be different
> of course.
> 
> For 32-bit compat userspace, there is a chance that you have
> device drivers missing compat ioctl handlers, especially if you
> need non-upstream drivers. There are also a few differences in
> handling of deprecated instructions like ARMv6 style barriers
> or unaligned ldm/stm data accesses, which require you to enable
> the workarounds at boot time on 64-bit kernels.
> 
>       Arnd
> 

Re: [RFC PATCH v2 0/7] Add support for ZTE zx297520v3

[Stefan Dösinger]

[-- Attachment #1: Type: text/plain, Size: 3968 bytes --]

Am Freitag, 30. Januar 2026, 17:02:16 Ostafrikanische Zeit schrieben Sie:
> Hi Stefan,
> > 1) The GIC is a GICv3, but there are some extra registers (probably on a
> > different chip) to switch PPIs and SPIs between level high/level low or
> > rising edge/falling edge.
> 
> Wouldn't it be possible to fix this up in firmware and not bother the
> kernel with it? It would treat this like some very platform specific
> setup, as there is probably also very little point it ever doing it any
> other way?

Yes, this is certainly possible, and it is in a way what I am doing right now. 
As far as I understand the hardware I won't have to switch this at runtime, it 
just needs a sane default.

> The arm64 booting.rst specifies the expectations of the kernel very
> clearly, for instance it demands the GIC to be setup correctly and be
> booted in non-secure state. The arm(32) kernel was much more forgiving,
> mostly because many firmwares couldn't be fixed, so there was no choice.
> But I feel like for "new" devices we should lean on the safe side and
> use the firmware to bring the system in a sane state (pun intended).
> 
> It looks like you have access to the firmware and can change it?

Yes, we can replace Uboot on the NAND and boot our own via USB as well. ZTE 
actually provided uboot sources too. And I can certainly add some preload code 
into uimages to fix up registers, so these kinds of setup quirks won't go into 
the main kernel.

How we handle this for user-installable systems is still open. It depends on 
the risk of producing a bricked device. But we certainly have options.

And yes, they are begging to be called "insanechips" :-)

> > 3) The SoC has clock and reset controls in the same MMIO space, even the
> > same 32 bit registers. What is the preferred way to handle this? Two
> > separate clk and reset drivers that write into the same place? One
> > multifunction driver that exposes clock and resets? One syscon that
> > contains the reg values and two separate clk and reset drivers that
> > consume the syscon?
> 
> That's quite common, and the solution is to have one driver, that acts
> as both a clock and reset controller (registers to both subsystems).
> Look at sunxi, for instance (from the sun50i-a64.dtsi):

Thanks for the pointer, I'll use this as guidance.

> Allwinner cores also reset into EL3/AArch32, there an RMR reset brings
> it into AArch64 state. For this to work Allwinner provides a writable
> MMIO register that backs the architecturally read-only RVBAR, so you can
> program the AArch64 entry point.
> https://github.com/u-boot/u-boot/blob/master/arch/arm/mach-sunxi/rmr_switch.
> S Not sure if this works here, of course, but just FYI.
> In any case I feel this beast is better left in arm32 land ;-)

We tried to do something similar. We can actually change RVBAR and read back 
the changed value - and the value becomes 32 byte aligned. However, writing to 
RMR doesn't seem to do anything. The CPU just continues to execute the next 
instruction. I can even read it back later

What I'm doing in EL3:
mrc	15, 0, r0, cr12, cr0, 2	@ read RMR register
orr	r0, r0, #2			@ request reset in AArch32
mcr	15, 0, r0, cr12, cr0, 2 	@ write RMR register
isb	sy

and it merrily continues executing after that. It does that with or without 
the attempt to set RVBAR. If RMR worked I'd at least expect the hardware to 
crash in some way, not go back to the interactive uboot prompt (which 
continues to work fine). I also tried to set bits 0 and 1 (reset to aarch64) 
or set all 32 bits. There's no observable change.

We don't have any board schematics or datasheets, but I assume the 32/64 mode 
pin is wired to arm32. It may be controllable by one of the GPIOs, but I doubt 
that. So far we don't know of a way to reset the main CPU without resetting 
the entire board either.

The third way I read about was to attempt to return from 32 bit EL3 to 64 bit 
EL3, but I think I ran into some AI hallucination there.

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 870 bytes --]

Re: [RFC PATCH v2 1/7] ARM: zte: Add zx297520v3 platform support.

[Stefan Dösinger]

[-- Attachment #1: Type: text/plain, Size: 2042 bytes --]

Hi Linus,

Thanks for the replies!

Am Freitag, 30. Januar 2026, 12:07:41 Ostafrikanische Zeit schrieb Linus 
Walleij:

> The practice to run 32bit kernels on 64bit capable hardware has been
> pushed back in the past. When you say "they run aarch32 mode only" this
> sounds like a choice, not a mandatory demand from the hardware, i.e.
> it *could* run in 64bit mode.

I think ZTE could certainly have built this board + software in a way that 
runs in 64 bit mode yes. I am pessimistic that we can do this ourselves with 
purely software means.

> We can see why the vendor does this because the board has only 64MB
> of memory, and 64bit code is known to take up more memory.
> 
> What we recommend is usually to run a 64bit kernel with a 32bit userspace,
> so the userspace still isn't too demanding in memory.
> 
> Have you been able to try this?
> 
> If it seems hard we might need to bring people in who can help with
> enabling 64bit mode for the kernel.

Andre Przywara suggested switching to 64 bit via the Reset Management 
Register. The RMR seems to do nothing on this hardware (https://
lists.infradead.org/pipermail/linux-arm-kernel/2026-January/1099787.html is my 
reply in the archives).

We don't have board schematics or datasheets, but I guess AA64nAA32 is 
hardwired to 32 bit. Maybe a GPIO pin can control it, but it doesn't look like 
it. We also know of no way to reset the CPU without resetting the rest of the 
board. (since RMR doesn't seem to work)

In my previous research I came across the suggestion to do an eret from EL3 to 
EL3 and set SCR_EL3.RW to 1. We'd obviously need to set ELR_EL3 to point to 64 
bit code. However, I haven't actually seen a working example of that and my 
own attempts just ended up locking up the CPU. I don't know where I came 
across the suggestion the first time. All I can find right now is this 
article, which is clearly AI slop: https://www.systemonchips.com/switching-from-aarch32-to-aarch64-on-cortex-a55-challenges-and-solutions/ .

Do you have any other ideas we could try?

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 870 bytes --]

Re: [RFC PATCH v2 1/7] ARM: zte: Add zx297520v3 platform support.

[Linus Walleij]

Hi Stefan,

On Fri, Jan 30, 2026 at 5:38 PM Stefan Dösinger
<stefandoesinger@gmail.com> wrote:
> Andre Przywara suggested switching to 64 bit via the Reset Management
> Register. The RMR seems to do nothing on this hardware (https://
> lists.infradead.org/pipermail/linux-arm-kernel/2026-January/1099787.html is my
> reply in the archives).
>
> We don't have board schematics or datasheets, but I guess AA64nAA32 is
> hardwired to 32 bit. Maybe a GPIO pin can control it, but it doesn't look like
> it. We also know of no way to reset the CPU without resetting the rest of the
> board. (since RMR doesn't seem to work)

How typical. Well maybe this is just a new breed of 32bit machine
after all.

> In my previous research I came across the suggestion to do an eret from EL3 to
> EL3 and set SCR_EL3.RW to 1. We'd obviously need to set ELR_EL3 to point to 64
> bit code. However, I haven't actually seen a working example of that and my
> own attempts just ended up locking up the CPU. I don't know where I came
> across the suggestion the first time.

It would be my intuitive idea as well. After all, ERET is the way we do a lot
of things, such as start processes in user mode. But if it doesn't work,
well then it doesn't :/

I don't have any other ideas than to proceed with a 32bit port.

Yours,
Linus Walleij

Re: [RFC PATCH v2 1/7] ARM: zte: Add zx297520v3 platform support.

[Stefan Dösinger]

[-- Attachment #1: Type: text/plain, Size: 684 bytes --]

Am Montag, 2. Februar 2026, 12:09:03 Ostafrikanische Zeit schrieben Sie:
> Hi Stefan,

> I don't have any other ideas than to proceed with a 32bit port.

Yeah that's what I'll do.

Thanks for the help to everyone, I think I have enough guidance to disappear 
into my hacking cave for a while. I also received some feedback from people 
with different versions of this hardware, and as expected some things are 
working and some aren't. I'll probably spend the next few weeks or months 
trying to understand those devices better and submit my patches once they are 
ready for closer review. Since this is an evening hobby (and learning) project 
it might take a while.

Cheers,
Stefan

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 870 bytes --]