[PATCH v6 0/6] Introduce ASPEED AST2700 BMC SoC

[PATCH v6 0/6] Introduce ASPEED AST2700 BMC SoC

[Ryan Chen]

This introduces initial support for the Aspeed AST2700 SoC and the AST2700
Evaluation Board (EVB) to the Linux kernel. The AST27XX is the 8th
generation Baseboard Management Controller (BMC) SoC from Aspeed,
featuring improved performance, enhanced security, and expanded I/O
capabilities compared to previous generations.

AST27XX SOC Family
 - https://www.aspeedtech.com/server_ast2700/
 - https://www.aspeedtech.com/server_ast2720/
 - https://www.aspeedtech.com/server_ast2750/

Bindings Dependencies:
- scu/silicon-id: Documentation/devicetree/bindings/mfd/aspeed,ast2x00-scu.yaml
- gpio: Documentation/devicetree/bindings/gpio/aspeed,ast2400-gpio.yaml
- mdio: Documentation/devicetree/bindings/net/aspeed,ast2600-mdio.yaml
- intc0: Documentation/devicetree/bindings/interrupt-controller/aspeed,ast2700-intc0.yaml
- intc1: Documentation/devicetree/bindings/interrupt-controller/aspeed,ast2700-intc1.yaml
 - https://lore.kernel.org/all/20251022065507.1152071-2-ryan_chen@aspeedtech.com/T/#u (Reviewing)

v6:
- rebased on v6.18-rc1
- aspeed,ast2x00-scu.yaml
 - fixed dt-binding yaml issuse report.

v5:
- modify ast27XX 7th generation description to 8th generation.
- aspeed.yaml
 - modify missing blank line.
- Kconfig.platforms
 - modify ast27XX 7th generation to 8th generation.

v4:
- make CHECK_DTBS=y arch/arm64/boot/dts/aspeed/ fix.
- modify commit message remove itemlize.
- remove modify aspeed,ast2700-intc.yaml patch.
- aspeed.yaml
 - Add AST2700 board compatible.
- aspeed-g7.dtsi
 - modify all size-cells from 1 to 2.
 - add serial aliases, gpio, mdio, uart0 ~ 14.
 - add firmware for optee, reserved memory for atf and optee.
 - modify cpu@0 to cpu0: cpu@0.
 - fix intc-ic for yaml dependency.
- ast2700-evb.dts
 - update stdout-path = "serial12:115200n8";

v3:
- https://lore.kernel.org/all/20241212155237.848336-1-kevin_chen@aspeedtech.com/
- Split clk and reset driver to other commits, which are in series of
  "Add support for AST2700 clk driver".
- For BMC console by UART12, add uart12 using ASPEED INTC architecture.

aspeed,ast2700-intc.yaml
- Add minItems to 1 to fix the warning by "make dtbs_check W=1".
- Add intc1 into example.

Kconfig.platforms
  - Remove MACH_ASPEED_G7.

Ryan Chen (6):
  dt-bindings: arm: aspeed: Add AST2700 board compatible
  arm64: Kconfig: Add Aspeed SoC family (ast27XX) Kconfig support
  dt-bindings: mfd: aspeed,ast2x00-scu: allow #size-cells range
  arm64: dts: aspeed: Add initial AST2700 SoC device tree
  arm64: dts: aspeed: Add AST2700 Evaluation Board
  arm64: configs: Update defconfig for AST2700 platform support

 .../bindings/arm/aspeed/aspeed.yaml           |   6 +
 .../bindings/mfd/aspeed,ast2x00-scu.yaml      |   2 +-
 arch/arm64/Kconfig.platforms                  |   6 +
 arch/arm64/boot/dts/Makefile                  |   1 +
 arch/arm64/boot/dts/aspeed/Makefile           |   4 +
 arch/arm64/boot/dts/aspeed/aspeed-g7.dtsi     | 516 ++++++++++++++++++
 arch/arm64/boot/dts/aspeed/ast2700-evb.dts    |  22 +
 arch/arm64/configs/defconfig                  |   1 +
 8 files changed, 557 insertions(+), 1 deletion(-)
 create mode 100644 arch/arm64/boot/dts/aspeed/Makefile
 create mode 100644 arch/arm64/boot/dts/aspeed/aspeed-g7.dtsi
 create mode 100644 arch/arm64/boot/dts/aspeed/ast2700-evb.dts

-- 
2.34.1

[PATCH v6 1/6] dt-bindings: arm: aspeed: Add AST2700 board compatible

[Ryan Chen]

Add device tree compatible string for AST2700 based boards
("aspeed,ast2700-evb" and "aspeed,ast2700") to the Aspeed SoC
board bindings. This allows proper schema validation and
enables support for AST2700 platforms.

Signed-off-by: Ryan Chen <ryan_chen@aspeedtech.com>
Acked-by: Conor Dooley <conor.dooley@microchip.com>
---
 Documentation/devicetree/bindings/arm/aspeed/aspeed.yaml | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/Documentation/devicetree/bindings/arm/aspeed/aspeed.yaml b/Documentation/devicetree/bindings/arm/aspeed/aspeed.yaml
index aedefca7cf4a..1c1a12fc3a91 100644
--- a/Documentation/devicetree/bindings/arm/aspeed/aspeed.yaml
+++ b/Documentation/devicetree/bindings/arm/aspeed/aspeed.yaml
@@ -109,4 +109,10 @@ properties:
               - ufispace,ncplite-bmc
           - const: aspeed,ast2600
 
+      - description: AST2700 based boards
+        items:
+          - enum:
+              - aspeed,ast2700-evb
+          - const: aspeed,ast2700
+
 additionalProperties: true
-- 
2.34.1

[PATCH v6 2/6] arm64: Kconfig: Add Aspeed SoC family (ast27XX) Kconfig support

[Ryan Chen]

Support for Aspeed ast27XX 8th generation Aspeed BMCs.

Signed-off-by: Ryan Chen <ryan_chen@aspeedtech.com>
---
 arch/arm64/Kconfig.platforms | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/arch/arm64/Kconfig.platforms b/arch/arm64/Kconfig.platforms
index 13173795c43d..d2746107ceca 100644
--- a/arch/arm64/Kconfig.platforms
+++ b/arch/arm64/Kconfig.platforms
@@ -47,6 +47,12 @@ config ARCH_ARTPEC
 	help
 	   This enables support for the ARMv8 based ARTPEC SoC Family.
 
+config ARCH_ASPEED
+	bool "Aspeed SoC family"
+	help
+	  Say yes if you intend to run on an Aspeed ast27XX 8th generation
+          Aspeed BMCs.
+
 config ARCH_AXIADO
 	bool "Axiado SoC Family"
 	select GPIOLIB
-- 
2.34.1

[PATCH v6 3/6] dt-bindings: mfd: aspeed,ast2x00-scu: allow #size-cells range

[Ryan Chen]

The #size-cells property in the Aspeed SCU binding is currently
fixed to a constant value of 1. However, newer SoCs (ex. AST2700)
may require two size cells to describe certain subregions or
subdevices.

This patch updates the schema to allow #size-cells values in
the range of 1 to 2. This makes the binding more flexible
while maintaining compatibility with existing platforms.
It also resolves dt-binding validation warnings reported
by `make dt_binding_check`.

Signed-off-by: Ryan Chen <ryan_chen@aspeedtech.com>
---
 Documentation/devicetree/bindings/mfd/aspeed,ast2x00-scu.yaml | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/mfd/aspeed,ast2x00-scu.yaml b/Documentation/devicetree/bindings/mfd/aspeed,ast2x00-scu.yaml
index da1887d7a8fe..ee7855845e97 100644
--- a/Documentation/devicetree/bindings/mfd/aspeed,ast2x00-scu.yaml
+++ b/Documentation/devicetree/bindings/mfd/aspeed,ast2x00-scu.yaml
@@ -38,7 +38,7 @@ properties:
     maximum: 2
 
   '#size-cells':
-    const: 1
+    enum: [1, 2]
 
   '#clock-cells':
     const: 1
-- 
2.34.1

[PATCH v6 4/6] arm64: dts: aspeed: Add initial AST2700 SoC device tree

[Ryan Chen]

Add initial device tree for the ASPEED 8th BMC SoC family.

Signed-off-by: Ryan Chen <ryan_chen@aspeedtech.com>
---
 arch/arm64/boot/dts/aspeed/aspeed-g7.dtsi | 516 ++++++++++++++++++++++
 1 file changed, 516 insertions(+)
 create mode 100644 arch/arm64/boot/dts/aspeed/aspeed-g7.dtsi

diff --git a/arch/arm64/boot/dts/aspeed/aspeed-g7.dtsi b/arch/arm64/boot/dts/aspeed/aspeed-g7.dtsi
new file mode 100644
index 000000000000..be6ca2739958
--- /dev/null
+++ b/arch/arm64/boot/dts/aspeed/aspeed-g7.dtsi
@@ -0,0 +1,516 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+#include <dt-bindings/clock/aspeed,ast2700-scu.h>
+#include <dt-bindings/reset/aspeed,ast2700-scu.h>
+#include <dt-bindings/interrupt-controller/arm-gic.h>
+#include <dt-bindings/interrupt-controller/aspeed-scu-ic.h>
+
+/ {
+	compatible = "aspeed,ast2700";
+	#address-cells = <2>;
+	#size-cells = <2>;
+	interrupt-parent = <&gic>;
+
+	aliases {
+		serial0 = &uart0;
+		serial1 = &uart1;
+		serial2 = &uart2;
+		serial3 = &uart3;
+		serial4 = &uart4;
+		serial5 = &uart5;
+		serial6 = &uart6;
+		serial7 = &uart7;
+		serial8 = &uart8;
+		serial9 = &uart9;
+		serial10 = &uart10;
+		serial11 = &uart11;
+		serial12 = &uart12;
+		serial13 = &uart13;
+		serial14 = &uart14;
+	};
+
+	cpus {
+		#address-cells = <2>;
+		#size-cells = <0>;
+
+		cpu0: cpu@0 {
+			device_type = "cpu";
+			compatible = "arm,cortex-a35";
+			reg = <0x0 0x0>;
+			enable-method = "psci";
+			i-cache-size = <0x8000>;
+			i-cache-line-size = <64>;
+			i-cache-sets = <256>;
+			d-cache-size = <0x8000>;
+			d-cache-line-size = <64>;
+			d-cache-sets = <128>;
+			next-level-cache = <&l2>;
+		};
+
+		cpu1: cpu@1 {
+			device_type = "cpu";
+			compatible = "arm,cortex-a35";
+			reg = <0x0 0x1>;
+			enable-method = "psci";
+			i-cache-size = <0x8000>;
+			i-cache-line-size = <64>;
+			i-cache-sets = <256>;
+			d-cache-size = <0x8000>;
+			d-cache-line-size = <64>;
+			d-cache-sets = <128>;
+			next-level-cache = <&l2>;
+		};
+
+		cpu2: cpu@2 {
+			device_type = "cpu";
+			compatible = "arm,cortex-a35";
+			reg = <0x0 0x2>;
+			enable-method = "psci";
+			i-cache-size = <0x8000>;
+			i-cache-line-size = <64>;
+			i-cache-sets = <256>;
+			d-cache-size = <0x8000>;
+			d-cache-line-size = <64>;
+			d-cache-sets = <128>;
+			next-level-cache = <&l2>;
+		};
+
+		cpu3: cpu@3 {
+			device_type = "cpu";
+			compatible = "arm,cortex-a35";
+			reg = <0x0 0x3>;
+			enable-method = "psci";
+			i-cache-size = <0x8000>;
+			i-cache-line-size = <64>;
+			i-cache-sets = <256>;
+			d-cache-size = <0x8000>;
+			d-cache-line-size = <64>;
+			d-cache-sets = <128>;
+			next-level-cache = <&l2>;
+		};
+
+		l2: l2-cache0 {
+			compatible = "cache";
+			cache-level = <2>;
+			cache-unified;
+			cache-size = <0x80000>;
+			cache-line-size = <64>;
+			cache-sets = <1024>;
+		};
+	};
+
+	firmware {
+		optee: optee {
+			compatible = "linaro,optee-tz";
+			method = "smc";
+		};
+	};
+
+	reserved-memory {
+		#address-cells = <2>;
+		#size-cells = <2>;
+		ranges;
+
+		atf: trusted-firmware-a@430000000 {
+			reg = <0x4 0x30000000 0x0 0x80000>;
+			no-map;
+		};
+
+		optee_core: optee-core@430080000 {
+			reg = <0x4 0x30080000 0x0 0x1000000>;
+			no-map;
+		};
+	};
+
+	arm-pmu {
+		compatible = "arm,cortex-a35-pmu";
+		interrupts = <GIC_PPI 7 (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_HIGH)>;
+	};
+
+	psci {
+		compatible = "arm,psci-1.0";
+		method = "smc";
+	};
+
+	timer {
+		compatible = "arm,armv8-timer";
+		interrupts = <GIC_PPI 13 (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_LOW)>,
+			     <GIC_PPI 14 (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_LOW)>,
+			     <GIC_PPI 11 (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_LOW)>,
+			     <GIC_PPI 10 (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_LOW)>;
+		arm,cpu-registers-not-fw-configured;
+		always-on;
+	};
+
+	gic: interrupt-controller@12200000 {
+		compatible = "arm,gic-v3";
+		reg = <0 0x12200000 0 0x10000>, /* GICD */
+		      <0 0x12280000 0 0x80000>, /* GICR */
+		      <0 0x40440000 0 0x1000>;  /* GICC */
+		interrupts = <GIC_PPI 9 (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_HIGH)>;
+		#interrupt-cells = <3>;
+		interrupt-controller;
+	};
+
+	soc0: soc@10000000 {
+		compatible = "simple-bus";
+		#address-cells = <2>;
+		#size-cells = <2>;
+		ranges = <0x0 0x0 0x0 0x10000000 0x0 0x4000000>;
+
+		intc0: interrupt-controller@12100000 {
+			compatible = "aspeed,ast2700-intc0";
+			reg = <0 0x12100000 0 0x4000>;
+			#address-cells = <1>;
+			#size-cells = <1>;
+			ranges = <0x0 0x0 0x12100000 0x4000>;
+
+			intc0_11: interrupt-controller@1b00 {
+				#interrupt-cells = <1>;
+				interrupt-controller;
+				compatible = "aspeed,ast2700-intc0-ic";
+				reg = <0x1b00 0x10>;
+				interrupts = <GIC_SPI 192 IRQ_TYPE_LEVEL_HIGH>,
+						<GIC_SPI 193 IRQ_TYPE_LEVEL_HIGH>,
+						<GIC_SPI 194 IRQ_TYPE_LEVEL_HIGH>,
+						<GIC_SPI 195 IRQ_TYPE_LEVEL_HIGH>,
+						<GIC_SPI 196 IRQ_TYPE_LEVEL_HIGH>,
+						<GIC_SPI 197 IRQ_TYPE_LEVEL_HIGH>,
+						<GIC_SPI 198 IRQ_TYPE_LEVEL_HIGH>,
+						<GIC_SPI 199 IRQ_TYPE_LEVEL_HIGH>,
+						<GIC_SPI 200 IRQ_TYPE_LEVEL_HIGH>,
+						<GIC_SPI 201 IRQ_TYPE_LEVEL_HIGH>;
+			};
+		};
+
+		syscon0: syscon@12c02000 {
+			compatible = "aspeed,ast2700-scu0", "syscon", "simple-mfd";
+			reg = <0x0 0x12c02000 0x0 0x1000>;
+			ranges = <0x0 0x0 0x12c02000 0x1000>;
+			#address-cells = <1>;
+			#size-cells = <1>;
+			#clock-cells = <1>;
+			#reset-cells = <1>;
+
+			silicon-id@0 {
+				compatible = "aspeed,ast2700-silicon-id", "aspeed,silicon-id";
+				reg = <0x0 0x4>;
+			};
+
+			scu_ic0: interrupt-controller@1d0 {
+				compatible = "aspeed,ast2700-scu-ic0";
+				reg = <0x1d0 0xc>;
+				#interrupt-cells = <1>;
+				interrupts = <GIC_SPI 97 IRQ_TYPE_LEVEL_HIGH>;
+				interrupt-controller;
+			};
+
+			scu_ic1: interrupt-controller@1e0 {
+				compatible = "aspeed,ast2700-scu-ic1";
+				reg = <0x1e0 0xc>;
+				#interrupt-cells = <1>;
+				interrupts = <GIC_SPI 98 IRQ_TYPE_LEVEL_HIGH>;
+				interrupt-controller;
+			};
+		};
+
+		gpio0: gpio@12c11000 {
+			#gpio-cells = <2>;
+			gpio-controller;
+			compatible = "aspeed,ast2700-gpio";
+			reg = <0x0 0x12c11000 0x0 0x1000>;
+			interrupts = <GIC_SPI 11 IRQ_TYPE_LEVEL_HIGH>;
+			ngpios = <12>;
+			clocks = <&syscon0 SCU0_CLK_APB>;
+			interrupt-controller;
+			#interrupt-cells = <2>;
+		};
+
+		uart4: serial@12c1a000 {
+			compatible = "ns16550a";
+			reg = <0x0 0x12c1a000 0x0 0x1000>;
+			reg-shift = <2>;
+			reg-io-width = <4>;
+			clocks = <&syscon0 SCU0_CLK_GATE_UART4CLK>;
+			interrupts = <GIC_SPI 8 IRQ_TYPE_LEVEL_HIGH>;
+			no-loopback-test;
+			status = "disabled";
+		};
+	};
+
+	soc1: soc@14000000 {
+		compatible = "simple-bus";
+		#address-cells = <2>;
+		#size-cells = <2>;
+		ranges = <0x0 0x0 0x0 0x14000000 0x0 0x10000000>;
+
+		mdio0: mdio@14040000 {
+			compatible = "aspeed,ast2600-mdio";
+			reg = <0 0x14040000 0 0x8>;
+			resets = <&syscon1 SCU1_RESET_MII>;
+			status = "disabled";
+		};
+
+		mdio1: mdio@14040008 {
+			compatible = "aspeed,ast2600-mdio";
+			reg = <0 0x14040008 0 0x8>;
+			resets = <&syscon1 SCU1_RESET_MII>;
+			status = "disabled";
+		};
+
+		mdio2: mdio@14040010 {
+			compatible = "aspeed,ast2600-mdio";
+			reg = <0 0x14040010 0 0x8>;
+			resets = <&syscon1 SCU1_RESET_MII>;
+			status = "disabled";
+		};
+
+		syscon1: syscon@14c02000 {
+			compatible = "aspeed,ast2700-scu1", "syscon", "simple-mfd";
+			reg = <0x0 0x14c02000 0x0 0x1000>;
+			ranges = <0x0 0x0 0x14c02000 0x1000>;
+			#address-cells = <1>;
+			#size-cells = <1>;
+			#clock-cells = <1>;
+			#reset-cells = <1>;
+
+			scu_ic2: interrupt-controller@100 {
+				compatible = "aspeed,ast2700-scu-ic2";
+				reg = <0x100 0x8>;
+				#interrupt-cells = <1>;
+				interrupts-extended = <&intc1_5 0>;
+				interrupt-controller;
+			};
+
+			scu_ic3: interrupt-controller@108 {
+				compatible = "aspeed,ast2700-scu-ic3";
+				reg = <0x108 0x8>;
+				#interrupt-cells = <1>;
+				interrupts-extended = <&intc1_5 26>;
+				interrupt-controller;
+			};
+
+		};
+
+		gpio1: gpio@14c0b000 {
+			#gpio-cells = <2>;
+			gpio-controller;
+			compatible = "aspeed,ast2700-gpio";
+			reg = <0x0 0x14c0b000 0x0 0x1000>;
+			interrupts-extended = <&intc1_2 18>;
+			ngpios = <216>;
+			clocks = <&syscon1 SCU1_CLK_AHB>;
+			interrupt-controller;
+			#interrupt-cells = <2>;
+		};
+
+		intc1: interrupt-controller@14c18000 {
+			compatible = "aspeed,ast2700-intc1";
+			reg = <0 0x14c18000 0 0x400>;
+			#address-cells = <1>;
+			#size-cells = <1>;
+			ranges = <0x0 0x0 0x14c18000 0x400>;
+
+			intc1_0: interrupt-controller@100 {
+				compatible = "aspeed,ast2700-intc1-ic";
+				reg = <0x100 0x10>;
+				#interrupt-cells = <1>;
+				interrupt-controller;
+				interrupts-extended = <&intc0_11 0>;
+			};
+
+			intc1_1: interrupt-controller@110 {
+				compatible = "aspeed,ast2700-intc1-ic";
+				reg = <0x110 0x10>;
+				#interrupt-cells = <1>;
+				interrupt-controller;
+				interrupts-extended = <&intc0_11 1>;
+			};
+
+			intc1_2: interrupt-controller@120 {
+				compatible = "aspeed,ast2700-intc1-ic";
+				reg = <0x120 0x10>;
+				#interrupt-cells = <1>;
+				interrupt-controller;
+				interrupts-extended = <&intc0_11 2>;
+			};
+
+			intc1_3: interrupt-controller@130 {
+				compatible = "aspeed,ast2700-intc1-ic";
+				reg = <0x130 0x10>;
+				#interrupt-cells = <1>;
+				interrupt-controller;
+				interrupts-extended = <&intc0_11 3>;
+			};
+
+			intc1_4: interrupt-controller@140 {
+				compatible = "aspeed,ast2700-intc1-ic";
+				reg = <0x140 0x10>;
+				#interrupt-cells = <1>;
+				interrupt-controller;
+				interrupts-extended = <&intc0_11 4>;
+			};
+
+			intc1_5: interrupt-controller@150 {
+				compatible = "aspeed,ast2700-intc1-ic";
+				reg = <0x150 0x10>;
+				#interrupt-cells = <1>;
+				interrupt-controller;
+				interrupts-extended = <&intc0_11 5>;
+			};
+		};
+
+		uart0: serial@14c33000 {
+			compatible = "ns16550a";
+			reg = <0x0 0x14c33000 0x0 0x100>;
+			reg-shift = <2>;
+			reg-io-width = <4>;
+			clocks = <&syscon1 SCU1_CLK_GATE_UART0CLK>;
+			interrupts-extended = <&intc1_4 7>;
+			no-loopback-test;
+			status = "disabled";
+		};
+
+		uart1: serial@14c33100 {
+			compatible = "ns16550a";
+			reg = <0x0 0x14c33100 0x0 0x100>;
+			reg-shift = <2>;
+			reg-io-width = <4>;
+			clocks = <&syscon1 SCU1_CLK_GATE_UART1CLK>;
+			interrupts-extended = <&intc1_4 8>;
+			no-loopback-test;
+			status = "disabled";
+		};
+
+		uart2: serial@14c33200 {
+			compatible = "ns16550a";
+			reg = <0x0 0x14c33200 0x0 0x100>;
+			reg-shift = <2>;
+			reg-io-width = <4>;
+			clocks = <&syscon1 SCU1_CLK_GATE_UART2CLK>;
+			interrupts-extended = <&intc1_4 9>;
+			no-loopback-test;
+			status = "disabled";
+		};
+
+		uart3: serial@14c33300 {
+			compatible = "ns16550a";
+			reg = <0x0 0x14c33300 0x0 0x100>;
+			reg-shift = <2>;
+			reg-io-width = <4>;
+			clocks = <&syscon1 SCU1_CLK_GATE_UART3CLK>;
+			interrupts-extended = <&intc1_4 10>;
+			no-loopback-test;
+			status = "disabled";
+		};
+
+		uart5: serial@14c33400 {
+			compatible = "ns16550a";
+			reg = <0x0 0x14c33400 0x0 0x100>;
+			reg-shift = <2>;
+			reg-io-width = <4>;
+			clocks = <&syscon1 SCU1_CLK_GATE_UART5CLK>;
+			interrupts-extended = <&intc1_4 11>;
+			no-loopback-test;
+			status = "disabled";
+		};
+
+		uart6: serial@14c33500 {
+			compatible = "ns16550a";
+			reg = <0x0 0x14c33500 0x0 0x100>;
+			reg-shift = <2>;
+			reg-io-width = <4>;
+			clocks = <&syscon1 SCU1_CLK_GATE_UART6CLK>;
+			interrupts-extended = <&intc1_4 12>;
+			no-loopback-test;
+			status = "disabled";
+		};
+
+		uart7: serial@14c33600 {
+			compatible = "ns16550a";
+			reg = <0x0 0x14c33600 0x0 0x100>;
+			reg-shift = <2>;
+			reg-io-width = <4>;
+			clocks = <&syscon1 SCU1_CLK_GATE_UART7CLK>;
+			interrupts-extended = <&intc1_4 13>;
+			no-loopback-test;
+			status = "disabled";
+		};
+
+		uart8: serial@14c33700 {
+			compatible = "ns16550a";
+			reg = <0x0 0x14c33700 0x0 0x100>;
+			reg-shift = <2>;
+			reg-io-width = <4>;
+			clocks = <&syscon1 SCU1_CLK_GATE_UART8CLK>;
+			interrupts-extended = <&intc1_4 14>;
+			no-loopback-test;
+			status = "disabled";
+		};
+
+		uart9: serial@14c33800 {
+			compatible = "ns16550a";
+			reg = <0x0 0x14c33800 0x0 0x100>;
+			reg-shift = <2>;
+			reg-io-width = <4>;
+			clocks = <&syscon1 SCU1_CLK_GATE_UART9CLK>;
+			interrupts-extended = <&intc1_4 15>;
+			no-loopback-test;
+			status = "disabled";
+		};
+
+		uart10: serial@14c33900 {
+			compatible = "ns16550a";
+			reg = <0x0 0x14c33900 0x0 0x100>;
+			reg-shift = <2>;
+			reg-io-width = <4>;
+			clocks = <&syscon1 SCU1_CLK_GATE_UART10CLK>;
+			interrupts-extended = <&intc1_4 16>;
+			no-loopback-test;
+			status = "disabled";
+		};
+
+		uart11: serial@14c33a00 {
+			compatible = "ns16550a";
+			reg = <0x0 0x14c33a00 0x0 0x100>;
+			reg-shift = <2>;
+			reg-io-width = <4>;
+			clocks = <&syscon1 SCU1_CLK_GATE_UART11CLK>;
+			interrupts-extended = <&intc1_4 17>;
+			no-loopback-test;
+			status = "disabled";
+		};
+
+		uart12: serial@14c33b00 {
+			compatible = "ns16550a";
+			reg = <0x0 0x14c33b00 0x0 0x100>;
+			reg-shift = <2>;
+			reg-io-width = <4>;
+			clocks = <&syscon1 SCU1_CLK_GATE_UART12CLK>;
+			interrupts-extended = <&intc1_4 18>;
+			no-loopback-test;
+			status = "disabled";
+		};
+
+		uart13: serial@14c33c00 {
+			compatible = "ns16550a";
+			reg = <0x0 0x14c33c00 0x0 0x100>;
+			reg-shift = <2>;
+			reg-io-width = <4>;
+			clocks = <&syscon1 SCU1_CLK_UART13>;
+			interrupts-extended = <&intc1_0 23>;
+			no-loopback-test;
+			status = "disabled";
+		};
+
+		uart14: serial@14c33d00 {
+			compatible = "ns16550a";
+			reg = <0x0 0x14c33d00 0x0 0x100>;
+			reg-shift = <2>;
+			reg-io-width = <4>;
+			clocks = <&syscon1 SCU1_CLK_UART14>;
+			interrupts-extended = <&intc1_1 23>;
+			no-loopback-test;
+			status = "disabled";
+		};
+	};
+};
-- 
2.34.1

[PATCH v6 5/6] arm64: dts: aspeed: Add AST2700 Evaluation Board

[Ryan Chen]

ASPEED AST2700 EVB is prototype development board based
on AST2700 SOC.

Signed-off-by: Ryan Chen <ryan_chen@aspeedtech.com>
---
 arch/arm64/boot/dts/Makefile               |  1 +
 arch/arm64/boot/dts/aspeed/Makefile        |  4 ++++
 arch/arm64/boot/dts/aspeed/ast2700-evb.dts | 22 ++++++++++++++++++++++
 3 files changed, 27 insertions(+)
 create mode 100644 arch/arm64/boot/dts/aspeed/Makefile
 create mode 100644 arch/arm64/boot/dts/aspeed/ast2700-evb.dts

diff --git a/arch/arm64/boot/dts/Makefile b/arch/arm64/boot/dts/Makefile
index b0844404eda1..5b8fbf5b1061 100644
--- a/arch/arm64/boot/dts/Makefile
+++ b/arch/arm64/boot/dts/Makefile
@@ -9,6 +9,7 @@ subdir-y += amlogic
 subdir-y += apm
 subdir-y += apple
 subdir-y += arm
+subdir-y += aspeed
 subdir-y += axiado
 subdir-y += bitmain
 subdir-y += blaize
diff --git a/arch/arm64/boot/dts/aspeed/Makefile b/arch/arm64/boot/dts/aspeed/Makefile
new file mode 100644
index 000000000000..ffe7e15017cc
--- /dev/null
+++ b/arch/arm64/boot/dts/aspeed/Makefile
@@ -0,0 +1,4 @@
+# SPDX-License-Identifier: GPL-2.0
+
+dtb-$(CONFIG_ARCH_ASPEED) += \
+	ast2700-evb.dtb
diff --git a/arch/arm64/boot/dts/aspeed/ast2700-evb.dts b/arch/arm64/boot/dts/aspeed/ast2700-evb.dts
new file mode 100644
index 000000000000..654b36ec24de
--- /dev/null
+++ b/arch/arm64/boot/dts/aspeed/ast2700-evb.dts
@@ -0,0 +1,22 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+
+/dts-v1/;
+#include "aspeed-g7.dtsi"
+
+/ {
+	model = "AST2700 EVB";
+	compatible = "aspeed,ast2700-evb", "aspeed,ast2700";
+
+	chosen {
+		stdout-path = "serial12:115200n8";
+	};
+
+	memory@400000000 {
+		device_type = "memory";
+		reg = <0x4 0x00000000 0x0 0x40000000>;
+	};
+};
+
+&uart12 {
+	status = "okay";
+};
-- 
2.34.1

[PATCH v6 6/6] arm64: configs: Update defconfig for AST2700 platform support

[Ryan Chen]

Enable options for ASPEED AST2700 SoC.

Signed-off-by: Ryan Chen <ryan_chen@aspeedtech.com>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
---
 arch/arm64/configs/defconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
index e3a2d37bd104..ca2978dd1ccc 100644
--- a/arch/arm64/configs/defconfig
+++ b/arch/arm64/configs/defconfig
@@ -39,6 +39,7 @@ CONFIG_ARCH_SUNXI=y
 CONFIG_ARCH_ALPINE=y
 CONFIG_ARCH_APPLE=y
 CONFIG_ARCH_ARTPEC=y
+CONFIG_ARCH_ASPEED=y
 CONFIG_ARCH_AXIADO=y
 CONFIG_ARCH_BCM=y
 CONFIG_ARCH_BCM2835=y
-- 
2.34.1

Re: [PATCH v6 3/6] dt-bindings: mfd: aspeed,ast2x00-scu: allow #size-cells range

[Krzysztof Kozlowski]

On 22/10/2025 09:05, Ryan Chen wrote:
> The #size-cells property in the Aspeed SCU binding is currently
> fixed to a constant value of 1. However, newer SoCs (ex. AST2700)
> may require two size cells to describe certain subregions or
> subdevices.
> 
> This patch updates the schema to allow #size-cells values in
> the range of 1 to 2. This makes the binding more flexible
> while maintaining compatibility with existing platforms.
> It also resolves dt-binding validation warnings reported
> by `make dt_binding_check`.
> 
> Signed-off-by: Ryan Chen <ryan_chen@aspeedtech.com>
> ---
>  Documentation/devicetree/bindings/mfd/aspeed,ast2x00-scu.yaml | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/Documentation/devicetree/bindings/mfd/aspeed,ast2x00-scu.yaml b/Documentation/devicetree/bindings/mfd/aspeed,ast2x00-scu.yaml
> index da1887d7a8fe..ee7855845e97 100644
> --- a/Documentation/devicetree/bindings/mfd/aspeed,ast2x00-scu.yaml
> +++ b/Documentation/devicetree/bindings/mfd/aspeed,ast2x00-scu.yaml
> @@ -38,7 +38,7 @@ properties:
>      maximum: 2
>  
>    '#size-cells':
> -    const: 1
> +    enum: [1, 2]
>  

I said no last time and now when we see the DTS it is visible it makes
no sense. Please reply in the DTS patch in the EXACT place where this is
being used.

NAK

Best regards,
Krzysztof

Re: [PATCH v6 3/6] dt-bindings: mfd: aspeed,ast2x00-scu: allow #size-cells range

[Krzysztof Kozlowski]

On 22/10/2025 09:05, Ryan Chen wrote:
> The #size-cells property in the Aspeed SCU binding is currently
> fixed to a constant value of 1. However, newer SoCs (ex. AST2700)
> may require two size cells to describe certain subregions or
> subdevices.
> 
> This patch updates the schema to allow #size-cells values in
> the range of 1 to 2. This makes the binding more flexible
> while maintaining compatibility with existing platforms.
> It also resolves dt-binding validation warnings reported
> by `make dt_binding_check`.

There is no such warning! I think I told you that already. Don't invent
fake, future warnings.

Best regards,
Krzysztof

RE: [PATCH v6 3/6] dt-bindings: mfd: aspeed,ast2x00-scu: allow #size-cells range

[Ryan Chen]

> Subject: Re: [PATCH v6 3/6] dt-bindings: mfd: aspeed,ast2x00-scu: allow
> #size-cells range
> 
> On 22/10/2025 09:05, Ryan Chen wrote:
> > The #size-cells property in the Aspeed SCU binding is currently fixed
> > to a constant value of 1. However, newer SoCs (ex. AST2700) may
> > require two size cells to describe certain subregions or subdevices.
> >
> > This patch updates the schema to allow #size-cells values in the range
> > of 1 to 2. This makes the binding more flexible while maintaining
> > compatibility with existing platforms.
> > It also resolves dt-binding validation warnings reported by `make
> > dt_binding_check`.
> 
> There is no such warning! I think I told you that already. Don't invent fake,
> future warnings.

Sorry, I understand your point, will remove this patch.
> 
> Best regards,
> Krzysztof

Re: [PATCH v6 4/6] arm64: dts: aspeed: Add initial AST2700 SoC device tree

[Arnd Bergmann]

On Wed, Oct 22, 2025, at 09:05, Ryan Chen wrote:
> Add initial device tree for the ASPEED 8th BMC SoC family.
>
> Signed-off-by: Ryan Chen <ryan_chen@aspeedtech.com>

I think this is the place where you'd want to put some information
about the chip itself. I know what it is, but others may not
know anything about it.
 
> +	aliases {
> +		serial0 = &uart0;
> +		serial1 = &uart1;
> +		serial2 = &uart2;
> +		serial3 = &uart3;
> +		serial4 = &uart4;
> +		serial5 = &uart5;
> +		serial6 = &uart6;
> +		serial7 = &uart7;
> +		serial8 = &uart8;
> +		serial9 = &uart9;
> +		serial10 = &uart10;
> +		serial11 = &uart11;
> +		serial12 = &uart12;
> +		serial13 = &uart13;
> +		serial14 = &uart14;
> +	};

This looks like you just list all the uarts that are present
on the chip, which is not how the aliases are meant to be
used. Move this block into the board specific file and
only list the ones that are actually enabled on that particular
board.

In particular, the alias names are meant to be local to the
board and don't usually correspond to the numbering inside
of the chip. In the defconfig, we currently set
CONFIG_SERIAL_8250_NR_UARTS=8, which is enough for any
board we support so far, but that means only the first
8 aliases in the list will actually work.

> +	soc0: soc@10000000 {
> +		compatible = "simple-bus";
> +		#address-cells = <2>;
> +		#size-cells = <2>;
> +		ranges = <0x0 0x0 0x0 0x10000000 0x0 0x4000000>;
> +
> +		intc0: interrupt-controller@12100000 {
> +			compatible = "aspeed,ast2700-intc0";
> +			reg = <0 0x12100000 0 0x4000>;
> +			#address-cells = <1>;
> +			#size-cells = <1>;
> +			ranges = <0x0 0x0 0x12100000 0x4000>;

This doesn't seem to add up: you define a local register
space for the soc from 0x0 to 0x4000000, but the registers of
the child devices are above 0x4000000.

I suspect that you forgot to adjust all the addresses in
the child devices to be inside of that range.

> +	soc1: soc@14000000 {
> +		compatible = "simple-bus";
> +		#address-cells = <2>;
> +		#size-cells = <2>;
> +		ranges = <0x0 0x0 0x0 0x14000000 0x0 0x10000000>;

This probably needs some explanation: why are there two 'soc@...'
devices? Is this literally two chips in the system, or are you
describing two buses inside of the same SoC?

> +
> +		mdio0: mdio@14040000 {
> +			compatible = "aspeed,ast2600-mdio";
> +			reg = <0 0x14040000 0 0x8>;
> +			resets = <&syscon1 SCU1_RESET_MII>;
> +			status = "disabled";
> +		};

I see that you use the old compatible="aspeed,ast2600-mdio" string
exclusively here. While this works, I would suggest you list both
a more specific "aspeed,ast2700-mdio" string to refer to the version
in this chip as well as the fallback "aspeed,ast2600-mdio" string
as the generic identifier.

The binding obviously has to describe both in that case, but the
driver does not need to be modified as long as both behave the
same way.

> +
> +		syscon1: syscon@14c02000 {
> +			compatible = "aspeed,ast2700-scu1", "syscon", "simple-mfd";
> +			reg = <0x0 0x14c02000 0x0 0x1000>;
> +			ranges = <0x0 0x0 0x14c02000 0x1000>;
> +			#address-cells = <1>;
> +			#size-cells = <1>;
> +			#clock-cells = <1>;
> +			#reset-cells = <1>;
> +
> +			scu_ic2: interrupt-controller@100 {
> +				compatible = "aspeed,ast2700-scu-ic2";
> +				reg = <0x100 0x8>;
> +				#interrupt-cells = <1>;
> +				interrupts-extended = <&intc1_5 0>;
> +				interrupt-controller;
> +			};
> +
> +			scu_ic3: interrupt-controller@108 {
> +				compatible = "aspeed,ast2700-scu-ic3";
> +				reg = <0x108 0x8>;
> +				#interrupt-cells = <1>;
> +				interrupts-extended = <&intc1_5 26>;
> +				interrupt-controller;
> +			};

This looks a bit silly to be honest: you have two separate devices
that each have a single register and a different compatible string?

Also you claim to be compatible with "syscon" but nothing actually
refers to the syscon node in that form?

       Arnd

RE: [PATCH v6 4/6] arm64: dts: aspeed: Add initial AST2700 SoC device tree

[Ryan Chen]

Hi Arnd,

Thanks for the detailed review and explanations.

> Subject: Re: [PATCH v6 4/6] arm64: dts: aspeed: Add initial AST2700 SoC device
> tree
> 
> On Wed, Oct 22, 2025, at 09:05, Ryan Chen wrote:
> > Add initial device tree for the ASPEED 8th BMC SoC family.
> >
> > Signed-off-by: Ryan Chen <ryan_chen@aspeedtech.com>
> 
> I think this is the place where you'd want to put some information about the
> chip itself. I know what it is, but others may not know anything about it.
> 


I've included basic information about the AST27xx family in the cover letter:
AST27XX SOC Family
 - https://www.aspeedtech.com/server_ast2700/
 - https://www.aspeedtech.com/server_ast2720/
 - https://www.aspeedtech.com/server_ast2750/

I will add here in next submit.


> > +	aliases {
> > +		serial0 = &uart0;
> > +		serial1 = &uart1;
> > +		serial2 = &uart2;
> > +		serial3 = &uart3;
> > +		serial4 = &uart4;
> > +		serial5 = &uart5;
> > +		serial6 = &uart6;
> > +		serial7 = &uart7;
> > +		serial8 = &uart8;
> > +		serial9 = &uart9;
> > +		serial10 = &uart10;
> > +		serial11 = &uart11;
> > +		serial12 = &uart12;
> > +		serial13 = &uart13;
> > +		serial14 = &uart14;
> > +	};
> 
> This looks like you just list all the uarts that are present on the chip, which is
> not how the aliases are meant to be used. Move this block into the board
> specific file and only list the ones that are actually enabled on that particular
> board.
> 
> In particular, the alias names are meant to be local to the board and don't
> usually correspond to the numbering inside of the chip. In the defconfig, we
> currently set CONFIG_SERIAL_8250_NR_UARTS=8, which is enough for any
> board we support so far, but that means only the first
> 8 aliases in the list will actually work.

Understood. I'll move the aliases block from the SoC dtsi into the
EVB board dts. For the EVB, UART12 is used as the default console,
and the board labels match the SoC numbering, so I plan to keep:

Does that look acceptable?
ast2700-evb.dts
	aliases {
		serial0 = &uart0;
		serial1 = &uart1;
		serial2 = &uart2;
		serial3 = &uart3;
		serial4 = &uart4;
		serial5 = &uart5;
		serial6 = &uart6;
		serial7 = &uart7;
		serial8 = &uart8;
		serial9 = &uart9;
		serial10 = &uart10;
		serial11 = &uart11;
		serial12 = &uart12;
		serial13 = &uart13;
		serial14 = &uart14;
}

> 
> > +	soc0: soc@10000000 {
> > +		compatible = "simple-bus";
> > +		#address-cells = <2>;
> > +		#size-cells = <2>;
> > +		ranges = <0x0 0x0 0x0 0x10000000 0x0 0x4000000>;
> > +
> > +		intc0: interrupt-controller@12100000 {
> > +			compatible = "aspeed,ast2700-intc0";
> > +			reg = <0 0x12100000 0 0x4000>;
> > +			#address-cells = <1>;
> > +			#size-cells = <1>;
> > +			ranges = <0x0 0x0 0x12100000 0x4000>;
> 
> This doesn't seem to add up: you define a local register space for the soc from
> 0x0 to 0x4000000, but the registers of the child devices are above 0x4000000.
> 
> I suspect that you forgot to adjust all the addresses in the child devices to be
> inside of that range.

Yes, that's a mistake. I'll fix the ranges property in 
soc0 to properly cover all child registers.

> 
> > +	soc1: soc@14000000 {
> > +		compatible = "simple-bus";
> > +		#address-cells = <2>;
> > +		#size-cells = <2>;
> > +		ranges = <0x0 0x0 0x0 0x14000000 0x0 0x10000000>;
> 
> This probably needs some explanation: why are there two 'soc@...'
> devices? Is this literally two chips in the system, or are you describing two
> buses inside of the same SoC?

The AST2700 is two soc connection with a property bus.
Sharing some decode registers. Each have it own ahb bus.

> 
> > +
> > +		mdio0: mdio@14040000 {
> > +			compatible = "aspeed,ast2600-mdio";
> > +			reg = <0 0x14040000 0 0x8>;
> > +			resets = <&syscon1 SCU1_RESET_MII>;
> > +			status = "disabled";
> > +		};
> 
> I see that you use the old compatible="aspeed,ast2600-mdio" string exclusively
> here. While this works, I would suggest you list both a more specific
> "aspeed,ast2700-mdio" string to refer to the version in this chip as well as the
> fallback "aspeed,ast2600-mdio" string as the generic identifier.
> 
> The binding obviously has to describe both in that case, but the driver does not
> need to be modified as long as both behave the same way.

Thanks, will submit ast2700-mdio. 
Question, should I add in here patch series?
Or go for another patch thread?

> 
> > +
> > +		syscon1: syscon@14c02000 {
> > +			compatible = "aspeed,ast2700-scu1", "syscon", "simple-mfd";
> > +			reg = <0x0 0x14c02000 0x0 0x1000>;
> > +			ranges = <0x0 0x0 0x14c02000 0x1000>;
> > +			#address-cells = <1>;
> > +			#size-cells = <1>;
> > +			#clock-cells = <1>;
> > +			#reset-cells = <1>;
> > +
> > +			scu_ic2: interrupt-controller@100 {
> > +				compatible = "aspeed,ast2700-scu-ic2";
> > +				reg = <0x100 0x8>;
> > +				#interrupt-cells = <1>;
> > +				interrupts-extended = <&intc1_5 0>;
> > +				interrupt-controller;
> > +			};
> > +
> > +			scu_ic3: interrupt-controller@108 {
> > +				compatible = "aspeed,ast2700-scu-ic3";
> > +				reg = <0x108 0x8>;
> > +				#interrupt-cells = <1>;
> > +				interrupts-extended = <&intc1_5 26>;
> > +				interrupt-controller;
> > +			};
> 
> This looks a bit silly to be honest: you have two separate devices that each have
> a single register and a different compatible string?

Yes, it have difference register define in each scu-ic#. That is compatible with design.
https://github.com/torvalds/linux/blob/master/drivers/irqchip/irq-aspeed-scu-ic.c#L45-L48

> 
> Also you claim to be compatible with "syscon" but nothing actually refers to the
> syscon node in that form?

There is another submit ongoing in pinctrl which will use syscon. 
https://lwn.net/ml/all/20250829073030.2749482-2-billy_tsai@aspeedtech.com/

Could I keep it? or I should remove it?

> 
>        Arnd

Re: [PATCH v6 4/6] arm64: dts: aspeed: Add initial AST2700 SoC device tree

[Andrew Lunn]

> > > +		mdio0: mdio@14040000 {
> > > +			compatible = "aspeed,ast2600-mdio";
> > > +			reg = <0 0x14040000 0 0x8>;
> > > +			resets = <&syscon1 SCU1_RESET_MII>;
> > > +			status = "disabled";
> > > +		};
> > 
> > I see that you use the old compatible="aspeed,ast2600-mdio" string exclusively
> > here. While this works, I would suggest you list both a more specific
> > "aspeed,ast2700-mdio" string to refer to the version in this chip as well as the
> > fallback "aspeed,ast2600-mdio" string as the generic identifier.
> > 
> > The binding obviously has to describe both in that case, but the driver does not
> > need to be modified as long as both behave the same way.
> 
> Thanks, will submit ast2700-mdio. 
> Question, should I add in here patch series?
> Or go for another patch thread?

Please submit it to net-next. Since you will have aspeed,ast2600-mdio
as a fail back, it will work until everything meets up in linux-next.

	Andrew

Re: [PATCH v6 4/6] arm64: dts: aspeed: Add initial AST2700 SoC device tree

[Arnd Bergmann]

On Thu, Oct 23, 2025, at 09:37, Ryan Chen wrote:
>
>> > +	aliases {
>> > +		serial0 = &uart0;
>> > +		serial1 = &uart1;
>> > +		serial2 = &uart2;
>> > +		serial3 = &uart3;
>> > +		serial4 = &uart4;
>> > +		serial5 = &uart5;
>> > +		serial6 = &uart6;
>> > +		serial7 = &uart7;
>> > +		serial8 = &uart8;
>> > +		serial9 = &uart9;
>> > +		serial10 = &uart10;
>> > +		serial11 = &uart11;
>> > +		serial12 = &uart12;
>> > +		serial13 = &uart13;
>> > +		serial14 = &uart14;
>> > +	};
>> 
>> This looks like you just list all the uarts that are present on the chip, which is
>> not how the aliases are meant to be used. Move this block into the board
>> specific file and only list the ones that are actually enabled on that particular
>> board.
>> 
>> In particular, the alias names are meant to be local to the board and don't
>> usually correspond to the numbering inside of the chip. In the defconfig, we
>> currently set CONFIG_SERIAL_8250_NR_UARTS=8, which is enough for any
>> board we support so far, but that means only the first
>> 8 aliases in the list will actually work.
>
> Understood. I'll move the aliases block from the SoC dtsi into the
> EVB board dts. For the EVB, UART12 is used as the default console,
> and the board labels match the SoC numbering, so I plan to keep:
>
> Does that look acceptable?
> ast2700-evb.dts
> 	aliases {
> 		serial0 = &uart0;
> 		serial1 = &uart1;
> 		serial2 = &uart2;
> 		serial3 = &uart3;
> 		serial4 = &uart4;
> 		serial5 = &uart5;
> 		serial6 = &uart6;
> 		serial7 = &uart7;
> 		serial8 = &uart8;
> 		serial9 = &uart9;
> 		serial10 = &uart10;
> 		serial11 = &uart11;
> 		serial12 = &uart12;
> 		serial13 = &uart13;
> 		serial14 = &uart14;
> }

I think this would be broken for the defconfig if the consol is
on serial12. I would recommend using serial0 as the console, like

aliases {
       serial0 = &uart12;
}

in this case. If additional uarts are enabled, add those as
further aliases.

>> 
>> > +	soc1: soc@14000000 {
>> > +		compatible = "simple-bus";
>> > +		#address-cells = <2>;
>> > +		#size-cells = <2>;
>> > +		ranges = <0x0 0x0 0x0 0x14000000 0x0 0x10000000>;
>> 
>> This probably needs some explanation: why are there two 'soc@...'
>> devices? Is this literally two chips in the system, or are you describing two
>> buses inside of the same SoC?
>
> The AST2700 is two soc connection with a property bus.
> Sharing some decode registers. Each have it own ahb bus.

I don't understand your explanation, 

>> 
>> > +
>> > +		mdio0: mdio@14040000 {
>> > +			compatible = "aspeed,ast2600-mdio";
>> > +			reg = <0 0x14040000 0 0x8>;
>> > +			resets = <&syscon1 SCU1_RESET_MII>;
>> > +			status = "disabled";
>> > +		};
>> 
>> I see that you use the old compatible="aspeed,ast2600-mdio" string exclusively
>> here. While this works, I would suggest you list both a more specific
>> "aspeed,ast2700-mdio" string to refer to the version in this chip as well as the
>> fallback "aspeed,ast2600-mdio" string as the generic identifier.
>> 
>> The binding obviously has to describe both in that case, but the driver does not
>> need to be modified as long as both behave the same way.
>
> Thanks, will submit ast2700-mdio. 
> Question, should I add in here patch series?
> Or go for another patch thread?

Since there is no corresponding driver change, I would keep the binding
change as a patch in this series.

>> > +
>> > +		syscon1: syscon@14c02000 {
>> > +			compatible = "aspeed,ast2700-scu1", "syscon", "simple-mfd";
>> > +			reg = <0x0 0x14c02000 0x0 0x1000>;
>> > +			ranges = <0x0 0x0 0x14c02000 0x1000>;
>> > +			#address-cells = <1>;
>> > +			#size-cells = <1>;
>> > +			#clock-cells = <1>;
>> > +			#reset-cells = <1>;
>> > +
>> > +			scu_ic2: interrupt-controller@100 {
>> > +				compatible = "aspeed,ast2700-scu-ic2";
>> > +				reg = <0x100 0x8>;
>> > +				#interrupt-cells = <1>;
>> > +				interrupts-extended = <&intc1_5 0>;
>> > +				interrupt-controller;
>> > +			};
>> > +
>> > +			scu_ic3: interrupt-controller@108 {
>> > +				compatible = "aspeed,ast2700-scu-ic3";
>> > +				reg = <0x108 0x8>;
>> > +				#interrupt-cells = <1>;
>> > +				interrupts-extended = <&intc1_5 26>;
>> > +				interrupt-controller;
>> > +			};
>> 
>> This looks a bit silly to be honest: you have two separate devices that each have
>> a single register and a different compatible string?
>
> Yes, it have difference register define in each scu-ic#. That is 
> compatible with design.
> https://github.com/torvalds/linux/blob/master/drivers/irqchip/irq-aspeed-scu-ic.c#L45-L48

Right, if the driver already has this design, it does make sense to
not change it for the new generation. For a newly added driver I would
probably do it differently.

>> Also you claim to be compatible with "syscon" but nothing actually refers to the
>> syscon node in that form?
>
> There is another submit ongoing in pinctrl which will use syscon. 
> https://lwn.net/ml/all/20250829073030.2749482-2-billy_tsai@aspeedtech.com/
>
> Could I keep it? or I should remove it?

The version of the driver you are linking does not appear to use
syscon, maybe this is an artifact from a previous version?

If so, you can drop it. On the other hand, this does seem to
be a classic syscon device and keeping it marked that way is not
harmful, just redundant if you actually use the more specific
compatible string.


     Arnd

RE: [PATCH v6 4/6] arm64: dts: aspeed: Add initial AST2700 SoC device tree

[Ryan Chen]

> Subject: Re: [PATCH v6 4/6] arm64: dts: aspeed: Add initial AST2700 SoC device
> tree
> 
> On Thu, Oct 23, 2025, at 09:37, Ryan Chen wrote:
> >
> >> > +	aliases {
> >> > +		serial0 = &uart0;
> >> > +		serial1 = &uart1;
> >> > +		serial2 = &uart2;
> >> > +		serial3 = &uart3;
> >> > +		serial4 = &uart4;
> >> > +		serial5 = &uart5;
> >> > +		serial6 = &uart6;
> >> > +		serial7 = &uart7;
> >> > +		serial8 = &uart8;
> >> > +		serial9 = &uart9;
> >> > +		serial10 = &uart10;
> >> > +		serial11 = &uart11;
> >> > +		serial12 = &uart12;
> >> > +		serial13 = &uart13;
> >> > +		serial14 = &uart14;
> >> > +	};
> >>
> >> This looks like you just list all the uarts that are present on the
> >> chip, which is not how the aliases are meant to be used. Move this
> >> block into the board specific file and only list the ones that are
> >> actually enabled on that particular board.
> >>
> >> In particular, the alias names are meant to be local to the board and
> >> don't usually correspond to the numbering inside of the chip. In the
> >> defconfig, we currently set CONFIG_SERIAL_8250_NR_UARTS=8, which is
> >> enough for any board we support so far, but that means only the first
> >> 8 aliases in the list will actually work.
> >
> > Understood. I'll move the aliases block from the SoC dtsi into the EVB
> > board dts. For the EVB, UART12 is used as the default console, and the
> > board labels match the SoC numbering, so I plan to keep:
> >
> > Does that look acceptable?
> > ast2700-evb.dts
> > 	aliases {
> > 		serial0 = &uart0;
> > 		serial1 = &uart1;
> > 		serial2 = &uart2;
> > 		serial3 = &uart3;
> > 		serial4 = &uart4;
> > 		serial5 = &uart5;
> > 		serial6 = &uart6;
> > 		serial7 = &uart7;
> > 		serial8 = &uart8;
> > 		serial9 = &uart9;
> > 		serial10 = &uart10;
> > 		serial11 = &uart11;
> > 		serial12 = &uart12;
> > 		serial13 = &uart13;
> > 		serial14 = &uart14;
> > }
> 
> I think this would be broken for the defconfig if the consol is on serial12. I
> would recommend using serial0 as the console, like
> 
> aliases {
>        serial0 = &uart12;
> }
> 
> in this case. If additional uarts are enabled, add those as further aliases.

Understood, I will update.

> 
> >>
> >> > +	soc1: soc@14000000 {
> >> > +		compatible = "simple-bus";
> >> > +		#address-cells = <2>;
> >> > +		#size-cells = <2>;
> >> > +		ranges = <0x0 0x0 0x0 0x14000000 0x0 0x10000000>;
> >>
> >> This probably needs some explanation: why are there two 'soc@...'
> >> devices? Is this literally two chips in the system, or are you
> >> describing two buses inside of the same SoC?
> >
> > The AST2700 is two soc connection with a property bus.
> > Sharing some decode registers. Each have it own ahb bus.
> 
> I don't understand your explanation,

Let me clarify more clearly:
The AST2700 is a dual-SoC architecture, consisting of two interconnected SoCs,
referred to as SoC0 and SoC1. Each SoC has its own clock/reset domains. 
They are connected through an internal "property bus", 
which is Aspeed's internal interconnect providing shared
address decoding and communication between the two SoCs.


> 
> >>
> >> > +
> >> > +		mdio0: mdio@14040000 {
> >> > +			compatible = "aspeed,ast2600-mdio";
> >> > +			reg = <0 0x14040000 0 0x8>;
> >> > +			resets = <&syscon1 SCU1_RESET_MII>;
> >> > +			status = "disabled";
> >> > +		};
> >>
> >> I see that you use the old compatible="aspeed,ast2600-mdio" string
> >> exclusively here. While this works, I would suggest you list both a
> >> more specific "aspeed,ast2700-mdio" string to refer to the version in
> >> this chip as well as the fallback "aspeed,ast2600-mdio" string as the generic
> identifier.
> >>
> >> The binding obviously has to describe both in that case, but the
> >> driver does not need to be modified as long as both behave the same way.
> >
> > Thanks, will submit ast2700-mdio.
> > Question, should I add in here patch series?
> > Or go for another patch thread?
> 
> Since there is no corresponding driver change, I would keep the binding change
> as a patch in this series.

Sorry, I am wondering, I will follow Andrew advice. 
Submit ast2700-mdio to net-next go out another thread.
And put submit link in cover-letter in next version.
Is it ok?

> 
> >> > +
> >> > +		syscon1: syscon@14c02000 {
> >> > +			compatible = "aspeed,ast2700-scu1", "syscon",
> "simple-mfd";
> >> > +			reg = <0x0 0x14c02000 0x0 0x1000>;
> >> > +			ranges = <0x0 0x0 0x14c02000 0x1000>;
> >> > +			#address-cells = <1>;
> >> > +			#size-cells = <1>;
> >> > +			#clock-cells = <1>;
> >> > +			#reset-cells = <1>;
> >> > +
> >> > +			scu_ic2: interrupt-controller@100 {
> >> > +				compatible = "aspeed,ast2700-scu-ic2";
> >> > +				reg = <0x100 0x8>;
> >> > +				#interrupt-cells = <1>;
> >> > +				interrupts-extended = <&intc1_5 0>;
> >> > +				interrupt-controller;
> >> > +			};
> >> > +
> >> > +			scu_ic3: interrupt-controller@108 {
> >> > +				compatible = "aspeed,ast2700-scu-ic3";
> >> > +				reg = <0x108 0x8>;
> >> > +				#interrupt-cells = <1>;
> >> > +				interrupts-extended = <&intc1_5 26>;
> >> > +				interrupt-controller;
> >> > +			};
> >>
> >> This looks a bit silly to be honest: you have two separate devices
> >> that each have a single register and a different compatible string?
> >
> > Yes, it have difference register define in each scu-ic#. That is
> > compatible with design.
> > https://github.com/torvalds/linux/blob/master/drivers/irqchip/irq-aspe
> > ed-scu-ic.c#L45-L48
> 
> Right, if the driver already has this design, it does make sense to not change it
> for the new generation. For a newly added driver I would probably do it
> differently.

Thanks
> 
> >> Also you claim to be compatible with "syscon" but nothing actually
> >> refers to the syscon node in that form?
> >
> > There is another submit ongoing in pinctrl which will use syscon.
> > https://lwn.net/ml/all/20250829073030.2749482-2-billy_tsai@aspeedtech.
> > com/
> >
> > Could I keep it? or I should remove it?
> 
> The version of the driver you are linking does not appear to use syscon, maybe
> this is an artifact from a previous version?
> 
> If so, you can drop it. On the other hand, this does seem to be a classic syscon
> device and keeping it marked that way is not harmful, just redundant if you
> actually use the more specific compatible string.

Sorry, I may not point right link
https://patchwork.ozlabs.org/project/linux-aspeed/patch/20250829073030.2749482-4-billy_tsai@aspeedtech.com/
aspeed_g7_soc0_pinctrl_probe -> aspeed_pinctrl_probe
https://github.com/torvalds/linux/blob/master/drivers/pinctrl/aspeed/pinctrl-aspeed.c#L456

That will use syscon to regmap.
> 
> 
>      Arnd

Re: [PATCH v6 4/6] arm64: dts: aspeed: Add initial AST2700 SoC device tree

[Arnd Bergmann]

On Fri, Oct 24, 2025, at 05:54, Ryan Chen wrote:
>> Subject: Re: [PATCH v6 4/6] arm64: dts: aspeed: Add initial AST2700 SoC device
>> tree
>> On Thu, Oct 23, 2025, at 09:37, Ryan Chen wrote:
>> >> > +	soc1: soc@14000000 {
>> >> > +		compatible = "simple-bus";
>> >> > +		#address-cells = <2>;
>> >> > +		#size-cells = <2>;
>> >> > +		ranges = <0x0 0x0 0x0 0x14000000 0x0 0x10000000>;
>> >>
>> >> This probably needs some explanation: why are there two 'soc@...'
>> >> devices? Is this literally two chips in the system, or are you
>> >> describing two buses inside of the same SoC?
>> >
>> > The AST2700 is two soc connection with a property bus.
>> > Sharing some decode registers. Each have it own ahb bus.
>> 
>> I don't understand your explanation,
>
> Let me clarify more clearly:
> The AST2700 is a dual-SoC architecture, consisting of two interconnected SoCs,
> referred to as SoC0 and SoC1. Each SoC has its own clock/reset domains. 
> They are connected through an internal "property bus", 
> which is Aspeed's internal interconnect providing shared
> address decoding and communication between the two SoCs.

Makes sense. Since this is a fairly unusual design, I would suggest
you add that explanation into the patch description for this
patch as well, so readers have a chance to find it when they look
at the file in the git history at a later point.

>> Since there is no corresponding driver change, I would keep the binding change
>> as a patch in this series.
>
> Sorry, I am wondering, I will follow Andrew advice. 
> Submit ast2700-mdio to net-next go out another thread.
> And put submit link in cover-letter in next version.
> Is it ok?

Yes

>> The version of the driver you are linking does not appear to use syscon, maybe
>> this is an artifact from a previous version?
>> 
>> If so, you can drop it. On the other hand, this does seem to be a classic syscon
>> device and keeping it marked that way is not harmful, just redundant if you
>> actually use the more specific compatible string.
>
> Sorry, I may not point right link
> https://patchwork.ozlabs.org/project/linux-aspeed/patch/20250829073030.2749482-4-billy_tsai@aspeedtech.com/
> aspeed_g7_soc0_pinctrl_probe -> aspeed_pinctrl_probe
> https://github.com/torvalds/linux/blob/master/drivers/pinctrl/aspeed/pinctrl-aspeed.c#L456
>
> That will use syscon to regmap.

Right, if that is the documented binding, I think keeping syscon in
the compatible list makes sense.

      Arnd

Re: [PATCH v6 4/6] arm64: dts: aspeed: Add initial AST2700 SoC device tree

[Geert Uytterhoeven]

On Thu, 23 Oct 2025 at 22:11, Arnd Bergmann <arnd@arndb.de> wrote:
> On Thu, Oct 23, 2025, at 09:37, Ryan Chen wrote:
> >> > +  aliases {
> >> > +          serial0 = &uart0;
> >> > +          serial1 = &uart1;
> >> > +          serial2 = &uart2;
> >> > +          serial3 = &uart3;
> >> > +          serial4 = &uart4;
> >> > +          serial5 = &uart5;
> >> > +          serial6 = &uart6;
> >> > +          serial7 = &uart7;
> >> > +          serial8 = &uart8;
> >> > +          serial9 = &uart9;
> >> > +          serial10 = &uart10;
> >> > +          serial11 = &uart11;
> >> > +          serial12 = &uart12;
> >> > +          serial13 = &uart13;
> >> > +          serial14 = &uart14;
> >> > +  };
> >>
> >> This looks like you just list all the uarts that are present on the chip, which is
> >> not how the aliases are meant to be used. Move this block into the board
> >> specific file and only list the ones that are actually enabled on that particular
> >> board.
> >>
> >> In particular, the alias names are meant to be local to the board and don't
> >> usually correspond to the numbering inside of the chip. In the defconfig, we
> >> currently set CONFIG_SERIAL_8250_NR_UARTS=8, which is enough for any
> >> board we support so far, but that means only the first
> >> 8 aliases in the list will actually work.
> >
> > Understood. I'll move the aliases block from the SoC dtsi into the
> > EVB board dts. For the EVB, UART12 is used as the default console,
> > and the board labels match the SoC numbering, so I plan to keep:
> >
> > Does that look acceptable?
> > ast2700-evb.dts
> >       aliases {
> >               serial0 = &uart0;
> >               serial1 = &uart1;
> >               serial2 = &uart2;
> >               serial3 = &uart3;
> >               serial4 = &uart4;
> >               serial5 = &uart5;
> >               serial6 = &uart6;
> >               serial7 = &uart7;
> >               serial8 = &uart8;
> >               serial9 = &uart9;
> >               serial10 = &uart10;
> >               serial11 = &uart11;
> >               serial12 = &uart12;
> >               serial13 = &uart13;
> >               serial14 = &uart14;
> > }
>
> I think this would be broken for the defconfig if the consol is
> on serial12. I would recommend using serial0 as the console, like
>
> aliases {
>        serial0 = &uart12;
> }
>
> in this case. If additional uarts are enabled, add those as
> further aliases.

Indeed. Are all these serial ports exposed on the board?
Aliases is mean to list only the ones that are exposed, and the alias
number should match the label on the board/port ("serialN", "debugN",
...), ideally.

Typically only a few ports are exposed, so you may end up with something like:

arch/arm64/boot/dts/renesas/rzg3s-smarc.dtsi:           serial0 = &scif1;
arch/arm64/boot/dts/renesas/rzg3s-smarc.dtsi:           serial1 = &scif3;
arch/arm64/boot/dts/renesas/rzg3s-smarc.dtsi:           serial3 = &scif0;

I deliberately picked this example, as it shows how the serialN
numbering does not need to match the scifM (or uartM) numbering.

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: [PATCH v6 4/6] arm64: dts: aspeed: Add initial AST2700 SoC device tree

[Andrew Lunn]

> > >> This probably needs some explanation: why are there two 'soc@...'
> > >> devices? Is this literally two chips in the system, or are you
> > >> describing two buses inside of the same SoC?
> > >
> > > The AST2700 is two soc connection with a property bus.
> > > Sharing some decode registers. Each have it own ahb bus.
> > 
> > I don't understand your explanation,
> 
> Let me clarify more clearly:
> The AST2700 is a dual-SoC architecture, consisting of two interconnected SoCs,
> referred to as SoC0 and SoC1. Each SoC has its own clock/reset domains. 
> They are connected through an internal "property bus", 
> which is Aspeed's internal interconnect providing shared
> address decoding and communication between the two SoCs.

By SoC are you just referring to peripherals? Or are there two sets of
CPUs as well?

If it is just peripherals, this has been done before by Marvell.

See armada-cp11x.dtsi. Marvell calls it a CP, they are identical, so
there is one description of it, which then gets included twice.

	Andrew

RE: [PATCH v6 4/6] arm64: dts: aspeed: Add initial AST2700 SoC device tree

[Ryan Chen]

> Subject: Re: [PATCH v6 4/6] arm64: dts: aspeed: Add initial AST2700 SoC device
> tree
> 
> > > >> This probably needs some explanation: why are there two 'soc@...'
> > > >> devices? Is this literally two chips in the system, or are you
> > > >> describing two buses inside of the same SoC?
> > > >
> > > > The AST2700 is two soc connection with a property bus.
> > > > Sharing some decode registers. Each have it own ahb bus.
> > >
> > > I don't understand your explanation,
> >
> > Let me clarify more clearly:
> > The AST2700 is a dual-SoC architecture, consisting of two
> > interconnected SoCs, referred to as SoC0 and SoC1. Each SoC has its own
> clock/reset domains.
> > They are connected through an internal "property bus", which is
> > Aspeed's internal interconnect providing shared address decoding and
> > communication between the two SoCs.
> 
> By SoC are you just referring to peripherals? Or are there two sets of CPUs as
> well?
> 
> If it is just peripherals, this has been done before by Marvell.
> 
> See armada-cp11x.dtsi. Marvell calls it a CP, they are identical, so there is one
> description of it, which then gets included twice.
> 
Hi Andrew,

Thanks for asking - yes, the AST2700 is indeed a dual-SoC device, not just a split peripheral domain.

SoC0, referred to as the CPU die, contains a dual-core Cortex-A35 cluster and two Cortex-M4 cores, along with its own clock/reset domains and high-speed peripheral set.
SoC1, referred to as the I/O die, contains the Boot MCU and its own clock/reset domains and low-speed peripheral set, and is responsible for system boot and control functions.

The two SoCs are interconnected through Aspeed's internal "property bus", which provides shared address decoding and inter-SoC communication between the CPU and I/O dies.

This makes the AST2700 closer to a dual-die / dual-SoC configuration, rather than the Marvell CP model you mentioned, which only duplicates peripheral blocks under a single CPU domain.

I'll add this clarification in the commit message and DTS comments in the next revision to make the relationship between the two SoCs explicit.

Best regards,
Ryan

RE: [PATCH v6 4/6] arm64: dts: aspeed: Add initial AST2700 SoC device tree

[Ryan Chen]

> Subject: Re: [PATCH v6 4/6] arm64: dts: aspeed: Add initial AST2700 SoC device
> tree
> 
> On Thu, 23 Oct 2025 at 22:11, Arnd Bergmann <arnd@arndb.de> wrote:
> > On Thu, Oct 23, 2025, at 09:37, Ryan Chen wrote:
> > >> > +  aliases {
> > >> > +          serial0 = &uart0;
> > >> > +          serial1 = &uart1;
> > >> > +          serial2 = &uart2;
> > >> > +          serial3 = &uart3;
> > >> > +          serial4 = &uart4;
> > >> > +          serial5 = &uart5;
> > >> > +          serial6 = &uart6;
> > >> > +          serial7 = &uart7;
> > >> > +          serial8 = &uart8;
> > >> > +          serial9 = &uart9;
> > >> > +          serial10 = &uart10;
> > >> > +          serial11 = &uart11;
> > >> > +          serial12 = &uart12;
> > >> > +          serial13 = &uart13;
> > >> > +          serial14 = &uart14;
> > >> > +  };
> > >>
> > >> This looks like you just list all the uarts that are present on the
> > >> chip, which is not how the aliases are meant to be used. Move this
> > >> block into the board specific file and only list the ones that are
> > >> actually enabled on that particular board.
> > >>
> > >> In particular, the alias names are meant to be local to the board
> > >> and don't usually correspond to the numbering inside of the chip.
> > >> In the defconfig, we currently set CONFIG_SERIAL_8250_NR_UARTS=8,
> > >> which is enough for any board we support so far, but that means
> > >> only the first
> > >> 8 aliases in the list will actually work.
> > >
> > > Understood. I'll move the aliases block from the SoC dtsi into the
> > > EVB board dts. For the EVB, UART12 is used as the default console,
> > > and the board labels match the SoC numbering, so I plan to keep:
> > >
> > > Does that look acceptable?
> > > ast2700-evb.dts
> > >       aliases {
> > >               serial0 = &uart0;
> > >               serial1 = &uart1;
> > >               serial2 = &uart2;
> > >               serial3 = &uart3;
> > >               serial4 = &uart4;
> > >               serial5 = &uart5;
> > >               serial6 = &uart6;
> > >               serial7 = &uart7;
> > >               serial8 = &uart8;
> > >               serial9 = &uart9;
> > >               serial10 = &uart10;
> > >               serial11 = &uart11;
> > >               serial12 = &uart12;
> > >               serial13 = &uart13;
> > >               serial14 = &uart14;
> > > }
> >
> > I think this would be broken for the defconfig if the consol is on
> > serial12. I would recommend using serial0 as the console, like
> >
> > aliases {
> >        serial0 = &uart12;
> > }
> >
> > in this case. If additional uarts are enabled, add those as further
> > aliases.
> 
> Indeed. Are all these serial ports exposed on the board?
> Aliases is mean to list only the ones that are exposed, and the alias number
> should match the label on the board/port ("serialN", "debugN", ...), ideally.
> 
> Typically only a few ports are exposed, so you may end up with something like:
> 
> arch/arm64/boot/dts/renesas/rzg3s-smarc.dtsi:           serial0 = &scif1;
> arch/arm64/boot/dts/renesas/rzg3s-smarc.dtsi:           serial1 = &scif3;
> arch/arm64/boot/dts/renesas/rzg3s-smarc.dtsi:           serial3 = &scif0;
> 
> I deliberately picked this example, as it shows how the serialN numbering does
> not need to match the scifM (or uartM) numbering.
> 
> Gr{oetje,eeting}s,
> 
>                         Geert
> 
> --
Hi Geert,

Thanks for the clarification and the Renesas example — that helps a lot.

Yes, on the AST2700 EVB only a few UARTs are actually routed out,
and UART12 is used as the main console port.

I’ll update the EVB DTS accordingly to list only the exposed ports, e.g.:

```dts
aliases {
    serial0 = &uart12; /* console */
};

> Geert Uytterhoeven -- There's lots of Linux beyond ia32 --
> geert@linux-m68k.org
> 
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like that.
>                                 -- Linus Torvalds

Re: [PATCH v6 4/6] arm64: dts: aspeed: Add initial AST2700 SoC device tree

[Andrew Lunn]

> SoC0, referred to as the CPU die, contains a dual-core Cortex-A35
> cluster and two Cortex-M4 cores, along with its own clock/reset
> domains and high-speed peripheral set.

> SoC1, referred to as the I/O die, contains the Boot MCU and its own
> clock/reset domains and low-speed peripheral set, and is responsible
> for system boot and control functions.

So is the same .dtsi file shared by both systems? How do you partition
devices so each CPU cluster knows it has exclusive access to which
peripherals?

Seems like a fun system to play core wars on.

	Andrew

RE: [PATCH v6 4/6] arm64: dts: aspeed: Add initial AST2700 SoC device tree

[Ryan Chen]

> Subject: Re: [PATCH v6 4/6] arm64: dts: aspeed: Add initial AST2700 SoC device
> tree
> 
> > SoC0, referred to as the CPU die, contains a dual-core Cortex-A35
> > cluster and two Cortex-M4 cores, along with its own clock/reset
> > domains and high-speed peripheral set.
> 
> > SoC1, referred to as the I/O die, contains the Boot MCU and its own
> > clock/reset domains and low-speed peripheral set, and is responsible
> > for system boot and control functions.
> 
> So is the same .dtsi file shared by both systems? 

This .dtsi represents the Cortex-A35 view only and is not shared
with the Cortex-M4 or the Boot MCU side, since they are separate
32-bit and 64-bit systems running independent firmware.

> How do you partition devices
> so each CPU cluster knows it has exclusive access to which peripherals?

Before the system is fully brought up, Boot MCU configure hardware 
controllers handle the resource partitioning to ensure exclusive access.

> 
> Seems like a fun system to play core wars on.
> 
> 	Andrew

Re: [PATCH v6 4/6] arm64: dts: aspeed: Add initial AST2700 SoC device tree

[Andrew Lunn]

On Mon, Oct 27, 2025 at 02:42:01AM +0000, Ryan Chen wrote:
> > Subject: Re: [PATCH v6 4/6] arm64: dts: aspeed: Add initial AST2700 SoC device
> > tree
> > 
> > > SoC0, referred to as the CPU die, contains a dual-core Cortex-A35
> > > cluster and two Cortex-M4 cores, along with its own clock/reset
> > > domains and high-speed peripheral set.
> > 
> > > SoC1, referred to as the I/O die, contains the Boot MCU and its own
> > > clock/reset domains and low-speed peripheral set, and is responsible
> > > for system boot and control functions.
> > 
> > So is the same .dtsi file shared by both systems? 
> 
> This .dtsi represents the Cortex-A35 view only and is not shared
> with the Cortex-M4 or the Boot MCU side, since they are separate
> 32-bit and 64-bit systems running independent firmware.

DT describes the hardware. The .dtsi file could be shared, you just
need different status = <>; lines in the dtb blob.

> > How do you partition devices
> > so each CPU cluster knows it has exclusive access to which peripherals?
> 
> Before the system is fully brought up, Boot MCU configure hardware 
> controllers handle the resource partitioning to ensure exclusive access.

Are you saying it modifies the .dtb blob and changes some status =
"okay"; to "disabled";?

	Andrew

Re: [PATCH v6 4/6] arm64: dts: aspeed: Add initial AST2700 SoC device tree

[Geert Uytterhoeven]

Hi Andrew,

On Mon, 27 Oct 2025 at 13:01, Andrew Lunn <andrew@lunn.ch> wrote:
> On Mon, Oct 27, 2025 at 02:42:01AM +0000, Ryan Chen wrote:
> > > Subject: Re: [PATCH v6 4/6] arm64: dts: aspeed: Add initial AST2700 SoC device
> > > tree
> > >
> > > > SoC0, referred to as the CPU die, contains a dual-core Cortex-A35
> > > > cluster and two Cortex-M4 cores, along with its own clock/reset
> > > > domains and high-speed peripheral set.
> > >
> > > > SoC1, referred to as the I/O die, contains the Boot MCU and its own
> > > > clock/reset domains and low-speed peripheral set, and is responsible
> > > > for system boot and control functions.
> > >
> > > So is the same .dtsi file shared by both systems?
> >
> > This .dtsi represents the Cortex-A35 view only and is not shared
> > with the Cortex-M4 or the Boot MCU side, since they are separate
> > 32-bit and 64-bit systems running independent firmware.
>
> DT describes the hardware. The .dtsi file could be shared, you just
> need different status = <>; lines in the dtb blob.
>
> > > How do you partition devices
> > > so each CPU cluster knows it has exclusive access to which peripherals?
> >
> > Before the system is fully brought up, Boot MCU configure hardware
> > controllers handle the resource partitioning to ensure exclusive access.
>
> Are you saying it modifies the .dtb blob and changes some status =
> "okay"; to "disabled";?

"reserved" is the appropriate status value for that.

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

RE: [PATCH v6 4/6] arm64: dts: aspeed: Add initial AST2700 SoC device tree

[Ryan Chen]

> Subject: Re: [PATCH v6 4/6] arm64: dts: aspeed: Add initial AST2700 SoC device
> tree
> 
> On Mon, Oct 27, 2025 at 02:42:01AM +0000, Ryan Chen wrote:
> > > Subject: Re: [PATCH v6 4/6] arm64: dts: aspeed: Add initial AST2700
> > > SoC device tree
> > >
> > > > SoC0, referred to as the CPU die, contains a dual-core Cortex-A35
> > > > cluster and two Cortex-M4 cores, along with its own clock/reset
> > > > domains and high-speed peripheral set.
> > >
> > > > SoC1, referred to as the I/O die, contains the Boot MCU and its
> > > > own clock/reset domains and low-speed peripheral set, and is
> > > > responsible for system boot and control functions.
> > >
> > > So is the same .dtsi file shared by both systems?
> >
> > This .dtsi represents the Cortex-A35 view only and is not shared with
> > the Cortex-M4 or the Boot MCU side, since they are separate 32-bit and
> > 64-bit systems running independent firmware.
> 
> DT describes the hardware. The .dtsi file could be shared, you just need
> different status = <>; lines in the dtb blob.

Could you please share an example of a .dtsi that is shared between
different CPU architectures?
In the AST2700 design, even though we have both Cortex-A35 (64-bit)
and Cortex-M4 (32-bit) cores, each runs in a distinct address space
and sees a different memory map.

Therefore, the dtsi view for each side needs to be separate rather than
shared.

> 
> > > How do you partition devices
> > > so each CPU cluster knows it has exclusive access to which peripherals?
> >
> > Before the system is fully brought up, Boot MCU configure hardware
> > controllers handle the resource partitioning to ensure exclusive access.
> 
> Are you saying it modifies the .dtb blob and changes some status = "okay"; to
> "disabled";?

no, the Boot MCU does not modify the .dtb blob. 
During early boot, it only configures the SCU and property
bus controllers to partition peripheral access, ensuring exclusive
ownership before others system bring up.

> 
> 	Andrew

RE: [PATCH v6 4/6] arm64: dts: aspeed: Add initial AST2700 SoC device tree

[Ryan Chen]

> Subject: Re: [PATCH v6 4/6] arm64: dts: aspeed: Add initial AST2700 SoC device
> tree
> 
> Hi Andrew,
> 
> On Mon, 27 Oct 2025 at 13:01, Andrew Lunn <andrew@lunn.ch> wrote:
> > On Mon, Oct 27, 2025 at 02:42:01AM +0000, Ryan Chen wrote:
> > > > Subject: Re: [PATCH v6 4/6] arm64: dts: aspeed: Add initial
> > > > AST2700 SoC device tree
> > > >
> > > > > SoC0, referred to as the CPU die, contains a dual-core
> > > > > Cortex-A35 cluster and two Cortex-M4 cores, along with its own
> > > > > clock/reset domains and high-speed peripheral set.
> > > >
> > > > > SoC1, referred to as the I/O die, contains the Boot MCU and its
> > > > > own clock/reset domains and low-speed peripheral set, and is
> > > > > responsible for system boot and control functions.
> > > >
> > > > So is the same .dtsi file shared by both systems?
> > >
> > > This .dtsi represents the Cortex-A35 view only and is not shared
> > > with the Cortex-M4 or the Boot MCU side, since they are separate
> > > 32-bit and 64-bit systems running independent firmware.
> >
> > DT describes the hardware. The .dtsi file could be shared, you just
> > need different status = <>; lines in the dtb blob.
> >
> > > > How do you partition devices
> > > > so each CPU cluster knows it has exclusive access to which peripherals?
> > >
> > > Before the system is fully brought up, Boot MCU configure hardware
> > > controllers handle the resource partitioning to ensure exclusive access.
> >
> > Are you saying it modifies the .dtb blob and changes some status =
> > "okay"; to "disabled";?
> 
> "reserved" is the appropriate status value for that.

Thanks for the clarification.

Since the SoC-level .dtsi is shared by all users (potentially other platforms),
I don’t actually know in advance which peripherals will be assigned to
which CPU. For this reason, marking nodes as `status = "reserved"` in the
.dtsi might be misleading.

I think it’s more appropriate to keep all peripherals as
`status = "disabled"` in the common .dtsi, and let each board-level .dts or
firmware-specific DT decide whether a device should be `okay` or `reserved`
depending on the actual resource assignment.

> 
> Gr{oetje,eeting}s,
> 
>                         Geert
> 
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 --
> geert@linux-m68k.org
> 
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like that.
>                                 -- Linus Torvalds

Re: [PATCH v6 4/6] arm64: dts: aspeed: Add initial AST2700 SoC device tree

[Arnd Bergmann]

On Wed, Oct 29, 2025, at 03:31, Ryan Chen wrote:
>> Subject: Re: [PATCH v6 4/6] arm64: dts: aspeed: Add initial AST2700 SoC device
>> tree
>> 
>> On Mon, Oct 27, 2025 at 02:42:01AM +0000, Ryan Chen wrote:
>> > > Subject: Re: [PATCH v6 4/6] arm64: dts: aspeed: Add initial AST2700
>> > > SoC device tree
>> > >
>> > > > SoC0, referred to as the CPU die, contains a dual-core Cortex-A35
>> > > > cluster and two Cortex-M4 cores, along with its own clock/reset
>> > > > domains and high-speed peripheral set.
>> > >
>> > > > SoC1, referred to as the I/O die, contains the Boot MCU and its
>> > > > own clock/reset domains and low-speed peripheral set, and is
>> > > > responsible for system boot and control functions.
>> > >
>> > > So is the same .dtsi file shared by both systems?
>> >
>> > This .dtsi represents the Cortex-A35 view only and is not shared with
>> > the Cortex-M4 or the Boot MCU side, since they are separate 32-bit and
>> > 64-bit systems running independent firmware.
>> 
>> DT describes the hardware. The .dtsi file could be shared, you just need
>> different status = <>; lines in the dtb blob.
>
> Could you please share an example of a .dtsi that is shared between
> different CPU architectures?

I can think of three that are shared between arm and riscv, with both
able to boot Linux using a variation of the same device tree, with
the .dtsi file being included from the respective other side:

arch/riscv/boot/dts/renesas/r9a07g043f.dtsi
arch/arm/boot/dts/allwinner/sun8i-t113s.dtsi
arch/arm64/boot/dts/sophgo/sg2000.dtsi

All of these however use the same basic physical address layout
as seen from the two CPUs, with only the set of on-chip devices
being slightly different, such as using the native irqchip
instance per CPU.

> In the AST2700 design, even though we have both Cortex-A35 (64-bit)
> and Cortex-M4 (32-bit) cores, each runs in a distinct address space
> and sees a different memory map.

This is similar to the Cortex-M4 on i.MX7D. This is supported by
the Linux code, but I don't see the corresponding dts file for it now,
it may have never been merged.

If you want to share the devicetree source files but have different
physical addresses, you'll need to set up 'ranges' properties in
the top-level .dtsi files that map the child buses into the CPU space
as needed. arch/arm64/boot/dts/apple/t6002.dtsi has a rather
sophisticated way of doing this where &die0 and &die1 set up the
ranges for including the same child die multiple times at different
addresses. You should be able to use similar method but make it
a lot simpler for your case.

      Arnd

Re: [PATCH v6 4/6] arm64: dts: aspeed: Add initial AST2700 SoC device tree

[Geert Uytterhoeven]

Hi Arnd,

On Wed, 29 Oct 2025 at 08:26, Arnd Bergmann <arnd@arndb.de> wrote:
> On Wed, Oct 29, 2025, at 03:31, Ryan Chen wrote:
> >> Subject: Re: [PATCH v6 4/6] arm64: dts: aspeed: Add initial AST2700 SoC device
> >> tree
> >>
> >> On Mon, Oct 27, 2025 at 02:42:01AM +0000, Ryan Chen wrote:
> >> > > Subject: Re: [PATCH v6 4/6] arm64: dts: aspeed: Add initial AST2700
> >> > > SoC device tree
> >> > >
> >> > > > SoC0, referred to as the CPU die, contains a dual-core Cortex-A35
> >> > > > cluster and two Cortex-M4 cores, along with its own clock/reset
> >> > > > domains and high-speed peripheral set.
> >> > >
> >> > > > SoC1, referred to as the I/O die, contains the Boot MCU and its
> >> > > > own clock/reset domains and low-speed peripheral set, and is
> >> > > > responsible for system boot and control functions.
> >> > >
> >> > > So is the same .dtsi file shared by both systems?
> >> >
> >> > This .dtsi represents the Cortex-A35 view only and is not shared with
> >> > the Cortex-M4 or the Boot MCU side, since they are separate 32-bit and
> >> > 64-bit systems running independent firmware.
> >>
> >> DT describes the hardware. The .dtsi file could be shared, you just need
> >> different status = <>; lines in the dtb blob.
> >
> > Could you please share an example of a .dtsi that is shared between
> > different CPU architectures?
>
> I can think of three that are shared between arm and riscv, with both
> able to boot Linux using a variation of the same device tree, with
> the .dtsi file being included from the respective other side:
>
> arch/riscv/boot/dts/renesas/r9a07g043f.dtsi
> arch/arm/boot/dts/allwinner/sun8i-t113s.dtsi
> arch/arm64/boot/dts/sophgo/sg2000.dtsi
>
> All of these however use the same basic physical address layout
> as seen from the two CPUs, with only the set of on-chip devices
> being slightly different, such as using the native irqchip
> instance per CPU.

I can't speak for the last two ones, but the first one is not what Ryan
is looking for, as r9a07g043 has either an ARM (r9a07g043u) or a
RISC-V (r9a07g043f) CPU core, not both.

> In the AST2700 design, even though we have both Cortex-A35 (64-bit)
> > and Cortex-M4 (32-bit) cores, each runs in a distinct address space
> > and sees a different memory map.
>
> This is similar to the Cortex-M4 on i.MX7D. This is supported by
> the Linux code, but I don't see the corresponding dts file for it now,
> it may have never been merged.

The keyword here is "System DT", where you have a single file describing
the whole SoC. From this, separate DTS files are generated that
describe the view for the application CPU core, real-time CPU core,
control CPU core, etc...

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: [PATCH v6 4/6] arm64: dts: aspeed: Add initial AST2700 SoC device tree

[Geert Uytterhoeven]

Hi Ryan,

On Wed, 29 Oct 2025 at 03:38, Ryan Chen <ryan_chen@aspeedtech.com> wrote:
> > Subject: Re: [PATCH v6 4/6] arm64: dts: aspeed: Add initial AST2700 SoC device
> > On Mon, 27 Oct 2025 at 13:01, Andrew Lunn <andrew@lunn.ch> wrote:
> > > On Mon, Oct 27, 2025 at 02:42:01AM +0000, Ryan Chen wrote:
> > > > > Subject: Re: [PATCH v6 4/6] arm64: dts: aspeed: Add initial
> > > > > AST2700 SoC device tree
> > > > >
> > > > > > SoC0, referred to as the CPU die, contains a dual-core
> > > > > > Cortex-A35 cluster and two Cortex-M4 cores, along with its own
> > > > > > clock/reset domains and high-speed peripheral set.
> > > > >
> > > > > > SoC1, referred to as the I/O die, contains the Boot MCU and its
> > > > > > own clock/reset domains and low-speed peripheral set, and is
> > > > > > responsible for system boot and control functions.
> > > > >
> > > > > So is the same .dtsi file shared by both systems?
> > > >
> > > > This .dtsi represents the Cortex-A35 view only and is not shared
> > > > with the Cortex-M4 or the Boot MCU side, since they are separate
> > > > 32-bit and 64-bit systems running independent firmware.
> > >
> > > DT describes the hardware. The .dtsi file could be shared, you just
> > > need different status = <>; lines in the dtb blob.
> > >
> > > > > How do you partition devices
> > > > > so each CPU cluster knows it has exclusive access to which peripherals?
> > > >
> > > > Before the system is fully brought up, Boot MCU configure hardware
> > > > controllers handle the resource partitioning to ensure exclusive access.
> > >
> > > Are you saying it modifies the .dtb blob and changes some status =
> > > "okay"; to "disabled";?
> >
> > "reserved" is the appropriate status value for that.
>
> Thanks for the clarification.
>
> Since the SoC-level .dtsi is shared by all users (potentially other platforms),
> I don’t actually know in advance which peripherals will be assigned to
> which CPU. For this reason, marking nodes as `status = "reserved"` in the
> .dtsi might be misleading.

Sure, not in the SoC-specific .dtsi.

> I think it’s more appropriate to keep all peripherals as
> `status = "disabled"` in the common .dtsi, and let each board-level .dts or
> firmware-specific DT decide whether a device should be `okay` or `reserved`
> depending on the actual resource assignment.

Correct.

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

RE: [PATCH v6 4/6] arm64: dts: aspeed: Add initial AST2700 SoC device tree

[Ryan Chen]

> Subject: Re: [PATCH v6 4/6] arm64: dts: aspeed: Add initial AST2700 SoC device
> tree
> 
> Hi Arnd,
> 
> On Wed, 29 Oct 2025 at 08:26, Arnd Bergmann <arnd@arndb.de> wrote:
> > On Wed, Oct 29, 2025, at 03:31, Ryan Chen wrote:
> > >> Subject: Re: [PATCH v6 4/6] arm64: dts: aspeed: Add initial AST2700
> > >> SoC device tree
> > >>
> > >> On Mon, Oct 27, 2025 at 02:42:01AM +0000, Ryan Chen wrote:
> > >> > > Subject: Re: [PATCH v6 4/6] arm64: dts: aspeed: Add initial
> > >> > > AST2700 SoC device tree
> > >> > >
> > >> > > > SoC0, referred to as the CPU die, contains a dual-core
> > >> > > > Cortex-A35 cluster and two Cortex-M4 cores, along with its
> > >> > > > own clock/reset domains and high-speed peripheral set.
> > >> > >
> > >> > > > SoC1, referred to as the I/O die, contains the Boot MCU and
> > >> > > > its own clock/reset domains and low-speed peripheral set, and
> > >> > > > is responsible for system boot and control functions.
> > >> > >
> > >> > > So is the same .dtsi file shared by both systems?
> > >> >
> > >> > This .dtsi represents the Cortex-A35 view only and is not shared
> > >> > with the Cortex-M4 or the Boot MCU side, since they are separate
> > >> > 32-bit and 64-bit systems running independent firmware.
> > >>
> > >> DT describes the hardware. The .dtsi file could be shared, you just
> > >> need different status = <>; lines in the dtb blob.
> > >
> > > Could you please share an example of a .dtsi that is shared between
> > > different CPU architectures?
> >
> > I can think of three that are shared between arm and riscv, with both
> > able to boot Linux using a variation of the same device tree, with the
> > .dtsi file being included from the respective other side:
> >
> > arch/riscv/boot/dts/renesas/r9a07g043f.dtsi
> > arch/arm/boot/dts/allwinner/sun8i-t113s.dtsi
> > arch/arm64/boot/dts/sophgo/sg2000.dtsi
> >
> > All of these however use the same basic physical address layout as
> > seen from the two CPUs, with only the set of on-chip devices being
> > slightly different, such as using the native irqchip instance per CPU.
> 
> I can't speak for the last two ones, but the first one is not what Ryan is looking
> for, as r9a07g043 has either an ARM (r9a07g043u) or a RISC-V (r9a07g043f)
> CPU core, not both.
> 
> > In the AST2700 design, even though we have both Cortex-A35 (64-bit)
> > > and Cortex-M4 (32-bit) cores, each runs in a distinct address space
> > > and sees a different memory map.
> >
> > This is similar to the Cortex-M4 on i.MX7D. This is supported by the
> > Linux code, but I don't see the corresponding dts file for it now, it
> > may have never been merged.
> 
> The keyword here is "System DT", where you have a single file describing the
> whole SoC. From this, separate DTS files are generated that describe the view
> for the application CPU core, real-time CPU core, control CPU core, etc...
> 
> Gr{oetje,eeting}s,
> 
>                         Geert

Thanks for pointing me in the right direction.

After checking the TI K3 example
(https://github.com/torvalds/linux/blob/master/arch/arm64/boot/dts/ti/k3-j784s4-j742s2-common.dtsi#L75),
I see that all processing domains in that SoC share the same physical
address decoding, which makes a System-DT-style structure possible.

However, in the AST2700 design, the Cortex-A35 (64-bit) and Cortex-M4
(32-bit) cores each run in a distinct address space with different memory
maps, so they do not share the same decode view.  
Because of that, a single unified .dtsi cannot directly represent both sides
without additional translation or “ranges” mapping logic.
For example, in ca35 view uart0@14c33000, cm4 view uart0@74c33000
From ca35 do have 0x7xxxxxxx is another peripheral decode address.

> 
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 --
> geert@linux-m68k.org
> 
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like that.
>                                 -- Linus Torvalds

Re: [PATCH v6 4/6] arm64: dts: aspeed: Add initial AST2700 SoC device tree

[Arnd Bergmann]

On Thu, Oct 30, 2025, at 03:30, Ryan Chen wrote:
>> Subject: Re: [PATCH v6 4/6] arm64: dts: aspeed: Add initial AST2700 SoC device
>> tree
>> On Wed, 29 Oct 2025 at 08:26, Arnd Bergmann <arnd@arndb.de> wrote:
>> > On Wed, Oct 29, 2025, at 03:31, Ryan Chen wrote:
>> > >> Subject: Re: [PATCH v6 4/6] arm64: dts: aspeed: Add initial AST2700
>
> Thanks for pointing me in the right direction.
>
> After checking the TI K3 example
> (https://github.com/torvalds/linux/blob/master/arch/arm64/boot/dts/ti/k3-j784s4-j742s2-common.dtsi#L75),
> I see that all processing domains in that SoC share the same physical
> address decoding, which makes a System-DT-style structure possible.
>
> However, in the AST2700 design, the Cortex-A35 (64-bit) and Cortex-M4
> (32-bit) cores each run in a distinct address space with different memory
> maps, so they do not share the same decode view.  
> Because of that, a single unified .dtsi cannot directly represent both sides
> without additional translation or “ranges” mapping logic.
> For example, in ca35 view uart0@14c33000, cm4 view uart0@74c33000
> From ca35 do have 0x7xxxxxxx is another peripheral decode address.

This still looks like the simplest case to me, where you'd have
a dtsi file describing the @soc0 and @soc1 devices using their
local addresses such as uart0@c33000, and a ranges property
to map it into the CPU specific physical address space, one of

	ranges = <0x0 0x0 0x0 0x14000000 0x0 0x1000000>;
	ranges = <0x0 0x0 0x0 0x74000000 0x0 0x1000000>;

to remap 0x1000000 bytes (16MB) of address space from local
bus addresses to one of the two clusters. This is almost
what you have, except you map an entire 256MB (0x10000000)
range. The exact size you want should be available in your
hardware documentation.

         Arnd

RE: [PATCH v6 4/6] arm64: dts: aspeed: Add initial AST2700 SoC device tree

[Ryan Chen]

> Subject: Re: [PATCH v6 4/6] arm64: dts: aspeed: Add initial AST2700 SoC device
> tree
> 
> On Thu, Oct 30, 2025, at 03:30, Ryan Chen wrote:
> >> Subject: Re: [PATCH v6 4/6] arm64: dts: aspeed: Add initial AST2700
> >> SoC device tree On Wed, 29 Oct 2025 at 08:26, Arnd Bergmann
> >> <arnd@arndb.de> wrote:
> >> > On Wed, Oct 29, 2025, at 03:31, Ryan Chen wrote:
> >> > >> Subject: Re: [PATCH v6 4/6] arm64: dts: aspeed: Add initial
> >> > >> AST2700
> >
> > Thanks for pointing me in the right direction.
> >
> > After checking the TI K3 example
> > (https://github.com/torvalds/linux/blob/master/arch/arm64/boot/dts/ti/
> > k3-j784s4-j742s2-common.dtsi#L75),
> > I see that all processing domains in that SoC share the same physical
> > address decoding, which makes a System-DT-style structure possible.
> >
> > However, in the AST2700 design, the Cortex-A35 (64-bit) and Cortex-M4
> > (32-bit) cores each run in a distinct address space with different
> > memory maps, so they do not share the same decode view.
> > Because of that, a single unified .dtsi cannot directly represent both
> > sides without additional translation or “ranges” mapping logic.
> > For example, in ca35 view uart0@14c33000, cm4 view uart0@74c33000
> From
> > ca35 do have 0x7xxxxxxx is another peripheral decode address.
> 
> This still looks like the simplest case to me, where you'd have a dtsi file
> describing the @soc0 and @soc1 devices using their local addresses such as
> uart0@c33000, and a ranges property to map it into the CPU specific physical
> address space, one of
> 
> 	ranges = <0x0 0x0 0x0 0x14000000 0x0 0x1000000>;
> 	ranges = <0x0 0x0 0x0 0x74000000 0x0 0x1000000>;
> 
> to remap 0x1000000 bytes (16MB) of address space from local bus addresses
> to one of the two clusters. This is almost what you have, except you map an
> entire 256MB (0x10000000) range. The exact size you want should be available
> in your hardware documentation.

Thanks the direction.
I will separate the aspeed-g7.dtsi file to be aspeed-g7-a35.dtsi and aspeed-g7-common.dts.
aspeed-g7-a35.dtsi will descript soc0/1 ranges
    soc0: bus@10000000 {
        compatible = "simple-bus";
        #address-cells = <2>;
        #size-cells = <2>;

        ranges = <0x0 0x0 0x0 0x0 0x0 0x10000000>;
    };

    soc1: bus@14000000 {
        compatible = "simple-bus";
        #address-cells = <2>;
        #size-cells = <2>;

        ranges = <0x0 0x0 0x0 0x14000000 0x0 0x10000000>; 
    };
aspeed-g7-common.dts will descript soc0/1 peripheral offset. 

> 
>          Arnd