[PATCH 0/4] Add support for EcoNet EN7523 SoC

[PATCH 0/4] Add support for EcoNet EN7523 SoC

[Bert Vermeulen]

This patchset adds support for the EcoNet EN7523 SoC, intended primarily
for xPON/xDSL routers.

John Crispin (4):
  dt-bindings: Add vendor prefix for EcoNet
  dt-bindings: arm: econet: Add binding for EN7523 SoC and EVB
  ARM: dts: Add basic support for EcoNet EN7523
  ARM: Add basic support for EcoNet EN7523 SoC

 .../devicetree/bindings/arm/econet.yaml       |  27 ++++
 .../devicetree/bindings/vendor-prefixes.yaml  |   2 +
 arch/arm/Kconfig                              |  14 ++
 arch/arm/Makefile                             |   1 +
 arch/arm/boot/dts/Makefile                    |   2 +
 arch/arm/boot/dts/en7523-evb.dts              |  17 +++
 arch/arm/boot/dts/en7523.dtsi                 | 128 ++++++++++++++++++
 7 files changed, 191 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/arm/econet.yaml
 create mode 100644 arch/arm/boot/dts/en7523-evb.dts
 create mode 100644 arch/arm/boot/dts/en7523.dtsi

-- 
2.25.1

[PATCH 0/4] Add support for EcoNet EN7523 SoC

[Bert Vermeulen]

This patchset adds support for the EcoNet EN7523 SoC, intended primarily
for xPON/xDSL routers.

John Crispin (4):
  dt-bindings: Add vendor prefix for EcoNet
  dt-bindings: arm: econet: Add binding for EN7523 SoC and EVB
  ARM: dts: Add basic support for EcoNet EN7523
  ARM: Add basic support for EcoNet EN7523 SoC

 .../devicetree/bindings/arm/econet.yaml       |  27 ++++
 .../devicetree/bindings/vendor-prefixes.yaml  |   2 +
 arch/arm/Kconfig                              |  14 ++
 arch/arm/Makefile                             |   1 +
 arch/arm/boot/dts/Makefile                    |   2 +
 arch/arm/boot/dts/en7523-evb.dts              |  17 +++
 arch/arm/boot/dts/en7523.dtsi                 | 128 ++++++++++++++++++
 7 files changed, 191 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/arm/econet.yaml
 create mode 100644 arch/arm/boot/dts/en7523-evb.dts
 create mode 100644 arch/arm/boot/dts/en7523.dtsi

-- 
2.25.1


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH 1/5] dt-bindings: Add vendor prefix for EcoNet

[Bert Vermeulen]

From: John Crispin <john@phrozen.org>

Add vendor prefix "econet" for EcoNet.

Signed-off-by: John Crispin <john@phrozen.org>
Signed-off-by: Bert Vermeulen <bert@biot.com>
---
 Documentation/devicetree/bindings/vendor-prefixes.yaml | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/Documentation/devicetree/bindings/vendor-prefixes.yaml b/Documentation/devicetree/bindings/vendor-prefixes.yaml
index 07fb0d25fc15..9a47725f3948 100644
--- a/Documentation/devicetree/bindings/vendor-prefixes.yaml
+++ b/Documentation/devicetree/bindings/vendor-prefixes.yaml
@@ -333,6 +333,8 @@ patternProperties:
     description: EBV Elektronik
   "^eckelmann,.*":
     description: Eckelmann AG
+  "^econet,.*":
+    description: EcoNet
   "^edt,.*":
     description: Emerging Display Technologies
   "^eeti,.*":
-- 
2.25.1

[PATCH 1/5] dt-bindings: Add vendor prefix for EcoNet

[Bert Vermeulen]

From: John Crispin <john@phrozen.org>

Add vendor prefix "econet" for EcoNet.

Signed-off-by: John Crispin <john@phrozen.org>
Signed-off-by: Bert Vermeulen <bert@biot.com>
---
 Documentation/devicetree/bindings/vendor-prefixes.yaml | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/Documentation/devicetree/bindings/vendor-prefixes.yaml b/Documentation/devicetree/bindings/vendor-prefixes.yaml
index 07fb0d25fc15..9a47725f3948 100644
--- a/Documentation/devicetree/bindings/vendor-prefixes.yaml
+++ b/Documentation/devicetree/bindings/vendor-prefixes.yaml
@@ -333,6 +333,8 @@ patternProperties:
     description: EBV Elektronik
   "^eckelmann,.*":
     description: Eckelmann AG
+  "^econet,.*":
+    description: EcoNet
   "^edt,.*":
     description: Emerging Display Technologies
   "^eeti,.*":
-- 
2.25.1


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH 1/5] dt-bindings: Add vendor prefix for EcoNet

[Rob Herring]

On Fri, 30 Jul 2021 15:45:48 +0200, Bert Vermeulen wrote:
> From: John Crispin <john@phrozen.org>
> 
> Add vendor prefix "econet" for EcoNet.
> 
> Signed-off-by: John Crispin <john@phrozen.org>
> Signed-off-by: Bert Vermeulen <bert@biot.com>
> ---
>  Documentation/devicetree/bindings/vendor-prefixes.yaml | 2 ++
>  1 file changed, 2 insertions(+)
> 

Acked-by: Rob Herring <robh@kernel.org>

Re: [PATCH 1/5] dt-bindings: Add vendor prefix for EcoNet

[Rob Herring]

On Fri, 30 Jul 2021 15:45:48 +0200, Bert Vermeulen wrote:
> From: John Crispin <john@phrozen.org>
> 
> Add vendor prefix "econet" for EcoNet.
> 
> Signed-off-by: John Crispin <john@phrozen.org>
> Signed-off-by: Bert Vermeulen <bert@biot.com>
> ---
>  Documentation/devicetree/bindings/vendor-prefixes.yaml | 2 ++
>  1 file changed, 2 insertions(+)
> 

Acked-by: Rob Herring <robh@kernel.org>

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH 2/5] dt-bindings: arm: econet: Add binding for EN7523 SoC and EVB

[Bert Vermeulen]

From: John Crispin <john@phrozen.org>

Add devicetree binding for Econet EN7523 SoC and evaluation board.

Signed-off-by: John Crispin <john@phrozen.org>
Signed-off-by: Bert Vermeulen <bert@biot.com>
---
 .../devicetree/bindings/arm/econet.yaml       | 27 +++++++++++++++++++
 1 file changed, 27 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/arm/econet.yaml

diff --git a/Documentation/devicetree/bindings/arm/econet.yaml b/Documentation/devicetree/bindings/arm/econet.yaml
new file mode 100644
index 000000000000..39128f959fef
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/econet.yaml
@@ -0,0 +1,27 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/arm/econet.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: EcoNet SoC based Platforms Device Tree Bindings
+
+maintainers:
+  - Felix Fietkau <nbd@nbd.name>
+  - John Crispin <john@phrozen.org>
+description: |
+  Boards with an EcoNet SoC shall have the following properties.
+
+properties:
+  $nodename:
+    const: '/'
+  compatible:
+    oneOf:
+      - items:
+          - enum:
+              - econet,en7523-evb
+          - const: econet,en7523
+
+additionalProperties: true
+
+...
-- 
2.25.1

[PATCH 2/5] dt-bindings: arm: econet: Add binding for EN7523 SoC and EVB

[Bert Vermeulen]

From: John Crispin <john@phrozen.org>

Add devicetree binding for Econet EN7523 SoC and evaluation board.

Signed-off-by: John Crispin <john@phrozen.org>
Signed-off-by: Bert Vermeulen <bert@biot.com>
---
 .../devicetree/bindings/arm/econet.yaml       | 27 +++++++++++++++++++
 1 file changed, 27 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/arm/econet.yaml

diff --git a/Documentation/devicetree/bindings/arm/econet.yaml b/Documentation/devicetree/bindings/arm/econet.yaml
new file mode 100644
index 000000000000..39128f959fef
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/econet.yaml
@@ -0,0 +1,27 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/arm/econet.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: EcoNet SoC based Platforms Device Tree Bindings
+
+maintainers:
+  - Felix Fietkau <nbd@nbd.name>
+  - John Crispin <john@phrozen.org>
+description: |
+  Boards with an EcoNet SoC shall have the following properties.
+
+properties:
+  $nodename:
+    const: '/'
+  compatible:
+    oneOf:
+      - items:
+          - enum:
+              - econet,en7523-evb
+          - const: econet,en7523
+
+additionalProperties: true
+
+...
-- 
2.25.1


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH 2/5] dt-bindings: arm: econet: Add binding for EN7523 SoC and EVB

[Rob Herring]

On Fri, Jul 30, 2021 at 03:45:49PM +0200, Bert Vermeulen wrote:
> From: John Crispin <john@phrozen.org>
> 
> Add devicetree binding for Econet EN7523 SoC and evaluation board.
> 
> Signed-off-by: John Crispin <john@phrozen.org>
> Signed-off-by: Bert Vermeulen <bert@biot.com>
> ---
>  .../devicetree/bindings/arm/econet.yaml       | 27 +++++++++++++++++++
>  1 file changed, 27 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/arm/econet.yaml
> 
> diff --git a/Documentation/devicetree/bindings/arm/econet.yaml b/Documentation/devicetree/bindings/arm/econet.yaml
> new file mode 100644
> index 000000000000..39128f959fef
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/arm/econet.yaml
> @@ -0,0 +1,27 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/arm/econet.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: EcoNet SoC based Platforms Device Tree Bindings
> +
> +maintainers:
> +  - Felix Fietkau <nbd@nbd.name>
> +  - John Crispin <john@phrozen.org>

Blank line

> +description: |

Don't need '|' if no formatting to maintain.

> +  Boards with an EcoNet SoC shall have the following properties.
> +
> +properties:
> +  $nodename:
> +    const: '/'
> +  compatible:
> +    oneOf:

Expecting other SoCs soonish? If not, drop 'oneOf'.

> +      - items:
> +          - enum:
> +              - econet,en7523-evb
> +          - const: econet,en7523
> +
> +additionalProperties: true
> +
> +...
> -- 
> 2.25.1
> 
> 

Re: [PATCH 2/5] dt-bindings: arm: econet: Add binding for EN7523 SoC and EVB

[Rob Herring]

On Fri, Jul 30, 2021 at 03:45:49PM +0200, Bert Vermeulen wrote:
> From: John Crispin <john@phrozen.org>
> 
> Add devicetree binding for Econet EN7523 SoC and evaluation board.
> 
> Signed-off-by: John Crispin <john@phrozen.org>
> Signed-off-by: Bert Vermeulen <bert@biot.com>
> ---
>  .../devicetree/bindings/arm/econet.yaml       | 27 +++++++++++++++++++
>  1 file changed, 27 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/arm/econet.yaml
> 
> diff --git a/Documentation/devicetree/bindings/arm/econet.yaml b/Documentation/devicetree/bindings/arm/econet.yaml
> new file mode 100644
> index 000000000000..39128f959fef
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/arm/econet.yaml
> @@ -0,0 +1,27 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/arm/econet.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: EcoNet SoC based Platforms Device Tree Bindings
> +
> +maintainers:
> +  - Felix Fietkau <nbd@nbd.name>
> +  - John Crispin <john@phrozen.org>

Blank line

> +description: |

Don't need '|' if no formatting to maintain.

> +  Boards with an EcoNet SoC shall have the following properties.
> +
> +properties:
> +  $nodename:
> +    const: '/'
> +  compatible:
> +    oneOf:

Expecting other SoCs soonish? If not, drop 'oneOf'.

> +      - items:
> +          - enum:
> +              - econet,en7523-evb
> +          - const: econet,en7523
> +
> +additionalProperties: true
> +
> +...
> -- 
> 2.25.1
> 
> 

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH 3/5] ARM: dts: Add basic support for EcoNet EN7523

[Bert Vermeulen]

From: John Crispin <john@phrozen.org>

Add basic support for EcoNet EN7523, enough for booting to console.

The UART is basically 8250-compatible, except for the clock selection.
A clock-frequency value is synthesized to get this to run at 115200 bps.

Signed-off-by: John Crispin <john@phrozen.org>
Signed-off-by: Bert Vermeulen <bert@biot.com>
---
 arch/arm/boot/dts/Makefile       |   2 +
 arch/arm/boot/dts/en7523-evb.dts |  17 ++++
 arch/arm/boot/dts/en7523.dtsi    | 128 +++++++++++++++++++++++++++++++
 3 files changed, 147 insertions(+)
 create mode 100644 arch/arm/boot/dts/en7523-evb.dts
 create mode 100644 arch/arm/boot/dts/en7523.dtsi

diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 863347b6b65e..3eeb7715c6ce 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -174,6 +174,8 @@ dtb-$(CONFIG_ARCH_DAVINCI) += \
 	da850-lego-ev3.dtb
 dtb-$(CONFIG_ARCH_DIGICOLOR) += \
 	cx92755_equinox.dtb
+dtb-$(CONFIG_ARCH_ECONET) += \
+	en7523-evb.dtb
 dtb-$(CONFIG_ARCH_EXYNOS3) += \
 	exynos3250-artik5-eval.dtb \
 	exynos3250-monk.dtb \
diff --git a/arch/arm/boot/dts/en7523-evb.dts b/arch/arm/boot/dts/en7523-evb.dts
new file mode 100644
index 000000000000..c5b75eb3715e
--- /dev/null
+++ b/arch/arm/boot/dts/en7523-evb.dts
@@ -0,0 +1,17 @@
+// SPDX-License-Identifier: GPL-2.0
+/dts-v1/;
+#include "en7523.dtsi"
+
+/ {
+	model = "Econet EN7523 Evaluation Board";
+	compatible = "econet,en7523-evb", "econet,en7523";
+
+	aliases {
+		serial0 = &uart1;
+	};
+
+	chosen {
+		bootargs = "earlycon=uart8250,mmio32,0x1fbf0000 console=ttyS0,115200";
+		stdout-path = "serial0:115200n8";
+	};
+};
diff --git a/arch/arm/boot/dts/en7523.dtsi b/arch/arm/boot/dts/en7523.dtsi
new file mode 100644
index 000000000000..f4fe1c6f66e8
--- /dev/null
+++ b/arch/arm/boot/dts/en7523.dtsi
@@ -0,0 +1,128 @@
+// SPDX-License-Identifier: GPL-2.0
+
+#include <dt-bindings/interrupt-controller/irq.h>
+#include <dt-bindings/interrupt-controller/arm-gic.h>
+
+/ {
+	interrupt-parent = <&gic>;
+	#address-cells = <1>;
+	#size-cells = <1>;
+
+	reserved-memory {
+		#address-cells = <1>;
+		#size-cells = <1>;
+		ranges;
+
+		npu_binary@84000000 {
+			no-map;
+			reg = <0x84000000 0xA00000>;
+		};
+
+		npu_flag@84B0000 {
+			no-map;
+			reg = <0x84B00000 0x100000>;
+		};
+
+		npu_pkt@85000000 {
+			no-map;
+			reg = <0x85000000 0x1A00000>;
+		};
+
+		npu_phyaddr@86B00000 {
+			no-map;
+			reg = <0x86B00000 0x100000>;
+		};
+
+		npu_rxdesc@86D00000 {
+			no-map;
+			reg = <0x86D00000 0x100000>;
+		};
+	};
+
+	psci {
+		compatible = "arm,psci-0.2";
+		method = "smc";
+	};
+
+	cpus {
+		#address-cells = <1>;
+		#size-cells = <0>;
+
+		cpu-map {
+			cluster0 {
+				core0 {
+					cpu = <&cpu0>;
+				};
+				core1 {
+					cpu = <&cpu1>;
+				};
+			};
+		};
+
+		cpu0: cpu@0 {
+			device_type = "cpu";
+			compatible = "arm,cortex-a7";
+			reg = <0x0>;
+			enable-method = "psci";
+			clock-frequency = <80000000>;
+			next-level-cache = <&L2_0>;
+
+		};
+
+		cpu1: cpu@1 {
+			device_type = "cpu";
+			compatible = "arm,cortex-a7";
+			reg = <0x1>;
+			enable-method = "psci";
+			clock-frequency = <80000000>;
+			next-level-cache = <&L2_0>;
+		};
+
+		L2_0: l2-cache0 {
+			compatible = "cache";
+		};
+	};
+
+	gic: interrupt-controller@09000000 {
+		compatible = "arm,gic-v3";
+		interrupt-controller;
+		#interrupt-cells = <3>;
+		#address-cells = <1>;
+		#size-cells = <1>;
+		reg = <0x09000000 0x20000>,
+			  <0x09080000 0x80000>;
+		interrupts = <GIC_PPI 9 IRQ_TYPE_LEVEL_LOW>;
+
+		its: gic-its@09020000 {
+			compatible = "arm,gic-v3-its";
+			msi-controller;
+			#msi-cell = <1>;
+			reg = <0x090200000 0x20000>;
+		};
+	};
+
+	timer {
+		compatible = "arm,armv8-timer";
+		interrupt-parent = <&gic>;
+		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)>;
+		clock-frequency = <25000000>;
+	};
+
+	memory@80000000 {
+		device_type = "memory";
+		reg = <0x80000000 0x40000000>;
+	};
+
+	uart1: serial@1fbf0000 {
+		compatible = "ns8250";
+		reg = <0x1fbf0000 0x30>;
+		reg-io-width = <4>;
+		reg-shift = <2>;
+		interrupts = <GIC_SPI 18 IRQ_TYPE_LEVEL_HIGH>;
+		clock-frequency = <1843200>;
+		status = "okay";
+	};
+};
-- 
2.25.1

[PATCH 3/5] ARM: dts: Add basic support for EcoNet EN7523

[Bert Vermeulen]

From: John Crispin <john@phrozen.org>

Add basic support for EcoNet EN7523, enough for booting to console.

The UART is basically 8250-compatible, except for the clock selection.
A clock-frequency value is synthesized to get this to run at 115200 bps.

Signed-off-by: John Crispin <john@phrozen.org>
Signed-off-by: Bert Vermeulen <bert@biot.com>
---
 arch/arm/boot/dts/Makefile       |   2 +
 arch/arm/boot/dts/en7523-evb.dts |  17 ++++
 arch/arm/boot/dts/en7523.dtsi    | 128 +++++++++++++++++++++++++++++++
 3 files changed, 147 insertions(+)
 create mode 100644 arch/arm/boot/dts/en7523-evb.dts
 create mode 100644 arch/arm/boot/dts/en7523.dtsi

diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 863347b6b65e..3eeb7715c6ce 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -174,6 +174,8 @@ dtb-$(CONFIG_ARCH_DAVINCI) += \
 	da850-lego-ev3.dtb
 dtb-$(CONFIG_ARCH_DIGICOLOR) += \
 	cx92755_equinox.dtb
+dtb-$(CONFIG_ARCH_ECONET) += \
+	en7523-evb.dtb
 dtb-$(CONFIG_ARCH_EXYNOS3) += \
 	exynos3250-artik5-eval.dtb \
 	exynos3250-monk.dtb \
diff --git a/arch/arm/boot/dts/en7523-evb.dts b/arch/arm/boot/dts/en7523-evb.dts
new file mode 100644
index 000000000000..c5b75eb3715e
--- /dev/null
+++ b/arch/arm/boot/dts/en7523-evb.dts
@@ -0,0 +1,17 @@
+// SPDX-License-Identifier: GPL-2.0
+/dts-v1/;
+#include "en7523.dtsi"
+
+/ {
+	model = "Econet EN7523 Evaluation Board";
+	compatible = "econet,en7523-evb", "econet,en7523";
+
+	aliases {
+		serial0 = &uart1;
+	};
+
+	chosen {
+		bootargs = "earlycon=uart8250,mmio32,0x1fbf0000 console=ttyS0,115200";
+		stdout-path = "serial0:115200n8";
+	};
+};
diff --git a/arch/arm/boot/dts/en7523.dtsi b/arch/arm/boot/dts/en7523.dtsi
new file mode 100644
index 000000000000..f4fe1c6f66e8
--- /dev/null
+++ b/arch/arm/boot/dts/en7523.dtsi
@@ -0,0 +1,128 @@
+// SPDX-License-Identifier: GPL-2.0
+
+#include <dt-bindings/interrupt-controller/irq.h>
+#include <dt-bindings/interrupt-controller/arm-gic.h>
+
+/ {
+	interrupt-parent = <&gic>;
+	#address-cells = <1>;
+	#size-cells = <1>;
+
+	reserved-memory {
+		#address-cells = <1>;
+		#size-cells = <1>;
+		ranges;
+
+		npu_binary@84000000 {
+			no-map;
+			reg = <0x84000000 0xA00000>;
+		};
+
+		npu_flag@84B0000 {
+			no-map;
+			reg = <0x84B00000 0x100000>;
+		};
+
+		npu_pkt@85000000 {
+			no-map;
+			reg = <0x85000000 0x1A00000>;
+		};
+
+		npu_phyaddr@86B00000 {
+			no-map;
+			reg = <0x86B00000 0x100000>;
+		};
+
+		npu_rxdesc@86D00000 {
+			no-map;
+			reg = <0x86D00000 0x100000>;
+		};
+	};
+
+	psci {
+		compatible = "arm,psci-0.2";
+		method = "smc";
+	};
+
+	cpus {
+		#address-cells = <1>;
+		#size-cells = <0>;
+
+		cpu-map {
+			cluster0 {
+				core0 {
+					cpu = <&cpu0>;
+				};
+				core1 {
+					cpu = <&cpu1>;
+				};
+			};
+		};
+
+		cpu0: cpu@0 {
+			device_type = "cpu";
+			compatible = "arm,cortex-a7";
+			reg = <0x0>;
+			enable-method = "psci";
+			clock-frequency = <80000000>;
+			next-level-cache = <&L2_0>;
+
+		};
+
+		cpu1: cpu@1 {
+			device_type = "cpu";
+			compatible = "arm,cortex-a7";
+			reg = <0x1>;
+			enable-method = "psci";
+			clock-frequency = <80000000>;
+			next-level-cache = <&L2_0>;
+		};
+
+		L2_0: l2-cache0 {
+			compatible = "cache";
+		};
+	};
+
+	gic: interrupt-controller@09000000 {
+		compatible = "arm,gic-v3";
+		interrupt-controller;
+		#interrupt-cells = <3>;
+		#address-cells = <1>;
+		#size-cells = <1>;
+		reg = <0x09000000 0x20000>,
+			  <0x09080000 0x80000>;
+		interrupts = <GIC_PPI 9 IRQ_TYPE_LEVEL_LOW>;
+
+		its: gic-its@09020000 {
+			compatible = "arm,gic-v3-its";
+			msi-controller;
+			#msi-cell = <1>;
+			reg = <0x090200000 0x20000>;
+		};
+	};
+
+	timer {
+		compatible = "arm,armv8-timer";
+		interrupt-parent = <&gic>;
+		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)>;
+		clock-frequency = <25000000>;
+	};
+
+	memory@80000000 {
+		device_type = "memory";
+		reg = <0x80000000 0x40000000>;
+	};
+
+	uart1: serial@1fbf0000 {
+		compatible = "ns8250";
+		reg = <0x1fbf0000 0x30>;
+		reg-io-width = <4>;
+		reg-shift = <2>;
+		interrupts = <GIC_SPI 18 IRQ_TYPE_LEVEL_HIGH>;
+		clock-frequency = <1843200>;
+		status = "okay";
+	};
+};
-- 
2.25.1


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH 3/5] ARM: dts: Add basic support for EcoNet EN7523

[Linus Walleij]

Paging Marc Z and Catalin just so they can see this:

On Fri, Jul 30, 2021 at 3:49 PM Bert Vermeulen <bert@biot.com> wrote:

> From: John Crispin <john@phrozen.org>
>
> Add basic support for EcoNet EN7523, enough for booting to console.
>
> The UART is basically 8250-compatible, except for the clock selection.
> A clock-frequency value is synthesized to get this to run at 115200 bps.
>
> Signed-off-by: John Crispin <john@phrozen.org>
> Signed-off-by: Bert Vermeulen <bert@biot.com>
(...)
> +       gic: interrupt-controller@09000000 {
> +               compatible = "arm,gic-v3";
> +               interrupt-controller;
> +               #interrupt-cells = <3>;
> +               #address-cells = <1>;
> +               #size-cells = <1>;
> +               reg = <0x09000000 0x20000>,
> +                         <0x09080000 0x80000>;
> +               interrupts = <GIC_PPI 9 IRQ_TYPE_LEVEL_LOW>;
> +
> +               its: gic-its@09020000 {
> +                       compatible = "arm,gic-v3-its";
> +                       msi-controller;
> +                       #msi-cell = <1>;
> +                       reg = <0x090200000 0x20000>;
> +               };
> +       };

Yup GICv3 on ARM32-only silicon.

> +       timer {
> +               compatible = "arm,armv8-timer";
> +               interrupt-parent = <&gic>;
> +               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)>;
> +               clock-frequency = <25000000>;
> +       };

Also arm,armv8-timer on ARM32-only silicon.

This is kind of a first.

Yours,
Linus Walleij

Re: [PATCH 3/5] ARM: dts: Add basic support for EcoNet EN7523

[Linus Walleij]

Paging Marc Z and Catalin just so they can see this:

On Fri, Jul 30, 2021 at 3:49 PM Bert Vermeulen <bert@biot.com> wrote:

> From: John Crispin <john@phrozen.org>
>
> Add basic support for EcoNet EN7523, enough for booting to console.
>
> The UART is basically 8250-compatible, except for the clock selection.
> A clock-frequency value is synthesized to get this to run at 115200 bps.
>
> Signed-off-by: John Crispin <john@phrozen.org>
> Signed-off-by: Bert Vermeulen <bert@biot.com>
(...)
> +       gic: interrupt-controller@09000000 {
> +               compatible = "arm,gic-v3";
> +               interrupt-controller;
> +               #interrupt-cells = <3>;
> +               #address-cells = <1>;
> +               #size-cells = <1>;
> +               reg = <0x09000000 0x20000>,
> +                         <0x09080000 0x80000>;
> +               interrupts = <GIC_PPI 9 IRQ_TYPE_LEVEL_LOW>;
> +
> +               its: gic-its@09020000 {
> +                       compatible = "arm,gic-v3-its";
> +                       msi-controller;
> +                       #msi-cell = <1>;
> +                       reg = <0x090200000 0x20000>;
> +               };
> +       };

Yup GICv3 on ARM32-only silicon.

> +       timer {
> +               compatible = "arm,armv8-timer";
> +               interrupt-parent = <&gic>;
> +               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)>;
> +               clock-frequency = <25000000>;
> +       };

Also arm,armv8-timer on ARM32-only silicon.

This is kind of a first.

Yours,
Linus Walleij

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH 3/5] ARM: dts: Add basic support for EcoNet EN7523

[Linus Walleij]

Paging Marc Z and Catalin just so they can see this:

On Fri, Jul 30, 2021 at 3:49 PM Bert Vermeulen <bert@biot.com> wrote:

> From: John Crispin <john@phrozen.org>
>
> Add basic support for EcoNet EN7523, enough for booting to console.
>
> The UART is basically 8250-compatible, except for the clock selection.
> A clock-frequency value is synthesized to get this to run at 115200 bps.
>
> Signed-off-by: John Crispin <john@phrozen.org>
> Signed-off-by: Bert Vermeulen <bert@biot.com>
(...)
> +       gic: interrupt-controller@09000000 {
> +               compatible = "arm,gic-v3";
> +               interrupt-controller;
> +               #interrupt-cells = <3>;
> +               #address-cells = <1>;
> +               #size-cells = <1>;
> +               reg = <0x09000000 0x20000>,
> +                         <0x09080000 0x80000>;
> +               interrupts = <GIC_PPI 9 IRQ_TYPE_LEVEL_LOW>;
> +
> +               its: gic-its@09020000 {
> +                       compatible = "arm,gic-v3-its";
> +                       msi-controller;
> +                       #msi-cell = <1>;
> +                       reg = <0x090200000 0x20000>;
> +               };
> +       };

Yup GICv3 on ARM32-only silicon.

> +       timer {
> +               compatible = "arm,armv8-timer";
> +               interrupt-parent = <&gic>;
> +               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)>;
> +               clock-frequency = <25000000>;
> +       };

Also arm,armv8-timer on ARM32-only silicon.

This is kind of a first.

Yours,
Linus Walleij

Re: [PATCH 3/5] ARM: dts: Add basic support for EcoNet EN7523

[Marc Zyngier]

On Fri, 30 Jul 2021 15:31:36 +0100,
Linus Walleij <linus.walleij@linaro.org> wrote:
> 
> Paging Marc Z and Catalin just so they can see this:
> 
> On Fri, Jul 30, 2021 at 3:49 PM Bert Vermeulen <bert@biot.com> wrote:
> 
> > From: John Crispin <john@phrozen.org>
> >
> > Add basic support for EcoNet EN7523, enough for booting to console.
> >
> > The UART is basically 8250-compatible, except for the clock selection.
> > A clock-frequency value is synthesized to get this to run at 115200 bps.
> >
> > Signed-off-by: John Crispin <john@phrozen.org>
> > Signed-off-by: Bert Vermeulen <bert@biot.com>
> (...)
> > +       gic: interrupt-controller@09000000 {
> > +               compatible = "arm,gic-v3";
> > +               interrupt-controller;
> > +               #interrupt-cells = <3>;
> > +               #address-cells = <1>;
> > +               #size-cells = <1>;
> > +               reg = <0x09000000 0x20000>,
> > +                         <0x09080000 0x80000>;
> > +               interrupts = <GIC_PPI 9 IRQ_TYPE_LEVEL_LOW>;
> > +
> > +               its: gic-its@09020000 {
> > +                       compatible = "arm,gic-v3-its";
> > +                       msi-controller;
> > +                       #msi-cell = <1>;
> > +                       reg = <0x090200000 0x20000>;
> > +               };
> > +       };
> 
> Yup GICv3 on ARM32-only silicon.

Hey, why not. But that's very unlikely, as Cortex-A7 doesn't have a
GICv3 CPU interface built in (it only has the memory mapped version),
and A53/57 were the first CPUs to ever support GICv3. I don't believe
the description of the CPU in the DT is accurate.

Bert, please send a kernel boot log.

> 
> > +       timer {
> > +               compatible = "arm,armv8-timer";
> > +               interrupt-parent = <&gic>;
> > +               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)>;

Copy paste bug. These are not valid intspecs for GICv3.

> > +               clock-frequency = <25000000>;
> > +       };
> 
> Also arm,armv8-timer on ARM32-only silicon.

Probably because that's not what it actually is. My bet is on A53 with
a crippled firmware.

> This is kind of a first.

Thanks,

	M.

-- 
Without deviation from the norm, progress is not possible.

Re: [PATCH 3/5] ARM: dts: Add basic support for EcoNet EN7523

[Marc Zyngier]

On Fri, 30 Jul 2021 15:31:36 +0100,
Linus Walleij <linus.walleij@linaro.org> wrote:
> 
> Paging Marc Z and Catalin just so they can see this:
> 
> On Fri, Jul 30, 2021 at 3:49 PM Bert Vermeulen <bert@biot.com> wrote:
> 
> > From: John Crispin <john@phrozen.org>
> >
> > Add basic support for EcoNet EN7523, enough for booting to console.
> >
> > The UART is basically 8250-compatible, except for the clock selection.
> > A clock-frequency value is synthesized to get this to run at 115200 bps.
> >
> > Signed-off-by: John Crispin <john@phrozen.org>
> > Signed-off-by: Bert Vermeulen <bert@biot.com>
> (...)
> > +       gic: interrupt-controller@09000000 {
> > +               compatible = "arm,gic-v3";
> > +               interrupt-controller;
> > +               #interrupt-cells = <3>;
> > +               #address-cells = <1>;
> > +               #size-cells = <1>;
> > +               reg = <0x09000000 0x20000>,
> > +                         <0x09080000 0x80000>;
> > +               interrupts = <GIC_PPI 9 IRQ_TYPE_LEVEL_LOW>;
> > +
> > +               its: gic-its@09020000 {
> > +                       compatible = "arm,gic-v3-its";
> > +                       msi-controller;
> > +                       #msi-cell = <1>;
> > +                       reg = <0x090200000 0x20000>;
> > +               };
> > +       };
> 
> Yup GICv3 on ARM32-only silicon.

Hey, why not. But that's very unlikely, as Cortex-A7 doesn't have a
GICv3 CPU interface built in (it only has the memory mapped version),
and A53/57 were the first CPUs to ever support GICv3. I don't believe
the description of the CPU in the DT is accurate.

Bert, please send a kernel boot log.

> 
> > +       timer {
> > +               compatible = "arm,armv8-timer";
> > +               interrupt-parent = <&gic>;
> > +               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)>;

Copy paste bug. These are not valid intspecs for GICv3.

> > +               clock-frequency = <25000000>;
> > +       };
> 
> Also arm,armv8-timer on ARM32-only silicon.

Probably because that's not what it actually is. My bet is on A53 with
a crippled firmware.

> This is kind of a first.

Thanks,

	M.

-- 
Without deviation from the norm, progress is not possible.

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH 3/5] ARM: dts: Add basic support for EcoNet EN7523

[Bert Vermeulen]

On 7/30/21 4:53 PM, Marc Zyngier wrote:
> On Fri, 30 Jul 2021 15:31:36 +0100,
> Linus Walleij <linus.walleij@linaro.org> wrote:
>> 
>> Paging Marc Z and Catalin just so they can see this:
>> 
>> On Fri, Jul 30, 2021 at 3:49 PM Bert Vermeulen <bert@biot.com> wrote:
>> 
>> > From: John Crispin <john@phrozen.org>
>> >
>> > Add basic support for EcoNet EN7523, enough for booting to console.
>> >
>> > The UART is basically 8250-compatible, except for the clock selection.
>> > A clock-frequency value is synthesized to get this to run at 115200 bps.
>> >
>> > Signed-off-by: John Crispin <john@phrozen.org>
>> > Signed-off-by: Bert Vermeulen <bert@biot.com>
>> (...)
>> > +       gic: interrupt-controller@09000000 {
>> > +               compatible = "arm,gic-v3";
>> > +               interrupt-controller;
>> > +               #interrupt-cells = <3>;
>> > +               #address-cells = <1>;
>> > +               #size-cells = <1>;
>> > +               reg = <0x09000000 0x20000>,
>> > +                         <0x09080000 0x80000>;
>> > +               interrupts = <GIC_PPI 9 IRQ_TYPE_LEVEL_LOW>;
>> > +
>> > +               its: gic-its@09020000 {
>> > +                       compatible = "arm,gic-v3-its";
>> > +                       msi-controller;
>> > +                       #msi-cell = <1>;
>> > +                       reg = <0x090200000 0x20000>;
>> > +               };
>> > +       };
>> 
>> Yup GICv3 on ARM32-only silicon.
> 
> Hey, why not. But that's very unlikely, as Cortex-A7 doesn't have a
> GICv3 CPU interface built in (it only has the memory mapped version),
> and A53/57 were the first CPUs to ever support GICv3. I don't believe
> the description of the CPU in the DT is accurate.
> 
> Bert, please send a kernel boot log.

At the bottom of this mail.

>> > +       timer {
>> > +               compatible = "arm,armv8-timer";
>> > +               interrupt-parent = <&gic>;
>> > +               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)>;
> 
> Copy paste bug. These are not valid intspecs for GICv3.

FWIW all these were taken verbatim from the vendor's SDK. Not that this 
makes them necessarily correct :)

>> > +               clock-frequency = <25000000>;
>> > +       };
>> 
>> Also arm,armv8-timer on ARM32-only silicon.
> 
> Probably because that's not what it actually is. My bet is on A53 with
> a crippled firmware.

kernel boot log:

[    0.000000] Booting Linux on physical CPU 0x0
[    0.000000] Linux version 5.14.0-rc3-00042-g3af70c6f8e95-dirty 
(bert@sumner) (arm-linux-gnueabi-gcc (Ubuntu 9.3.0-17ubuntu1~20.04) 9.3.0, 
GNU ld (GNU Binutils for Ubuntu) 2.34) #392 SMP Sun Aug 1 10:28:13 CEST 2021
[    0.000000] CPU: ARMv7 Processor [410fd034] revision 4 (ARMv7), cr=10c5383d
[    0.000000] CPU: div instructions available: patching division code
[    0.000000] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing 
instruction cache
[    0.000000] OF: fdt: Machine model: econet,en7523
[    0.000000] earlycon: uart8250 at MMIO32 0x1fbf0000 (options '')
[    0.000000] printk: bootconsole [uart8250] enabled
[    0.000000] Memory policy: Data cache writealloc
[    0.000000] Zone ranges:
[    0.000000]   Normal   [mem 0x0000000080000000-0x000000009fffffff]
[    0.000000]   HighMem  empty
[    0.000000] Movable zone start for each node
[    0.000000] Early memory node ranges
[    0.000000]   node   0: [mem 0x0000000080000000-0x0000000083ffffff]
[    0.000000]   node   0: [mem 0x0000000084000000-0x00000000849fffff]
[    0.000000]   node   0: [mem 0x0000000084a00000-0x0000000084afffff]
[    0.000000]   node   0: [mem 0x0000000084b00000-0x0000000084bfffff]
[    0.000000]   node   0: [mem 0x0000000084c00000-0x0000000084ffffff]
[    0.000000]   node   0: [mem 0x0000000085000000-0x00000000869fffff]
[    0.000000]   node   0: [mem 0x0000000086a00000-0x0000000086afffff]
[    0.000000]   node   0: [mem 0x0000000086b00000-0x0000000086bfffff]
[    0.000000]   node   0: [mem 0x0000000086c00000-0x0000000086cfffff]
[    0.000000]   node   0: [mem 0x0000000086d00000-0x0000000086dfffff]
[    0.000000]   node   0: [mem 0x0000000086e00000-0x000000009fffffff]
[    0.000000] Initmem setup node 0 [mem 0x0000000080000000-0x000000009fffffff]
[    0.000000] percpu: Embedded 15 pages/cpu s30604 r8192 d22644 u61440
[    0.000000] Built 1 zonelists, mobility grouping on.  Total pages: 129920
[    0.000000] Kernel command line: earlycon=uart8250,mmio32,0x1fbf0000 
console=ttyS0,115200
[    0.000000] Dentry cache hash table entries: 65536 (order: 6, 262144 
bytes, linear)
[    0.000000] Inode-cache hash table entries: 32768 (order: 5, 131072 
bytes, linear)
[    0.000000] mem auto-init: stack:off, heap alloc:off, heap free:off
[    0.000000] Memory: 461316K/524288K available (7168K kernel code, 312K 
rwdata, 1488K rodata, 8192K init, 142K bss, 62972K reserved, 0K 
cma-reserved, 0K highmem)
[    0.000000] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=2, Nodes=1
[    0.000000] rcu: Hierarchical RCU implementation.
[    0.000000] rcu: RCU calculated value of scheduler-enlistment delay is 10 
jiffies.
[    0.000000] NR_IRQS: 16, nr_irqs: 16, preallocated irqs: 16
[    0.000000] GICv3: 256 SPIs implemented
[    0.000000] GICv3: 0 Extended SPIs implemented
[    0.000000] GICv3: Distributor has no Range Selector support
[    0.000000] GICv3: 16 PPIs implemented
[    0.000000] GICv3: CPU0: found redistributor 0 region 0:0x09080000
[    0.000000] random: get_random_bytes called from start_kernel+0x484/0x628 
with crng_init=0
[    0.000000] arch_timer: cp15 timer(s) running at 25.00MHz (virt).
[    0.000000] clocksource: arch_sys_counter: mask: 0xffffffffffffff 
max_cycles: 0x5c40939b5, max_idle_ns: 440795202646 ns
[    0.000000] sched_clock: 56 bits at 25MHz, resolution 40ns, wraps every 
4398046511100ns
[    0.008791] Switching to timer-based delay loop, resolution 40ns
[    0.015454] Calibrating delay loop (skipped), value calculated using 
timer frequency.. 50.00 BogoMIPS (lpj=250000)
[    0.026833] pid_max: default: 32768 minimum: 301
[    0.032013] Mount-cache hash table entries: 1024 (order: 0, 4096 bytes, 
linear)
[    0.040047] Mountpoint-cache hash table entries: 1024 (order: 0, 4096 
bytes, linear)
[    0.049172] CPU: Testing write buffer coherency: ok
[    0.054780] CPU0: thread -1, cpu 0, socket 0, mpidr 80000000
[    0.061362] Setting up static identity map for 0x80100000 - 0x80100060
[    0.068667] rcu: Hierarchical SRCU implementation.
[    0.074290] gic-its@09020000: unable to locate ITS domain
[    0.080461] smp: Bringing up secondary CPUs ...
[    0.085769] smp: Brought up 1 node, 1 CPU
[    0.090179] SMP: Total of 1 processors activated (50.00 BogoMIPS).
[    0.097013] CPU: All CPU(s) started in SVC mode.
[    0.103634] clocksource: jiffies: mask: 0xffffffff max_cycles: 
0xffffffff, max_idle_ns: 19112604462750000 ns
[    0.114499] futex hash table entries: 512 (order: 3, 32768 bytes, linear)
[    0.122380] NET: Registered PF_NETLINK/PF_ROUTE protocol family
[    0.129153] DMA: preallocated 256 KiB pool for atomic coherent allocations
[    0.137265] thermal_sys: Registered thermal governor 'step_wise'
[    0.137333] No ATAGs?
[    0.153205] iommu: Default domain type: Translated
[    0.158713] usbcore: registered new interface driver usbfs
[    0.164769] usbcore: registered new interface driver hub
[    0.170660] usbcore: registered new device driver usb
[    0.176704] NET: Registered PF_ATMPVC protocol family
[    0.182296] NET: Registered PF_ATMSVC protocol family
[    0.188055] clocksource: Switched to clocksource arch_sys_counter
[    0.195462] NET: Registered PF_INET protocol family
[    0.200971] IP idents hash table entries: 8192 (order: 4, 65536 bytes, 
linear)
[    0.209452] tcp_listen_portaddr_hash hash table entries: 512 (order: 0, 
6144 bytes, linear)
[    0.218713] TCP established hash table entries: 4096 (order: 2, 16384 
bytes, linear)
[    0.227251] TCP bind hash table entries: 4096 (order: 3, 32768 bytes, linear)
[    0.235158] TCP: Hash tables configured (established 4096 bind 4096)
[    0.242212] UDP hash table entries: 256 (order: 1, 8192 bytes, linear)
[    0.249416] UDP-Lite hash table entries: 256 (order: 1, 8192 bytes, linear)
[    0.257205] NET: Registered PF_UNIX/PF_LOCAL protocol family
[    0.263464] PCI: CLS 0 bytes, default 64
[    0.348846] workingset: timestamp_bits=14 max_order=17 bucket_order=3
[    0.360684] squashfs: version 4.0 (2009/01/31) Phillip Lougher
[    0.367197] ntfs: driver 2.1.32 [Flags: R/W DEBUG].
[    0.372785] jffs2: version 2.2. (NAND) © 2001-2006 Red Hat, Inc.
[    0.598557] io scheduler mq-deadline registered
[    0.603555] io scheduler kyber registered
[    0.619475] Serial: 8250/16550 driver, 2 ports, IRQ sharing enabled
[    0.626838] printk: console [ttyS0] disabled
[    0.631671] 1fbf0000.serial: ttyS0 at MMIO 0x1fbf0000 (irq = 28, 
base_baud = 115200) is a 8250
[    0.641169] printk: console [ttyS0] enabled
[    0.641169] printk: console [ttyS0] enabled
[    0.649943] printk: bootconsole [uart8250] disabled
[    0.649943] printk: bootconsole [uart8250] disabled
[    0.706413] brd: module loaded
[    0.709758] PPP generic driver version 2.4.2
[    0.714097] PPP BSD Compression module registered
[    0.718832] PPP Deflate Compression module registered
[    0.723877] NET: Registered PF_PPPOX protocol family
[    0.728989] usbcore: registered new interface driver cdc_acm
[    0.734648] cdc_acm: USB Abstract Control Model driver for USB modems and 
ISDN adapters
[    0.742712] usbcore: registered new interface driver usbserial_generic
[    0.749278] usbserial: USB Serial support registered for generic
[    0.755299] usbcore: registered new interface driver cypress_m8
[    0.761234] usbserial: USB Serial support registered for DeLorme 
Earthmate USB
[    0.768476] usbserial: USB Serial support registered for HID->COM RS232 
Adapter
[    0.775790] usbserial: USB Serial support registered for Nokia CA-42 V2 
Adapter
[    0.783121] usbcore: registered new interface driver ftdi_sio
[    0.788889] usbserial: USB Serial support registered for FTDI USB Serial 
Device
[    0.796272] hid: raw HID events driver (C) Jiri Kosina
[    0.801492] usbcore: registered new interface driver usbhid
[    0.807061] usbhid: USB HID core driver
[    0.811617] IPv4 over IPsec tunneling driver
[    0.816458] ipt_CLUSTERIP: ClusterIP Version 0.8 loaded successfully
[    0.822866] Initializing XFRM netlink socket
[    0.827522] NET: Registered PF_INET6 protocol family
[    0.955712] Segment Routing with IPv6
[    0.959637] sit: IPv6, IPv4 and MPLS over IPv4 tunneling driver
[    0.966526] NET: Registered PF_PACKET protocol family
[    0.971663] NET: Registered PF_KEY protocol family
[    0.976464] 8021q: 802.1Q VLAN Support v1.8
[    0.980675] lib80211: common routines for IEEE802.11 drivers
[    0.986398] Registering SWP/SWPB emulation handler
[    0.999840] Freeing unused kernel image (initmem) memory: 8192K
[    1.006133] Run /init as init process



-- 
Bert Vermeulen
bert@biot.com

Re: [PATCH 3/5] ARM: dts: Add basic support for EcoNet EN7523

[Bert Vermeulen]

On 7/30/21 4:53 PM, Marc Zyngier wrote:
> On Fri, 30 Jul 2021 15:31:36 +0100,
> Linus Walleij <linus.walleij@linaro.org> wrote:
>> 
>> Paging Marc Z and Catalin just so they can see this:
>> 
>> On Fri, Jul 30, 2021 at 3:49 PM Bert Vermeulen <bert@biot.com> wrote:
>> 
>> > From: John Crispin <john@phrozen.org>
>> >
>> > Add basic support for EcoNet EN7523, enough for booting to console.
>> >
>> > The UART is basically 8250-compatible, except for the clock selection.
>> > A clock-frequency value is synthesized to get this to run at 115200 bps.
>> >
>> > Signed-off-by: John Crispin <john@phrozen.org>
>> > Signed-off-by: Bert Vermeulen <bert@biot.com>
>> (...)
>> > +       gic: interrupt-controller@09000000 {
>> > +               compatible = "arm,gic-v3";
>> > +               interrupt-controller;
>> > +               #interrupt-cells = <3>;
>> > +               #address-cells = <1>;
>> > +               #size-cells = <1>;
>> > +               reg = <0x09000000 0x20000>,
>> > +                         <0x09080000 0x80000>;
>> > +               interrupts = <GIC_PPI 9 IRQ_TYPE_LEVEL_LOW>;
>> > +
>> > +               its: gic-its@09020000 {
>> > +                       compatible = "arm,gic-v3-its";
>> > +                       msi-controller;
>> > +                       #msi-cell = <1>;
>> > +                       reg = <0x090200000 0x20000>;
>> > +               };
>> > +       };
>> 
>> Yup GICv3 on ARM32-only silicon.
> 
> Hey, why not. But that's very unlikely, as Cortex-A7 doesn't have a
> GICv3 CPU interface built in (it only has the memory mapped version),
> and A53/57 were the first CPUs to ever support GICv3. I don't believe
> the description of the CPU in the DT is accurate.
> 
> Bert, please send a kernel boot log.

At the bottom of this mail.

>> > +       timer {
>> > +               compatible = "arm,armv8-timer";
>> > +               interrupt-parent = <&gic>;
>> > +               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)>;
> 
> Copy paste bug. These are not valid intspecs for GICv3.

FWIW all these were taken verbatim from the vendor's SDK. Not that this 
makes them necessarily correct :)

>> > +               clock-frequency = <25000000>;
>> > +       };
>> 
>> Also arm,armv8-timer on ARM32-only silicon.
> 
> Probably because that's not what it actually is. My bet is on A53 with
> a crippled firmware.

kernel boot log:

[    0.000000] Booting Linux on physical CPU 0x0
[    0.000000] Linux version 5.14.0-rc3-00042-g3af70c6f8e95-dirty 
(bert@sumner) (arm-linux-gnueabi-gcc (Ubuntu 9.3.0-17ubuntu1~20.04) 9.3.0, 
GNU ld (GNU Binutils for Ubuntu) 2.34) #392 SMP Sun Aug 1 10:28:13 CEST 2021
[    0.000000] CPU: ARMv7 Processor [410fd034] revision 4 (ARMv7), cr=10c5383d
[    0.000000] CPU: div instructions available: patching division code
[    0.000000] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing 
instruction cache
[    0.000000] OF: fdt: Machine model: econet,en7523
[    0.000000] earlycon: uart8250 at MMIO32 0x1fbf0000 (options '')
[    0.000000] printk: bootconsole [uart8250] enabled
[    0.000000] Memory policy: Data cache writealloc
[    0.000000] Zone ranges:
[    0.000000]   Normal   [mem 0x0000000080000000-0x000000009fffffff]
[    0.000000]   HighMem  empty
[    0.000000] Movable zone start for each node
[    0.000000] Early memory node ranges
[    0.000000]   node   0: [mem 0x0000000080000000-0x0000000083ffffff]
[    0.000000]   node   0: [mem 0x0000000084000000-0x00000000849fffff]
[    0.000000]   node   0: [mem 0x0000000084a00000-0x0000000084afffff]
[    0.000000]   node   0: [mem 0x0000000084b00000-0x0000000084bfffff]
[    0.000000]   node   0: [mem 0x0000000084c00000-0x0000000084ffffff]
[    0.000000]   node   0: [mem 0x0000000085000000-0x00000000869fffff]
[    0.000000]   node   0: [mem 0x0000000086a00000-0x0000000086afffff]
[    0.000000]   node   0: [mem 0x0000000086b00000-0x0000000086bfffff]
[    0.000000]   node   0: [mem 0x0000000086c00000-0x0000000086cfffff]
[    0.000000]   node   0: [mem 0x0000000086d00000-0x0000000086dfffff]
[    0.000000]   node   0: [mem 0x0000000086e00000-0x000000009fffffff]
[    0.000000] Initmem setup node 0 [mem 0x0000000080000000-0x000000009fffffff]
[    0.000000] percpu: Embedded 15 pages/cpu s30604 r8192 d22644 u61440
[    0.000000] Built 1 zonelists, mobility grouping on.  Total pages: 129920
[    0.000000] Kernel command line: earlycon=uart8250,mmio32,0x1fbf0000 
console=ttyS0,115200
[    0.000000] Dentry cache hash table entries: 65536 (order: 6, 262144 
bytes, linear)
[    0.000000] Inode-cache hash table entries: 32768 (order: 5, 131072 
bytes, linear)
[    0.000000] mem auto-init: stack:off, heap alloc:off, heap free:off
[    0.000000] Memory: 461316K/524288K available (7168K kernel code, 312K 
rwdata, 1488K rodata, 8192K init, 142K bss, 62972K reserved, 0K 
cma-reserved, 0K highmem)
[    0.000000] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=2, Nodes=1
[    0.000000] rcu: Hierarchical RCU implementation.
[    0.000000] rcu: RCU calculated value of scheduler-enlistment delay is 10 
jiffies.
[    0.000000] NR_IRQS: 16, nr_irqs: 16, preallocated irqs: 16
[    0.000000] GICv3: 256 SPIs implemented
[    0.000000] GICv3: 0 Extended SPIs implemented
[    0.000000] GICv3: Distributor has no Range Selector support
[    0.000000] GICv3: 16 PPIs implemented
[    0.000000] GICv3: CPU0: found redistributor 0 region 0:0x09080000
[    0.000000] random: get_random_bytes called from start_kernel+0x484/0x628 
with crng_init=0
[    0.000000] arch_timer: cp15 timer(s) running at 25.00MHz (virt).
[    0.000000] clocksource: arch_sys_counter: mask: 0xffffffffffffff 
max_cycles: 0x5c40939b5, max_idle_ns: 440795202646 ns
[    0.000000] sched_clock: 56 bits at 25MHz, resolution 40ns, wraps every 
4398046511100ns
[    0.008791] Switching to timer-based delay loop, resolution 40ns
[    0.015454] Calibrating delay loop (skipped), value calculated using 
timer frequency.. 50.00 BogoMIPS (lpj=250000)
[    0.026833] pid_max: default: 32768 minimum: 301
[    0.032013] Mount-cache hash table entries: 1024 (order: 0, 4096 bytes, 
linear)
[    0.040047] Mountpoint-cache hash table entries: 1024 (order: 0, 4096 
bytes, linear)
[    0.049172] CPU: Testing write buffer coherency: ok
[    0.054780] CPU0: thread -1, cpu 0, socket 0, mpidr 80000000
[    0.061362] Setting up static identity map for 0x80100000 - 0x80100060
[    0.068667] rcu: Hierarchical SRCU implementation.
[    0.074290] gic-its@09020000: unable to locate ITS domain
[    0.080461] smp: Bringing up secondary CPUs ...
[    0.085769] smp: Brought up 1 node, 1 CPU
[    0.090179] SMP: Total of 1 processors activated (50.00 BogoMIPS).
[    0.097013] CPU: All CPU(s) started in SVC mode.
[    0.103634] clocksource: jiffies: mask: 0xffffffff max_cycles: 
0xffffffff, max_idle_ns: 19112604462750000 ns
[    0.114499] futex hash table entries: 512 (order: 3, 32768 bytes, linear)
[    0.122380] NET: Registered PF_NETLINK/PF_ROUTE protocol family
[    0.129153] DMA: preallocated 256 KiB pool for atomic coherent allocations
[    0.137265] thermal_sys: Registered thermal governor 'step_wise'
[    0.137333] No ATAGs?
[    0.153205] iommu: Default domain type: Translated
[    0.158713] usbcore: registered new interface driver usbfs
[    0.164769] usbcore: registered new interface driver hub
[    0.170660] usbcore: registered new device driver usb
[    0.176704] NET: Registered PF_ATMPVC protocol family
[    0.182296] NET: Registered PF_ATMSVC protocol family
[    0.188055] clocksource: Switched to clocksource arch_sys_counter
[    0.195462] NET: Registered PF_INET protocol family
[    0.200971] IP idents hash table entries: 8192 (order: 4, 65536 bytes, 
linear)
[    0.209452] tcp_listen_portaddr_hash hash table entries: 512 (order: 0, 
6144 bytes, linear)
[    0.218713] TCP established hash table entries: 4096 (order: 2, 16384 
bytes, linear)
[    0.227251] TCP bind hash table entries: 4096 (order: 3, 32768 bytes, linear)
[    0.235158] TCP: Hash tables configured (established 4096 bind 4096)
[    0.242212] UDP hash table entries: 256 (order: 1, 8192 bytes, linear)
[    0.249416] UDP-Lite hash table entries: 256 (order: 1, 8192 bytes, linear)
[    0.257205] NET: Registered PF_UNIX/PF_LOCAL protocol family
[    0.263464] PCI: CLS 0 bytes, default 64
[    0.348846] workingset: timestamp_bits=14 max_order=17 bucket_order=3
[    0.360684] squashfs: version 4.0 (2009/01/31) Phillip Lougher
[    0.367197] ntfs: driver 2.1.32 [Flags: R/W DEBUG].
[    0.372785] jffs2: version 2.2. (NAND) © 2001-2006 Red Hat, Inc.
[    0.598557] io scheduler mq-deadline registered
[    0.603555] io scheduler kyber registered
[    0.619475] Serial: 8250/16550 driver, 2 ports, IRQ sharing enabled
[    0.626838] printk: console [ttyS0] disabled
[    0.631671] 1fbf0000.serial: ttyS0 at MMIO 0x1fbf0000 (irq = 28, 
base_baud = 115200) is a 8250
[    0.641169] printk: console [ttyS0] enabled
[    0.641169] printk: console [ttyS0] enabled
[    0.649943] printk: bootconsole [uart8250] disabled
[    0.649943] printk: bootconsole [uart8250] disabled
[    0.706413] brd: module loaded
[    0.709758] PPP generic driver version 2.4.2
[    0.714097] PPP BSD Compression module registered
[    0.718832] PPP Deflate Compression module registered
[    0.723877] NET: Registered PF_PPPOX protocol family
[    0.728989] usbcore: registered new interface driver cdc_acm
[    0.734648] cdc_acm: USB Abstract Control Model driver for USB modems and 
ISDN adapters
[    0.742712] usbcore: registered new interface driver usbserial_generic
[    0.749278] usbserial: USB Serial support registered for generic
[    0.755299] usbcore: registered new interface driver cypress_m8
[    0.761234] usbserial: USB Serial support registered for DeLorme 
Earthmate USB
[    0.768476] usbserial: USB Serial support registered for HID->COM RS232 
Adapter
[    0.775790] usbserial: USB Serial support registered for Nokia CA-42 V2 
Adapter
[    0.783121] usbcore: registered new interface driver ftdi_sio
[    0.788889] usbserial: USB Serial support registered for FTDI USB Serial 
Device
[    0.796272] hid: raw HID events driver (C) Jiri Kosina
[    0.801492] usbcore: registered new interface driver usbhid
[    0.807061] usbhid: USB HID core driver
[    0.811617] IPv4 over IPsec tunneling driver
[    0.816458] ipt_CLUSTERIP: ClusterIP Version 0.8 loaded successfully
[    0.822866] Initializing XFRM netlink socket
[    0.827522] NET: Registered PF_INET6 protocol family
[    0.955712] Segment Routing with IPv6
[    0.959637] sit: IPv6, IPv4 and MPLS over IPv4 tunneling driver
[    0.966526] NET: Registered PF_PACKET protocol family
[    0.971663] NET: Registered PF_KEY protocol family
[    0.976464] 8021q: 802.1Q VLAN Support v1.8
[    0.980675] lib80211: common routines for IEEE802.11 drivers
[    0.986398] Registering SWP/SWPB emulation handler
[    0.999840] Freeing unused kernel image (initmem) memory: 8192K
[    1.006133] Run /init as init process



-- 
Bert Vermeulen
bert@biot.com

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH 3/5] ARM: dts: Add basic support for EcoNet EN7523

[Bert Vermeulen]

On 7/30/21 4:53 PM, Marc Zyngier wrote:
> On Fri, 30 Jul 2021 15:31:36 +0100,
> Linus Walleij <linus.walleij@linaro.org> wrote:
>> 
>> Paging Marc Z and Catalin just so they can see this:
>> 
>> On Fri, Jul 30, 2021 at 3:49 PM Bert Vermeulen <bert@biot.com> wrote:
>> 
>> > From: John Crispin <john@phrozen.org>
>> >
>> > Add basic support for EcoNet EN7523, enough for booting to console.
>> >
>> > The UART is basically 8250-compatible, except for the clock selection.
>> > A clock-frequency value is synthesized to get this to run at 115200 bps.
>> >
>> > Signed-off-by: John Crispin <john@phrozen.org>
>> > Signed-off-by: Bert Vermeulen <bert@biot.com>
>> (...)
>> > +       gic: interrupt-controller@09000000 {
>> > +               compatible = "arm,gic-v3";
>> > +               interrupt-controller;
>> > +               #interrupt-cells = <3>;
>> > +               #address-cells = <1>;
>> > +               #size-cells = <1>;
>> > +               reg = <0x09000000 0x20000>,
>> > +                         <0x09080000 0x80000>;
>> > +               interrupts = <GIC_PPI 9 IRQ_TYPE_LEVEL_LOW>;
>> > +
>> > +               its: gic-its@09020000 {
>> > +                       compatible = "arm,gic-v3-its";
>> > +                       msi-controller;
>> > +                       #msi-cell = <1>;
>> > +                       reg = <0x090200000 0x20000>;
>> > +               };
>> > +       };
>> 
>> Yup GICv3 on ARM32-only silicon.
> 
> Hey, why not. But that's very unlikely, as Cortex-A7 doesn't have a
> GICv3 CPU interface built in (it only has the memory mapped version),
> and A53/57 were the first CPUs to ever support GICv3. I don't believe
> the description of the CPU in the DT is accurate.
> 
> Bert, please send a kernel boot log.

At the bottom of this mail.

>> > +       timer {
>> > +               compatible = "arm,armv8-timer";
>> > +               interrupt-parent = <&gic>;
>> > +               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)>;
> 
> Copy paste bug. These are not valid intspecs for GICv3.

FWIW all these were taken verbatim from the vendor's SDK. Not that this 
makes them necessarily correct :)

>> > +               clock-frequency = <25000000>;
>> > +       };
>> 
>> Also arm,armv8-timer on ARM32-only silicon.
> 
> Probably because that's not what it actually is. My bet is on A53 with
> a crippled firmware.

kernel boot log:

[    0.000000] Booting Linux on physical CPU 0x0
[    0.000000] Linux version 5.14.0-rc3-00042-g3af70c6f8e95-dirty 
(bert@sumner) (arm-linux-gnueabi-gcc (Ubuntu 9.3.0-17ubuntu1~20.04) 9.3.0, 
GNU ld (GNU Binutils for Ubuntu) 2.34) #392 SMP Sun Aug 1 10:28:13 CEST 2021
[    0.000000] CPU: ARMv7 Processor [410fd034] revision 4 (ARMv7), cr=10c5383d
[    0.000000] CPU: div instructions available: patching division code
[    0.000000] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing 
instruction cache
[    0.000000] OF: fdt: Machine model: econet,en7523
[    0.000000] earlycon: uart8250 at MMIO32 0x1fbf0000 (options '')
[    0.000000] printk: bootconsole [uart8250] enabled
[    0.000000] Memory policy: Data cache writealloc
[    0.000000] Zone ranges:
[    0.000000]   Normal   [mem 0x0000000080000000-0x000000009fffffff]
[    0.000000]   HighMem  empty
[    0.000000] Movable zone start for each node
[    0.000000] Early memory node ranges
[    0.000000]   node   0: [mem 0x0000000080000000-0x0000000083ffffff]
[    0.000000]   node   0: [mem 0x0000000084000000-0x00000000849fffff]
[    0.000000]   node   0: [mem 0x0000000084a00000-0x0000000084afffff]
[    0.000000]   node   0: [mem 0x0000000084b00000-0x0000000084bfffff]
[    0.000000]   node   0: [mem 0x0000000084c00000-0x0000000084ffffff]
[    0.000000]   node   0: [mem 0x0000000085000000-0x00000000869fffff]
[    0.000000]   node   0: [mem 0x0000000086a00000-0x0000000086afffff]
[    0.000000]   node   0: [mem 0x0000000086b00000-0x0000000086bfffff]
[    0.000000]   node   0: [mem 0x0000000086c00000-0x0000000086cfffff]
[    0.000000]   node   0: [mem 0x0000000086d00000-0x0000000086dfffff]
[    0.000000]   node   0: [mem 0x0000000086e00000-0x000000009fffffff]
[    0.000000] Initmem setup node 0 [mem 0x0000000080000000-0x000000009fffffff]
[    0.000000] percpu: Embedded 15 pages/cpu s30604 r8192 d22644 u61440
[    0.000000] Built 1 zonelists, mobility grouping on.  Total pages: 129920
[    0.000000] Kernel command line: earlycon=uart8250,mmio32,0x1fbf0000 
console=ttyS0,115200
[    0.000000] Dentry cache hash table entries: 65536 (order: 6, 262144 
bytes, linear)
[    0.000000] Inode-cache hash table entries: 32768 (order: 5, 131072 
bytes, linear)
[    0.000000] mem auto-init: stack:off, heap alloc:off, heap free:off
[    0.000000] Memory: 461316K/524288K available (7168K kernel code, 312K 
rwdata, 1488K rodata, 8192K init, 142K bss, 62972K reserved, 0K 
cma-reserved, 0K highmem)
[    0.000000] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=2, Nodes=1
[    0.000000] rcu: Hierarchical RCU implementation.
[    0.000000] rcu: RCU calculated value of scheduler-enlistment delay is 10 
jiffies.
[    0.000000] NR_IRQS: 16, nr_irqs: 16, preallocated irqs: 16
[    0.000000] GICv3: 256 SPIs implemented
[    0.000000] GICv3: 0 Extended SPIs implemented
[    0.000000] GICv3: Distributor has no Range Selector support
[    0.000000] GICv3: 16 PPIs implemented
[    0.000000] GICv3: CPU0: found redistributor 0 region 0:0x09080000
[    0.000000] random: get_random_bytes called from start_kernel+0x484/0x628 
with crng_init=0
[    0.000000] arch_timer: cp15 timer(s) running at 25.00MHz (virt).
[    0.000000] clocksource: arch_sys_counter: mask: 0xffffffffffffff 
max_cycles: 0x5c40939b5, max_idle_ns: 440795202646 ns
[    0.000000] sched_clock: 56 bits at 25MHz, resolution 40ns, wraps every 
4398046511100ns
[    0.008791] Switching to timer-based delay loop, resolution 40ns
[    0.015454] Calibrating delay loop (skipped), value calculated using 
timer frequency.. 50.00 BogoMIPS (lpj=250000)
[    0.026833] pid_max: default: 32768 minimum: 301
[    0.032013] Mount-cache hash table entries: 1024 (order: 0, 4096 bytes, 
linear)
[    0.040047] Mountpoint-cache hash table entries: 1024 (order: 0, 4096 
bytes, linear)
[    0.049172] CPU: Testing write buffer coherency: ok
[    0.054780] CPU0: thread -1, cpu 0, socket 0, mpidr 80000000
[    0.061362] Setting up static identity map for 0x80100000 - 0x80100060
[    0.068667] rcu: Hierarchical SRCU implementation.
[    0.074290] gic-its@09020000: unable to locate ITS domain
[    0.080461] smp: Bringing up secondary CPUs ...
[    0.085769] smp: Brought up 1 node, 1 CPU
[    0.090179] SMP: Total of 1 processors activated (50.00 BogoMIPS).
[    0.097013] CPU: All CPU(s) started in SVC mode.
[    0.103634] clocksource: jiffies: mask: 0xffffffff max_cycles: 
0xffffffff, max_idle_ns: 19112604462750000 ns
[    0.114499] futex hash table entries: 512 (order: 3, 32768 bytes, linear)
[    0.122380] NET: Registered PF_NETLINK/PF_ROUTE protocol family
[    0.129153] DMA: preallocated 256 KiB pool for atomic coherent allocations
[    0.137265] thermal_sys: Registered thermal governor 'step_wise'
[    0.137333] No ATAGs?
[    0.153205] iommu: Default domain type: Translated
[    0.158713] usbcore: registered new interface driver usbfs
[    0.164769] usbcore: registered new interface driver hub
[    0.170660] usbcore: registered new device driver usb
[    0.176704] NET: Registered PF_ATMPVC protocol family
[    0.182296] NET: Registered PF_ATMSVC protocol family
[    0.188055] clocksource: Switched to clocksource arch_sys_counter
[    0.195462] NET: Registered PF_INET protocol family
[    0.200971] IP idents hash table entries: 8192 (order: 4, 65536 bytes, 
linear)
[    0.209452] tcp_listen_portaddr_hash hash table entries: 512 (order: 0, 
6144 bytes, linear)
[    0.218713] TCP established hash table entries: 4096 (order: 2, 16384 
bytes, linear)
[    0.227251] TCP bind hash table entries: 4096 (order: 3, 32768 bytes, linear)
[    0.235158] TCP: Hash tables configured (established 4096 bind 4096)
[    0.242212] UDP hash table entries: 256 (order: 1, 8192 bytes, linear)
[    0.249416] UDP-Lite hash table entries: 256 (order: 1, 8192 bytes, linear)
[    0.257205] NET: Registered PF_UNIX/PF_LOCAL protocol family
[    0.263464] PCI: CLS 0 bytes, default 64
[    0.348846] workingset: timestamp_bits=14 max_order=17 bucket_order=3
[    0.360684] squashfs: version 4.0 (2009/01/31) Phillip Lougher
[    0.367197] ntfs: driver 2.1.32 [Flags: R/W DEBUG].
[    0.372785] jffs2: version 2.2. (NAND) © 2001-2006 Red Hat, Inc.
[    0.598557] io scheduler mq-deadline registered
[    0.603555] io scheduler kyber registered
[    0.619475] Serial: 8250/16550 driver, 2 ports, IRQ sharing enabled
[    0.626838] printk: console [ttyS0] disabled
[    0.631671] 1fbf0000.serial: ttyS0 at MMIO 0x1fbf0000 (irq = 28, 
base_baud = 115200) is a 8250
[    0.641169] printk: console [ttyS0] enabled
[    0.641169] printk: console [ttyS0] enabled
[    0.649943] printk: bootconsole [uart8250] disabled
[    0.649943] printk: bootconsole [uart8250] disabled
[    0.706413] brd: module loaded
[    0.709758] PPP generic driver version 2.4.2
[    0.714097] PPP BSD Compression module registered
[    0.718832] PPP Deflate Compression module registered
[    0.723877] NET: Registered PF_PPPOX protocol family
[    0.728989] usbcore: registered new interface driver cdc_acm
[    0.734648] cdc_acm: USB Abstract Control Model driver for USB modems and 
ISDN adapters
[    0.742712] usbcore: registered new interface driver usbserial_generic
[    0.749278] usbserial: USB Serial support registered for generic
[    0.755299] usbcore: registered new interface driver cypress_m8
[    0.761234] usbserial: USB Serial support registered for DeLorme 
Earthmate USB
[    0.768476] usbserial: USB Serial support registered for HID->COM RS232 
Adapter
[    0.775790] usbserial: USB Serial support registered for Nokia CA-42 V2 
Adapter
[    0.783121] usbcore: registered new interface driver ftdi_sio
[    0.788889] usbserial: USB Serial support registered for FTDI USB Serial 
Device
[    0.796272] hid: raw HID events driver (C) Jiri Kosina
[    0.801492] usbcore: registered new interface driver usbhid
[    0.807061] usbhid: USB HID core driver
[    0.811617] IPv4 over IPsec tunneling driver
[    0.816458] ipt_CLUSTERIP: ClusterIP Version 0.8 loaded successfully
[    0.822866] Initializing XFRM netlink socket
[    0.827522] NET: Registered PF_INET6 protocol family
[    0.955712] Segment Routing with IPv6
[    0.959637] sit: IPv6, IPv4 and MPLS over IPv4 tunneling driver
[    0.966526] NET: Registered PF_PACKET protocol family
[    0.971663] NET: Registered PF_KEY protocol family
[    0.976464] 8021q: 802.1Q VLAN Support v1.8
[    0.980675] lib80211: common routines for IEEE802.11 drivers
[    0.986398] Registering SWP/SWPB emulation handler
[    0.999840] Freeing unused kernel image (initmem) memory: 8192K
[    1.006133] Run /init as init process



-- 
Bert Vermeulen
bert@biot.com

Re: [PATCH 3/5] ARM: dts: Add basic support for EcoNet EN7523

[Arnd Bergmann]

On Sun, Aug 1, 2021 at 11:07 AM Bert Vermeulen <bert@biot.com> wrote:
> On 7/30/21 4:53 PM, Marc Zyngier wrote: On Fri, 30 Jul 2021 15:31:36 +0100,
> > Probably because that's not what it actually is. My bet is on A53 with
> > a crippled firmware.
>
> [    0.000000] Booting Linux on physical CPU 0x0
> [    0.000000] Linux version 5.14.0-rc3-00042-g3af70c6f8e95-dirty
> (bert@sumner) (arm-linux-gnueabi-gcc (Ubuntu 9.3.0-17ubuntu1~20.04) 9.3.0,
> GNU ld (GNU Binutils for Ubuntu) 2.34) #392 SMP Sun Aug 1 10:28:13 CEST 2021
> [    0.000000] CPU: ARMv7 Processor [410fd034] revision 4 (ARMv7), cr=10c5383d
> [    0.000000] CPU: div instructions available: patching division code
> [    0.000000] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache

Good guess! CPUID 410fd034 is a Cortex-53 (d03) indeed. I wish we
would just print
cleartext names for the CPUs that the kernel already knows about here, I think
the fact that we just print 'ARMv7 processor' (which is wrong) and
spell out the revision
but not implementer/part/variant numbers is rather silly.

Is there a way in the boot loader to boot up a 64-bit kernel?

       Arnd

Re: [PATCH 3/5] ARM: dts: Add basic support for EcoNet EN7523

[Arnd Bergmann]

On Sun, Aug 1, 2021 at 11:07 AM Bert Vermeulen <bert@biot.com> wrote:
> On 7/30/21 4:53 PM, Marc Zyngier wrote: On Fri, 30 Jul 2021 15:31:36 +0100,
> > Probably because that's not what it actually is. My bet is on A53 with
> > a crippled firmware.
>
> [    0.000000] Booting Linux on physical CPU 0x0
> [    0.000000] Linux version 5.14.0-rc3-00042-g3af70c6f8e95-dirty
> (bert@sumner) (arm-linux-gnueabi-gcc (Ubuntu 9.3.0-17ubuntu1~20.04) 9.3.0,
> GNU ld (GNU Binutils for Ubuntu) 2.34) #392 SMP Sun Aug 1 10:28:13 CEST 2021
> [    0.000000] CPU: ARMv7 Processor [410fd034] revision 4 (ARMv7), cr=10c5383d
> [    0.000000] CPU: div instructions available: patching division code
> [    0.000000] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache

Good guess! CPUID 410fd034 is a Cortex-53 (d03) indeed. I wish we
would just print
cleartext names for the CPUs that the kernel already knows about here, I think
the fact that we just print 'ARMv7 processor' (which is wrong) and
spell out the revision
but not implementer/part/variant numbers is rather silly.

Is there a way in the boot loader to boot up a 64-bit kernel?

       Arnd

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH 3/5] ARM: dts: Add basic support for EcoNet EN7523

[Arnd Bergmann]

On Sun, Aug 1, 2021 at 11:07 AM Bert Vermeulen <bert@biot.com> wrote:
> On 7/30/21 4:53 PM, Marc Zyngier wrote: On Fri, 30 Jul 2021 15:31:36 +0100,
> > Probably because that's not what it actually is. My bet is on A53 with
> > a crippled firmware.
>
> [    0.000000] Booting Linux on physical CPU 0x0
> [    0.000000] Linux version 5.14.0-rc3-00042-g3af70c6f8e95-dirty
> (bert@sumner) (arm-linux-gnueabi-gcc (Ubuntu 9.3.0-17ubuntu1~20.04) 9.3.0,
> GNU ld (GNU Binutils for Ubuntu) 2.34) #392 SMP Sun Aug 1 10:28:13 CEST 2021
> [    0.000000] CPU: ARMv7 Processor [410fd034] revision 4 (ARMv7), cr=10c5383d
> [    0.000000] CPU: div instructions available: patching division code
> [    0.000000] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache

Good guess! CPUID 410fd034 is a Cortex-53 (d03) indeed. I wish we
would just print
cleartext names for the CPUs that the kernel already knows about here, I think
the fact that we just print 'ARMv7 processor' (which is wrong) and
spell out the revision
but not implementer/part/variant numbers is rather silly.

Is there a way in the boot loader to boot up a 64-bit kernel?

       Arnd

Re: [PATCH 3/5] ARM: dts: Add basic support for EcoNet EN7523

[Marc Zyngier]

On Sun, 01 Aug 2021 10:07:48 +0100,
Bert Vermeulen <bert@biot.com> wrote:
> 
> On 7/30/21 4:53 PM, Marc Zyngier wrote:
> > On Fri, 30 Jul 2021 15:31:36 +0100,
> > Linus Walleij <linus.walleij@linaro.org> wrote:
> >> 
> >> Paging Marc Z and Catalin just so they can see this:
> >> 
> >> On Fri, Jul 30, 2021 at 3:49 PM Bert Vermeulen <bert@biot.com> wrote:
> >> 
> >> > From: John Crispin <john@phrozen.org>
> >> >
> >> > Add basic support for EcoNet EN7523, enough for booting to console.
> >> >
> >> > The UART is basically 8250-compatible, except for the clock selection.
> >> > A clock-frequency value is synthesized to get this to run at 115200 bps.
> >> >
> >> > Signed-off-by: John Crispin <john@phrozen.org>
> >> > Signed-off-by: Bert Vermeulen <bert@biot.com>
> >> (...)
> >> > +       gic: interrupt-controller@09000000 {
> >> > +               compatible = "arm,gic-v3";
> >> > +               interrupt-controller;
> >> > +               #interrupt-cells = <3>;
> >> > +               #address-cells = <1>;
> >> > +               #size-cells = <1>;
> >> > +               reg = <0x09000000 0x20000>,
> >> > +                         <0x09080000 0x80000>;
> >> > +               interrupts = <GIC_PPI 9 IRQ_TYPE_LEVEL_LOW>;
> >> > +
> >> > +               its: gic-its@09020000 {
> >> > +                       compatible = "arm,gic-v3-its";
> >> > +                       msi-controller;
> >> > +                       #msi-cell = <1>;
> >> > +                       reg = <0x090200000 0x20000>;
> >> > +               };
> >> > +       };
> >> 
> >> Yup GICv3 on ARM32-only silicon.
> > 
> > Hey, why not. But that's very unlikely, as Cortex-A7 doesn't have a
> > GICv3 CPU interface built in (it only has the memory mapped version),
> > and A53/57 were the first CPUs to ever support GICv3. I don't believe
> > the description of the CPU in the DT is accurate.
> > 
> > Bert, please send a kernel boot log.
> 
> At the bottom of this mail.
> 
> >> > +       timer {
> >> > +               compatible = "arm,armv8-timer";
> >> > +               interrupt-parent = <&gic>;
> >> > +               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)>;
> > 
> > Copy paste bug. These are not valid intspecs for GICv3.
> 
> FWIW all these were taken verbatim from the vendor's SDK. Not that
> this makes them necessarily correct :)

Please, never copy anything verbatim from an existing DT, specially
not a vendor pile of crap.

Most integrators only cherry-picking DT random fragments without
trying to understand what they imply, beat them together until there
is a sign of life, and end-up with a monster that bears no resemblance
with reality.

Take an existing DT as a hint of what *could* be there, and work out
from first principles what actually makes sense. Yes, it is a lot of
work and involves reading specs, TRMs and whatnot. But at least it
will be correct, which is the standard that upstream is supposed to
uphold.

A shining example is what is below:

> 
> >> > +               clock-frequency = <25000000>;
> >> > +       };
> >> 
> >> Also arm,armv8-timer on ARM32-only silicon.
> > 
> > Probably because that's not what it actually is. My bet is on A53 with
> > a crippled firmware.
> 
> kernel boot log:
> 
> [    0.000000] Booting Linux on physical CPU 0x0
> [    0.000000] Linux version 5.14.0-rc3-00042-g3af70c6f8e95-dirty
> (bert@sumner) (arm-linux-gnueabi-gcc (Ubuntu 9.3.0-17ubuntu1~20.04)
> 9.3.0, GNU ld (GNU Binutils for Ubuntu) 2.34) #392 SMP Sun Aug 1
> 10:28:13 CEST 2021
> [    0.000000] CPU: ARMv7 Processor [410fd034] revision 4 (ARMv7), cr=10c5383d

As expected: 410fd034 = Cortex-A53 r0p4. Pretty far from a Cortex-A7,
isn't it?

> [    0.000000] CPU: div instructions available: patching division code
> [    0.000000] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing
> instruction cache
> [    0.000000] OF: fdt: Machine model: econet,en7523
> [    0.000000] earlycon: uart8250 at MMIO32 0x1fbf0000 (options '')
> [    0.000000] printk: bootconsole [uart8250] enabled
> [    0.000000] Memory policy: Data cache writealloc
> [    0.000000] Zone ranges:
> [    0.000000]   Normal   [mem 0x0000000080000000-0x000000009fffffff]
> [    0.000000]   HighMem  empty
> [    0.000000] Movable zone start for each node
> [    0.000000] Early memory node ranges
> [    0.000000]   node   0: [mem 0x0000000080000000-0x0000000083ffffff]
> [    0.000000]   node   0: [mem 0x0000000084000000-0x00000000849fffff]
> [    0.000000]   node   0: [mem 0x0000000084a00000-0x0000000084afffff]
> [    0.000000]   node   0: [mem 0x0000000084b00000-0x0000000084bfffff]
> [    0.000000]   node   0: [mem 0x0000000084c00000-0x0000000084ffffff]
> [    0.000000]   node   0: [mem 0x0000000085000000-0x00000000869fffff]
> [    0.000000]   node   0: [mem 0x0000000086a00000-0x0000000086afffff]
> [    0.000000]   node   0: [mem 0x0000000086b00000-0x0000000086bfffff]
> [    0.000000]   node   0: [mem 0x0000000086c00000-0x0000000086cfffff]
> [    0.000000]   node   0: [mem 0x0000000086d00000-0x0000000086dfffff]
> [    0.000000]   node   0: [mem 0x0000000086e00000-0x000000009fffffff]
> [    0.000000] Initmem setup node 0 [mem 0x0000000080000000-0x000000009fffffff]
> [    0.000000] percpu: Embedded 15 pages/cpu s30604 r8192 d22644 u61440
> [    0.000000] Built 1 zonelists, mobility grouping on.  Total pages: 129920
> [    0.000000] Kernel command line:
> earlycon=uart8250,mmio32,0x1fbf0000 console=ttyS0,115200
> [    0.000000] Dentry cache hash table entries: 65536 (order: 6,
> 262144 bytes, linear)
> [    0.000000] Inode-cache hash table entries: 32768 (order: 5, 131072
> bytes, linear)
> [    0.000000] mem auto-init: stack:off, heap alloc:off, heap free:off
> [    0.000000] Memory: 461316K/524288K available (7168K kernel code,
> 312K rwdata, 1488K rodata, 8192K init, 142K bss, 62972K reserved, 0K
> cma-reserved, 0K highmem)
> [    0.000000] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=2, Nodes=1
> [    0.000000] rcu: Hierarchical RCU implementation.
> [    0.000000] rcu: RCU calculated value of scheduler-enlistment delay
> is 10 jiffies.
> [    0.000000] NR_IRQS: 16, nr_irqs: 16, preallocated irqs: 16
> [    0.000000] GICv3: 256 SPIs implemented
> [    0.000000] GICv3: 0 Extended SPIs implemented
> [    0.000000] GICv3: Distributor has no Range Selector support
> [    0.000000] GICv3: 16 PPIs implemented
> [    0.000000] GICv3: CPU0: found redistributor 0 region 0:0x09080000

Interestingly, we don't program the property/pending tables for the
RD. Which means this SoC doesn't support LPIs, and thus *does not*
have an ITS, despite what you advertise.

> [    0.000000] random: get_random_bytes called from
> start_kernel+0x484/0x628 with crng_init=0
> [    0.000000] arch_timer: cp15 timer(s) running at 25.00MHz (virt).
> [    0.000000] clocksource: arch_sys_counter: mask: 0xffffffffffffff
> max_cycles: 0x5c40939b5, max_idle_ns: 440795202646 ns
> [    0.000000] sched_clock: 56 bits at 25MHz, resolution 40ns, wraps
> every 4398046511100ns
> [    0.008791] Switching to timer-based delay loop, resolution 40ns
> [    0.015454] Calibrating delay loop (skipped), value calculated
> using timer frequency.. 50.00 BogoMIPS (lpj=250000)
> [    0.026833] pid_max: default: 32768 minimum: 301
> [    0.032013] Mount-cache hash table entries: 1024 (order: 0, 4096
> bytes, linear)
> [    0.040047] Mountpoint-cache hash table entries: 1024 (order: 0,
> 4096 bytes, linear)
> [    0.049172] CPU: Testing write buffer coherency: ok
> [    0.054780] CPU0: thread -1, cpu 0, socket 0, mpidr 80000000
> [    0.061362] Setting up static identity map for 0x80100000 - 0x80100060
> [    0.068667] rcu: Hierarchical SRCU implementation.
> [    0.074290] gic-its@09020000: unable to locate ITS domain

Confirmed. No LPI support, no ITS.

	M.

-- 
Without deviation from the norm, progress is not possible.

Re: [PATCH 3/5] ARM: dts: Add basic support for EcoNet EN7523

[Marc Zyngier]

On Sun, 01 Aug 2021 10:07:48 +0100,
Bert Vermeulen <bert@biot.com> wrote:
> 
> On 7/30/21 4:53 PM, Marc Zyngier wrote:
> > On Fri, 30 Jul 2021 15:31:36 +0100,
> > Linus Walleij <linus.walleij@linaro.org> wrote:
> >> 
> >> Paging Marc Z and Catalin just so they can see this:
> >> 
> >> On Fri, Jul 30, 2021 at 3:49 PM Bert Vermeulen <bert@biot.com> wrote:
> >> 
> >> > From: John Crispin <john@phrozen.org>
> >> >
> >> > Add basic support for EcoNet EN7523, enough for booting to console.
> >> >
> >> > The UART is basically 8250-compatible, except for the clock selection.
> >> > A clock-frequency value is synthesized to get this to run at 115200 bps.
> >> >
> >> > Signed-off-by: John Crispin <john@phrozen.org>
> >> > Signed-off-by: Bert Vermeulen <bert@biot.com>
> >> (...)
> >> > +       gic: interrupt-controller@09000000 {
> >> > +               compatible = "arm,gic-v3";
> >> > +               interrupt-controller;
> >> > +               #interrupt-cells = <3>;
> >> > +               #address-cells = <1>;
> >> > +               #size-cells = <1>;
> >> > +               reg = <0x09000000 0x20000>,
> >> > +                         <0x09080000 0x80000>;
> >> > +               interrupts = <GIC_PPI 9 IRQ_TYPE_LEVEL_LOW>;
> >> > +
> >> > +               its: gic-its@09020000 {
> >> > +                       compatible = "arm,gic-v3-its";
> >> > +                       msi-controller;
> >> > +                       #msi-cell = <1>;
> >> > +                       reg = <0x090200000 0x20000>;
> >> > +               };
> >> > +       };
> >> 
> >> Yup GICv3 on ARM32-only silicon.
> > 
> > Hey, why not. But that's very unlikely, as Cortex-A7 doesn't have a
> > GICv3 CPU interface built in (it only has the memory mapped version),
> > and A53/57 were the first CPUs to ever support GICv3. I don't believe
> > the description of the CPU in the DT is accurate.
> > 
> > Bert, please send a kernel boot log.
> 
> At the bottom of this mail.
> 
> >> > +       timer {
> >> > +               compatible = "arm,armv8-timer";
> >> > +               interrupt-parent = <&gic>;
> >> > +               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)>;
> > 
> > Copy paste bug. These are not valid intspecs for GICv3.
> 
> FWIW all these were taken verbatim from the vendor's SDK. Not that
> this makes them necessarily correct :)

Please, never copy anything verbatim from an existing DT, specially
not a vendor pile of crap.

Most integrators only cherry-picking DT random fragments without
trying to understand what they imply, beat them together until there
is a sign of life, and end-up with a monster that bears no resemblance
with reality.

Take an existing DT as a hint of what *could* be there, and work out
from first principles what actually makes sense. Yes, it is a lot of
work and involves reading specs, TRMs and whatnot. But at least it
will be correct, which is the standard that upstream is supposed to
uphold.

A shining example is what is below:

> 
> >> > +               clock-frequency = <25000000>;
> >> > +       };
> >> 
> >> Also arm,armv8-timer on ARM32-only silicon.
> > 
> > Probably because that's not what it actually is. My bet is on A53 with
> > a crippled firmware.
> 
> kernel boot log:
> 
> [    0.000000] Booting Linux on physical CPU 0x0
> [    0.000000] Linux version 5.14.0-rc3-00042-g3af70c6f8e95-dirty
> (bert@sumner) (arm-linux-gnueabi-gcc (Ubuntu 9.3.0-17ubuntu1~20.04)
> 9.3.0, GNU ld (GNU Binutils for Ubuntu) 2.34) #392 SMP Sun Aug 1
> 10:28:13 CEST 2021
> [    0.000000] CPU: ARMv7 Processor [410fd034] revision 4 (ARMv7), cr=10c5383d

As expected: 410fd034 = Cortex-A53 r0p4. Pretty far from a Cortex-A7,
isn't it?

> [    0.000000] CPU: div instructions available: patching division code
> [    0.000000] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing
> instruction cache
> [    0.000000] OF: fdt: Machine model: econet,en7523
> [    0.000000] earlycon: uart8250 at MMIO32 0x1fbf0000 (options '')
> [    0.000000] printk: bootconsole [uart8250] enabled
> [    0.000000] Memory policy: Data cache writealloc
> [    0.000000] Zone ranges:
> [    0.000000]   Normal   [mem 0x0000000080000000-0x000000009fffffff]
> [    0.000000]   HighMem  empty
> [    0.000000] Movable zone start for each node
> [    0.000000] Early memory node ranges
> [    0.000000]   node   0: [mem 0x0000000080000000-0x0000000083ffffff]
> [    0.000000]   node   0: [mem 0x0000000084000000-0x00000000849fffff]
> [    0.000000]   node   0: [mem 0x0000000084a00000-0x0000000084afffff]
> [    0.000000]   node   0: [mem 0x0000000084b00000-0x0000000084bfffff]
> [    0.000000]   node   0: [mem 0x0000000084c00000-0x0000000084ffffff]
> [    0.000000]   node   0: [mem 0x0000000085000000-0x00000000869fffff]
> [    0.000000]   node   0: [mem 0x0000000086a00000-0x0000000086afffff]
> [    0.000000]   node   0: [mem 0x0000000086b00000-0x0000000086bfffff]
> [    0.000000]   node   0: [mem 0x0000000086c00000-0x0000000086cfffff]
> [    0.000000]   node   0: [mem 0x0000000086d00000-0x0000000086dfffff]
> [    0.000000]   node   0: [mem 0x0000000086e00000-0x000000009fffffff]
> [    0.000000] Initmem setup node 0 [mem 0x0000000080000000-0x000000009fffffff]
> [    0.000000] percpu: Embedded 15 pages/cpu s30604 r8192 d22644 u61440
> [    0.000000] Built 1 zonelists, mobility grouping on.  Total pages: 129920
> [    0.000000] Kernel command line:
> earlycon=uart8250,mmio32,0x1fbf0000 console=ttyS0,115200
> [    0.000000] Dentry cache hash table entries: 65536 (order: 6,
> 262144 bytes, linear)
> [    0.000000] Inode-cache hash table entries: 32768 (order: 5, 131072
> bytes, linear)
> [    0.000000] mem auto-init: stack:off, heap alloc:off, heap free:off
> [    0.000000] Memory: 461316K/524288K available (7168K kernel code,
> 312K rwdata, 1488K rodata, 8192K init, 142K bss, 62972K reserved, 0K
> cma-reserved, 0K highmem)
> [    0.000000] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=2, Nodes=1
> [    0.000000] rcu: Hierarchical RCU implementation.
> [    0.000000] rcu: RCU calculated value of scheduler-enlistment delay
> is 10 jiffies.
> [    0.000000] NR_IRQS: 16, nr_irqs: 16, preallocated irqs: 16
> [    0.000000] GICv3: 256 SPIs implemented
> [    0.000000] GICv3: 0 Extended SPIs implemented
> [    0.000000] GICv3: Distributor has no Range Selector support
> [    0.000000] GICv3: 16 PPIs implemented
> [    0.000000] GICv3: CPU0: found redistributor 0 region 0:0x09080000

Interestingly, we don't program the property/pending tables for the
RD. Which means this SoC doesn't support LPIs, and thus *does not*
have an ITS, despite what you advertise.

> [    0.000000] random: get_random_bytes called from
> start_kernel+0x484/0x628 with crng_init=0
> [    0.000000] arch_timer: cp15 timer(s) running at 25.00MHz (virt).
> [    0.000000] clocksource: arch_sys_counter: mask: 0xffffffffffffff
> max_cycles: 0x5c40939b5, max_idle_ns: 440795202646 ns
> [    0.000000] sched_clock: 56 bits at 25MHz, resolution 40ns, wraps
> every 4398046511100ns
> [    0.008791] Switching to timer-based delay loop, resolution 40ns
> [    0.015454] Calibrating delay loop (skipped), value calculated
> using timer frequency.. 50.00 BogoMIPS (lpj=250000)
> [    0.026833] pid_max: default: 32768 minimum: 301
> [    0.032013] Mount-cache hash table entries: 1024 (order: 0, 4096
> bytes, linear)
> [    0.040047] Mountpoint-cache hash table entries: 1024 (order: 0,
> 4096 bytes, linear)
> [    0.049172] CPU: Testing write buffer coherency: ok
> [    0.054780] CPU0: thread -1, cpu 0, socket 0, mpidr 80000000
> [    0.061362] Setting up static identity map for 0x80100000 - 0x80100060
> [    0.068667] rcu: Hierarchical SRCU implementation.
> [    0.074290] gic-its@09020000: unable to locate ITS domain

Confirmed. No LPI support, no ITS.

	M.

-- 
Without deviation from the norm, progress is not possible.

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH 3/5] ARM: dts: Add basic support for EcoNet EN7523

[Daniel Palmer]

Hi Bert,

On Fri, 30 Jul 2021 at 22:53, Bert Vermeulen <bert@biot.com> wrote:
> +
> +               cpu0: cpu@0 {
> +                       device_type = "cpu";
> +                       compatible = "arm,cortex-a7";
> +                       reg = <0x0>;
> +                       enable-method = "psci";
> +                       clock-frequency = <80000000>;
> +                       next-level-cache = <&L2_0>;
> +
> +               };

Super nit but looks like an empty line snuck in here.

Cheers,

Daniel

Re: [PATCH 3/5] ARM: dts: Add basic support for EcoNet EN7523

[Daniel Palmer]

Hi Bert,

On Fri, 30 Jul 2021 at 22:53, Bert Vermeulen <bert@biot.com> wrote:
> +
> +               cpu0: cpu@0 {
> +                       device_type = "cpu";
> +                       compatible = "arm,cortex-a7";
> +                       reg = <0x0>;
> +                       enable-method = "psci";
> +                       clock-frequency = <80000000>;
> +                       next-level-cache = <&L2_0>;
> +
> +               };

Super nit but looks like an empty line snuck in here.

Cheers,

Daniel

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH 3/5] ARM: dts: Add basic support for EcoNet EN7523

[Daniel Palmer]

Hi Bert,

On Fri, 30 Jul 2021 at 22:53, Bert Vermeulen <bert@biot.com> wrote:
> +
> +               cpu0: cpu@0 {
> +                       device_type = "cpu";
> +                       compatible = "arm,cortex-a7";
> +                       reg = <0x0>;
> +                       enable-method = "psci";
> +                       clock-frequency = <80000000>;
> +                       next-level-cache = <&L2_0>;
> +
> +               };

Super nit but looks like an empty line snuck in here.

Cheers,

Daniel

Re: [PATCH 3/5] ARM: dts: Add basic support for EcoNet EN7523

[Mark Rutland]

On Fri, Jul 30, 2021 at 03:45:50PM +0200, Bert Vermeulen wrote:
> From: John Crispin <john@phrozen.org>
> 
> Add basic support for EcoNet EN7523, enough for booting to console.
> 
> The UART is basically 8250-compatible, except for the clock selection.
> A clock-frequency value is synthesized to get this to run at 115200 bps.
> 
> Signed-off-by: John Crispin <john@phrozen.org>
> Signed-off-by: Bert Vermeulen <bert@biot.com>
> ---
>  arch/arm/boot/dts/Makefile       |   2 +
>  arch/arm/boot/dts/en7523-evb.dts |  17 ++++
>  arch/arm/boot/dts/en7523.dtsi    | 128 +++++++++++++++++++++++++++++++
>  3 files changed, 147 insertions(+)
>  create mode 100644 arch/arm/boot/dts/en7523-evb.dts
>  create mode 100644 arch/arm/boot/dts/en7523.dtsi

[...]

> +	gic: interrupt-controller@09000000 {
> +		compatible = "arm,gic-v3";
> +		interrupt-controller;
> +		#interrupt-cells = <3>;
> +		#address-cells = <1>;
> +		#size-cells = <1>;
> +		reg = <0x09000000 0x20000>,
> +			  <0x09080000 0x80000>;
> +		interrupts = <GIC_PPI 9 IRQ_TYPE_LEVEL_LOW>;
> +
> +		its: gic-its@09020000 {
> +			compatible = "arm,gic-v3-its";
> +			msi-controller;
> +			#msi-cell = <1>;
> +			reg = <0x090200000 0x20000>;
> +		};
> +	};
> +
> +	timer {
> +		compatible = "arm,armv8-timer";

This should be "arm,armv7-timer".

> +		interrupt-parent = <&gic>;
> +		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)>;

GICv3 doesn't have a cpumask in its PPI description, so the
GIC_CPU_MASK_SIMPLE() bits should be removed.

> +		clock-frequency = <25000000>;

Please have your FW configure CNTFRQ on each CPU; the clock-frequency
property in the DT is a workaround for broken FW, and it's *vastly*
preferable for FW to configure this correctly (e.g. as it means VMs
should "just work").

Thanks,
Mark.

Re: [PATCH 3/5] ARM: dts: Add basic support for EcoNet EN7523

[Mark Rutland]

On Fri, Jul 30, 2021 at 03:45:50PM +0200, Bert Vermeulen wrote:
> From: John Crispin <john@phrozen.org>
> 
> Add basic support for EcoNet EN7523, enough for booting to console.
> 
> The UART is basically 8250-compatible, except for the clock selection.
> A clock-frequency value is synthesized to get this to run at 115200 bps.
> 
> Signed-off-by: John Crispin <john@phrozen.org>
> Signed-off-by: Bert Vermeulen <bert@biot.com>
> ---
>  arch/arm/boot/dts/Makefile       |   2 +
>  arch/arm/boot/dts/en7523-evb.dts |  17 ++++
>  arch/arm/boot/dts/en7523.dtsi    | 128 +++++++++++++++++++++++++++++++
>  3 files changed, 147 insertions(+)
>  create mode 100644 arch/arm/boot/dts/en7523-evb.dts
>  create mode 100644 arch/arm/boot/dts/en7523.dtsi

[...]

> +	gic: interrupt-controller@09000000 {
> +		compatible = "arm,gic-v3";
> +		interrupt-controller;
> +		#interrupt-cells = <3>;
> +		#address-cells = <1>;
> +		#size-cells = <1>;
> +		reg = <0x09000000 0x20000>,
> +			  <0x09080000 0x80000>;
> +		interrupts = <GIC_PPI 9 IRQ_TYPE_LEVEL_LOW>;
> +
> +		its: gic-its@09020000 {
> +			compatible = "arm,gic-v3-its";
> +			msi-controller;
> +			#msi-cell = <1>;
> +			reg = <0x090200000 0x20000>;
> +		};
> +	};
> +
> +	timer {
> +		compatible = "arm,armv8-timer";

This should be "arm,armv7-timer".

> +		interrupt-parent = <&gic>;
> +		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)>;

GICv3 doesn't have a cpumask in its PPI description, so the
GIC_CPU_MASK_SIMPLE() bits should be removed.

> +		clock-frequency = <25000000>;

Please have your FW configure CNTFRQ on each CPU; the clock-frequency
property in the DT is a workaround for broken FW, and it's *vastly*
preferable for FW to configure this correctly (e.g. as it means VMs
should "just work").

Thanks,
Mark.

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH 3/5] ARM: dts: Add basic support for EcoNet EN7523

[Bert Vermeulen]

On 7/30/21 4:46 PM, Mark Rutland wrote:
> On Fri, Jul 30, 2021 at 03:45:50PM +0200, Bert Vermeulen wrote:
>> +	timer {
>> +		compatible = "arm,armv8-timer";
> 
> This should be "arm,armv7-timer".
> 
>> +		interrupt-parent = <&gic>;
>> +		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)>;
> 
> GICv3 doesn't have a cpumask in its PPI description, so the
> GIC_CPU_MASK_SIMPLE() bits should be removed.

Ok, will fix.

>> +		clock-frequency = <25000000>;
> 
> Please have your FW configure CNTFRQ on each CPU; the clock-frequency
> property in the DT is a workaround for broken FW, and it's *vastly*
> preferable for FW to configure this correctly (e.g. as it means VMs
> should "just work").

I've since got hold of the modified U-Boot that runs on my eval board, and 
indeed it doesn't set CNTFRQ. So the kernel does need this, for the moment.

I may get a chance to upstream support for this SoC in U-Boot, but I can't 
control what people are going to ship with their board. Is it ok to leave 
this in?


-- 
Bert Vermeulen
bert@biot.com

Re: [PATCH 3/5] ARM: dts: Add basic support for EcoNet EN7523

[Bert Vermeulen]

On 7/30/21 4:46 PM, Mark Rutland wrote:
> On Fri, Jul 30, 2021 at 03:45:50PM +0200, Bert Vermeulen wrote:
>> +	timer {
>> +		compatible = "arm,armv8-timer";
> 
> This should be "arm,armv7-timer".
> 
>> +		interrupt-parent = <&gic>;
>> +		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)>;
> 
> GICv3 doesn't have a cpumask in its PPI description, so the
> GIC_CPU_MASK_SIMPLE() bits should be removed.

Ok, will fix.

>> +		clock-frequency = <25000000>;
> 
> Please have your FW configure CNTFRQ on each CPU; the clock-frequency
> property in the DT is a workaround for broken FW, and it's *vastly*
> preferable for FW to configure this correctly (e.g. as it means VMs
> should "just work").

I've since got hold of the modified U-Boot that runs on my eval board, and 
indeed it doesn't set CNTFRQ. So the kernel does need this, for the moment.

I may get a chance to upstream support for this SoC in U-Boot, but I can't 
control what people are going to ship with their board. Is it ok to leave 
this in?


-- 
Bert Vermeulen
bert@biot.com

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH 3/5] ARM: dts: Add basic support for EcoNet EN7523

[Rob Herring]

On Wed, Aug 04, 2021 at 06:41:55PM +0200, Bert Vermeulen wrote:
> On 7/30/21 4:46 PM, Mark Rutland wrote:
> > On Fri, Jul 30, 2021 at 03:45:50PM +0200, Bert Vermeulen wrote:
> > > +	timer {
> > > +		compatible = "arm,armv8-timer";
> > 
> > This should be "arm,armv7-timer".
> > 
> > > +		interrupt-parent = <&gic>;
> > > +		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)>;
> > 
> > GICv3 doesn't have a cpumask in its PPI description, so the
> > GIC_CPU_MASK_SIMPLE() bits should be removed.
> 
> Ok, will fix.
> 
> > > +		clock-frequency = <25000000>;
> > 
> > Please have your FW configure CNTFRQ on each CPU; the clock-frequency
> > property in the DT is a workaround for broken FW, and it's *vastly*
> > preferable for FW to configure this correctly (e.g. as it means VMs
> > should "just work").
> 
> I've since got hold of the modified U-Boot that runs on my eval board, and
> indeed it doesn't set CNTFRQ. So the kernel does need this, for the moment.

Can't you write CNTFRQ in the u-boot shell/script?

> I may get a chance to upstream support for this SoC in U-Boot, but I can't
> control what people are going to ship with their board. Is it ok to leave
> this in?

If they want a working upstream Linux, then you can control it.

I seem to recall this being rejected in other cases. That may have been 
on v8 which has taken stricter stances (but arguably any new v7 stuff 
should too).

Rob

Re: [PATCH 3/5] ARM: dts: Add basic support for EcoNet EN7523

[Rob Herring]

On Wed, Aug 04, 2021 at 06:41:55PM +0200, Bert Vermeulen wrote:
> On 7/30/21 4:46 PM, Mark Rutland wrote:
> > On Fri, Jul 30, 2021 at 03:45:50PM +0200, Bert Vermeulen wrote:
> > > +	timer {
> > > +		compatible = "arm,armv8-timer";
> > 
> > This should be "arm,armv7-timer".
> > 
> > > +		interrupt-parent = <&gic>;
> > > +		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)>;
> > 
> > GICv3 doesn't have a cpumask in its PPI description, so the
> > GIC_CPU_MASK_SIMPLE() bits should be removed.
> 
> Ok, will fix.
> 
> > > +		clock-frequency = <25000000>;
> > 
> > Please have your FW configure CNTFRQ on each CPU; the clock-frequency
> > property in the DT is a workaround for broken FW, and it's *vastly*
> > preferable for FW to configure this correctly (e.g. as it means VMs
> > should "just work").
> 
> I've since got hold of the modified U-Boot that runs on my eval board, and
> indeed it doesn't set CNTFRQ. So the kernel does need this, for the moment.

Can't you write CNTFRQ in the u-boot shell/script?

> I may get a chance to upstream support for this SoC in U-Boot, but I can't
> control what people are going to ship with their board. Is it ok to leave
> this in?

If they want a working upstream Linux, then you can control it.

I seem to recall this being rejected in other cases. That may have been 
on v8 which has taken stricter stances (but arguably any new v7 stuff 
should too).

Rob

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH 3/5] ARM: dts: Add basic support for EcoNet EN7523

[Mark Rutland]

On Fri, Jul 30, 2021 at 03:45:50PM +0200, Bert Vermeulen wrote:
> From: John Crispin <john@phrozen.org>
> 
> Add basic support for EcoNet EN7523, enough for booting to console.
> 
> The UART is basically 8250-compatible, except for the clock selection.
> A clock-frequency value is synthesized to get this to run at 115200 bps.
> 
> Signed-off-by: John Crispin <john@phrozen.org>
> Signed-off-by: Bert Vermeulen <bert@biot.com>
> ---
>  arch/arm/boot/dts/Makefile       |   2 +
>  arch/arm/boot/dts/en7523-evb.dts |  17 ++++
>  arch/arm/boot/dts/en7523.dtsi    | 128 +++++++++++++++++++++++++++++++
>  3 files changed, 147 insertions(+)
>  create mode 100644 arch/arm/boot/dts/en7523-evb.dts
>  create mode 100644 arch/arm/boot/dts/en7523.dtsi
> 

> +	cpus {
> +		#address-cells = <1>;
> +		#size-cells = <0>;

> +		cpu0: cpu@0 {
> +			device_type = "cpu";
> +			compatible = "arm,cortex-a7";
> +			reg = <0x0>;
> +			enable-method = "psci";
> +			clock-frequency = <80000000>;
> +			next-level-cache = <&L2_0>;
> +
> +		};

> +	gic: interrupt-controller@09000000 {
> +		compatible = "arm,gic-v3";
> +		interrupt-controller;
> +		#interrupt-cells = <3>;
> +		#address-cells = <1>;
> +		#size-cells = <1>;
> +		reg = <0x09000000 0x20000>,
> +			  <0x09080000 0x80000>;
> +		interrupts = <GIC_PPI 9 IRQ_TYPE_LEVEL_LOW>;
> +
> +		its: gic-its@09020000 {
> +			compatible = "arm,gic-v3-its";
> +			msi-controller;
> +			#msi-cell = <1>;

Missing 's' here for '#msi-cells'.

> +			reg = <0x090200000 0x20000>;
> +		};
> +	};

Looking at this again, I was under the impression that Cortex-A7 only
supported GICv2; is this actually a Cortex-A7 or a different CPU?

Which revision is this?

Thanks,
Mark.

Re: [PATCH 3/5] ARM: dts: Add basic support for EcoNet EN7523

[Mark Rutland]

On Fri, Jul 30, 2021 at 03:45:50PM +0200, Bert Vermeulen wrote:
> From: John Crispin <john@phrozen.org>
> 
> Add basic support for EcoNet EN7523, enough for booting to console.
> 
> The UART is basically 8250-compatible, except for the clock selection.
> A clock-frequency value is synthesized to get this to run at 115200 bps.
> 
> Signed-off-by: John Crispin <john@phrozen.org>
> Signed-off-by: Bert Vermeulen <bert@biot.com>
> ---
>  arch/arm/boot/dts/Makefile       |   2 +
>  arch/arm/boot/dts/en7523-evb.dts |  17 ++++
>  arch/arm/boot/dts/en7523.dtsi    | 128 +++++++++++++++++++++++++++++++
>  3 files changed, 147 insertions(+)
>  create mode 100644 arch/arm/boot/dts/en7523-evb.dts
>  create mode 100644 arch/arm/boot/dts/en7523.dtsi
> 

> +	cpus {
> +		#address-cells = <1>;
> +		#size-cells = <0>;

> +		cpu0: cpu@0 {
> +			device_type = "cpu";
> +			compatible = "arm,cortex-a7";
> +			reg = <0x0>;
> +			enable-method = "psci";
> +			clock-frequency = <80000000>;
> +			next-level-cache = <&L2_0>;
> +
> +		};

> +	gic: interrupt-controller@09000000 {
> +		compatible = "arm,gic-v3";
> +		interrupt-controller;
> +		#interrupt-cells = <3>;
> +		#address-cells = <1>;
> +		#size-cells = <1>;
> +		reg = <0x09000000 0x20000>,
> +			  <0x09080000 0x80000>;
> +		interrupts = <GIC_PPI 9 IRQ_TYPE_LEVEL_LOW>;
> +
> +		its: gic-its@09020000 {
> +			compatible = "arm,gic-v3-its";
> +			msi-controller;
> +			#msi-cell = <1>;

Missing 's' here for '#msi-cells'.

> +			reg = <0x090200000 0x20000>;
> +		};
> +	};

Looking at this again, I was under the impression that Cortex-A7 only
supported GICv2; is this actually a Cortex-A7 or a different CPU?

Which revision is this?

Thanks,
Mark.

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH 3/5] ARM: dts: Add basic support for EcoNet EN7523

[Rob Herring]

On Fri, Jul 30, 2021 at 03:59:01PM +0100, Mark Rutland wrote:
> On Fri, Jul 30, 2021 at 03:45:50PM +0200, Bert Vermeulen wrote:
> > From: John Crispin <john@phrozen.org>
> > 
> > Add basic support for EcoNet EN7523, enough for booting to console.
> > 
> > The UART is basically 8250-compatible, except for the clock selection.
> > A clock-frequency value is synthesized to get this to run at 115200 bps.
> > 
> > Signed-off-by: John Crispin <john@phrozen.org>
> > Signed-off-by: Bert Vermeulen <bert@biot.com>
> > ---
> >  arch/arm/boot/dts/Makefile       |   2 +
> >  arch/arm/boot/dts/en7523-evb.dts |  17 ++++
> >  arch/arm/boot/dts/en7523.dtsi    | 128 +++++++++++++++++++++++++++++++
> >  3 files changed, 147 insertions(+)
> >  create mode 100644 arch/arm/boot/dts/en7523-evb.dts
> >  create mode 100644 arch/arm/boot/dts/en7523.dtsi
> > 
> 
> > +	cpus {
> > +		#address-cells = <1>;
> > +		#size-cells = <0>;
> 
> > +		cpu0: cpu@0 {
> > +			device_type = "cpu";
> > +			compatible = "arm,cortex-a7";
> > +			reg = <0x0>;
> > +			enable-method = "psci";
> > +			clock-frequency = <80000000>;
> > +			next-level-cache = <&L2_0>;
> > +
> > +		};
> 
> > +	gic: interrupt-controller@09000000 {
> > +		compatible = "arm,gic-v3";
> > +		interrupt-controller;
> > +		#interrupt-cells = <3>;
> > +		#address-cells = <1>;
> > +		#size-cells = <1>;
> > +		reg = <0x09000000 0x20000>,
> > +			  <0x09080000 0x80000>;
> > +		interrupts = <GIC_PPI 9 IRQ_TYPE_LEVEL_LOW>;
> > +
> > +		its: gic-its@09020000 {
> > +			compatible = "arm,gic-v3-its";
> > +			msi-controller;
> > +			#msi-cell = <1>;
> 
> Missing 's' here for '#msi-cells'.

No need for a human to be checking this, the DT schemas will check this. 
Please run 'make dtbs_checks' on this. New platforms should be free of 
warnings ideally.

Rob

Re: [PATCH 3/5] ARM: dts: Add basic support for EcoNet EN7523

[Rob Herring]

On Fri, Jul 30, 2021 at 03:59:01PM +0100, Mark Rutland wrote:
> On Fri, Jul 30, 2021 at 03:45:50PM +0200, Bert Vermeulen wrote:
> > From: John Crispin <john@phrozen.org>
> > 
> > Add basic support for EcoNet EN7523, enough for booting to console.
> > 
> > The UART is basically 8250-compatible, except for the clock selection.
> > A clock-frequency value is synthesized to get this to run at 115200 bps.
> > 
> > Signed-off-by: John Crispin <john@phrozen.org>
> > Signed-off-by: Bert Vermeulen <bert@biot.com>
> > ---
> >  arch/arm/boot/dts/Makefile       |   2 +
> >  arch/arm/boot/dts/en7523-evb.dts |  17 ++++
> >  arch/arm/boot/dts/en7523.dtsi    | 128 +++++++++++++++++++++++++++++++
> >  3 files changed, 147 insertions(+)
> >  create mode 100644 arch/arm/boot/dts/en7523-evb.dts
> >  create mode 100644 arch/arm/boot/dts/en7523.dtsi
> > 
> 
> > +	cpus {
> > +		#address-cells = <1>;
> > +		#size-cells = <0>;
> 
> > +		cpu0: cpu@0 {
> > +			device_type = "cpu";
> > +			compatible = "arm,cortex-a7";
> > +			reg = <0x0>;
> > +			enable-method = "psci";
> > +			clock-frequency = <80000000>;
> > +			next-level-cache = <&L2_0>;
> > +
> > +		};
> 
> > +	gic: interrupt-controller@09000000 {
> > +		compatible = "arm,gic-v3";
> > +		interrupt-controller;
> > +		#interrupt-cells = <3>;
> > +		#address-cells = <1>;
> > +		#size-cells = <1>;
> > +		reg = <0x09000000 0x20000>,
> > +			  <0x09080000 0x80000>;
> > +		interrupts = <GIC_PPI 9 IRQ_TYPE_LEVEL_LOW>;
> > +
> > +		its: gic-its@09020000 {
> > +			compatible = "arm,gic-v3-its";
> > +			msi-controller;
> > +			#msi-cell = <1>;
> 
> Missing 's' here for '#msi-cells'.

No need for a human to be checking this, the DT schemas will check this. 
Please run 'make dtbs_checks' on this. New platforms should be free of 
warnings ideally.

Rob

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH 3/5] ARM: dts: Add basic support for EcoNet EN7523

[Andre Przywara]

On Fri, 30 Jul 2021 15:45:50 +0200
Bert Vermeulen <bert@biot.com> wrote:

Hi,

> From: John Crispin <john@phrozen.org>
> 
> Add basic support for EcoNet EN7523, enough for booting to console.
> 
> The UART is basically 8250-compatible, except for the clock selection.
> A clock-frequency value is synthesized to get this to run at 115200 bps.
> 
> Signed-off-by: John Crispin <john@phrozen.org>
> Signed-off-by: Bert Vermeulen <bert@biot.com>
> ---
>  arch/arm/boot/dts/Makefile       |   2 +
>  arch/arm/boot/dts/en7523-evb.dts |  17 ++++
>  arch/arm/boot/dts/en7523.dtsi    | 128 +++++++++++++++++++++++++++++++
>  3 files changed, 147 insertions(+)
>  create mode 100644 arch/arm/boot/dts/en7523-evb.dts
>  create mode 100644 arch/arm/boot/dts/en7523.dtsi
> 
> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
> index 863347b6b65e..3eeb7715c6ce 100644
> --- a/arch/arm/boot/dts/Makefile
> +++ b/arch/arm/boot/dts/Makefile
> @@ -174,6 +174,8 @@ dtb-$(CONFIG_ARCH_DAVINCI) += \
>  	da850-lego-ev3.dtb
>  dtb-$(CONFIG_ARCH_DIGICOLOR) += \
>  	cx92755_equinox.dtb
> +dtb-$(CONFIG_ARCH_ECONET) += \
> +	en7523-evb.dtb
>  dtb-$(CONFIG_ARCH_EXYNOS3) += \
>  	exynos3250-artik5-eval.dtb \
>  	exynos3250-monk.dtb \
> diff --git a/arch/arm/boot/dts/en7523-evb.dts b/arch/arm/boot/dts/en7523-evb.dts
> new file mode 100644
> index 000000000000..c5b75eb3715e
> --- /dev/null
> +++ b/arch/arm/boot/dts/en7523-evb.dts
> @@ -0,0 +1,17 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/dts-v1/;
> +#include "en7523.dtsi"
> +
> +/ {
> +	model = "Econet EN7523 Evaluation Board";
> +	compatible = "econet,en7523-evb", "econet,en7523";
> +
> +	aliases {
> +		serial0 = &uart1;
> +	};
> +
> +	chosen {
> +		bootargs = "earlycon=uart8250,mmio32,0x1fbf0000 console=ttyS0,115200";
> +		stdout-path = "serial0:115200n8";
> +	};
> +};
> diff --git a/arch/arm/boot/dts/en7523.dtsi b/arch/arm/boot/dts/en7523.dtsi
> new file mode 100644
> index 000000000000..f4fe1c6f66e8
> --- /dev/null
> +++ b/arch/arm/boot/dts/en7523.dtsi
> @@ -0,0 +1,128 @@
> +// SPDX-License-Identifier: GPL-2.0
> +
> +#include <dt-bindings/interrupt-controller/irq.h>
> +#include <dt-bindings/interrupt-controller/arm-gic.h>
> +
> +/ {
> +	interrupt-parent = <&gic>;
> +	#address-cells = <1>;
> +	#size-cells = <1>;
> +
> +	reserved-memory {
> +		#address-cells = <1>;
> +		#size-cells = <1>;
> +		ranges;
> +
> +		npu_binary@84000000 {
> +			no-map;
> +			reg = <0x84000000 0xA00000>;
> +		};
> +
> +		npu_flag@84B0000 {
> +			no-map;
> +			reg = <0x84B00000 0x100000>;
> +		};
> +
> +		npu_pkt@85000000 {
> +			no-map;
> +			reg = <0x85000000 0x1A00000>;
> +		};
> +
> +		npu_phyaddr@86B00000 {
> +			no-map;
> +			reg = <0x86B00000 0x100000>;
> +		};
> +
> +		npu_rxdesc@86D00000 {
> +			no-map;
> +			reg = <0x86D00000 0x100000>;
> +		};
> +	};
> +
> +	psci {
> +		compatible = "arm,psci-0.2";
> +		method = "smc";
> +	};
> +
> +	cpus {
> +		#address-cells = <1>;
> +		#size-cells = <0>;
> +
> +		cpu-map {
> +			cluster0 {
> +				core0 {
> +					cpu = <&cpu0>;
> +				};
> +				core1 {
> +					cpu = <&cpu1>;
> +				};
> +			};
> +		};
> +
> +		cpu0: cpu@0 {
> +			device_type = "cpu";
> +			compatible = "arm,cortex-a7";
> +			reg = <0x0>;
> +			enable-method = "psci";
> +			clock-frequency = <80000000>;
> +			next-level-cache = <&L2_0>;
> +
> +		};
> +
> +		cpu1: cpu@1 {
> +			device_type = "cpu";
> +			compatible = "arm,cortex-a7";
> +			reg = <0x1>;
> +			enable-method = "psci";
> +			clock-frequency = <80000000>;
> +			next-level-cache = <&L2_0>;
> +		};
> +
> +		L2_0: l2-cache0 {
> +			compatible = "cache";
> +		};
> +	};
> +
> +	gic: interrupt-controller@09000000 {

Please no leading zeros behind the '@', dtc should warn about this.

> +		compatible = "arm,gic-v3";
> +		interrupt-controller;
> +		#interrupt-cells = <3>;
> +		#address-cells = <1>;
> +		#size-cells = <1>;
> +		reg = <0x09000000 0x20000>,

Mmh, 128K for the distributor, is that actually right? Is that to cover
some GIC-500 MBI aliases? I don't think we announce this in the DT,
though?

> +			  <0x09080000 0x80000>;

So this offset and length suggests there are four cores? Is that a
mistake or are there two more cores, that are possibly hidden? 

> +		interrupts = <GIC_PPI 9 IRQ_TYPE_LEVEL_LOW>;
> +
> +		its: gic-its@09020000 {

Another leading zero.

Cheers,
Andre


> +			compatible = "arm,gic-v3-its";
> +			msi-controller;
> +			#msi-cell = <1>;
> +			reg = <0x090200000 0x20000>;
> +		};
> +	};
> +
> +	timer {
> +		compatible = "arm,armv8-timer";
> +		interrupt-parent = <&gic>;
> +		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)>;
> +		clock-frequency = <25000000>;
> +	};
> +
> +	memory@80000000 {
> +		device_type = "memory";
> +		reg = <0x80000000 0x40000000>;
> +	};
> +
> +	uart1: serial@1fbf0000 {
> +		compatible = "ns8250";
> +		reg = <0x1fbf0000 0x30>;
> +		reg-io-width = <4>;
> +		reg-shift = <2>;
> +		interrupts = <GIC_SPI 18 IRQ_TYPE_LEVEL_HIGH>;
> +		clock-frequency = <1843200>;
> +		status = "okay";
> +	};
> +};

Re: [PATCH 3/5] ARM: dts: Add basic support for EcoNet EN7523

[Andre Przywara]

On Fri, 30 Jul 2021 15:45:50 +0200
Bert Vermeulen <bert@biot.com> wrote:

Hi,

> From: John Crispin <john@phrozen.org>
> 
> Add basic support for EcoNet EN7523, enough for booting to console.
> 
> The UART is basically 8250-compatible, except for the clock selection.
> A clock-frequency value is synthesized to get this to run at 115200 bps.
> 
> Signed-off-by: John Crispin <john@phrozen.org>
> Signed-off-by: Bert Vermeulen <bert@biot.com>
> ---
>  arch/arm/boot/dts/Makefile       |   2 +
>  arch/arm/boot/dts/en7523-evb.dts |  17 ++++
>  arch/arm/boot/dts/en7523.dtsi    | 128 +++++++++++++++++++++++++++++++
>  3 files changed, 147 insertions(+)
>  create mode 100644 arch/arm/boot/dts/en7523-evb.dts
>  create mode 100644 arch/arm/boot/dts/en7523.dtsi
> 
> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
> index 863347b6b65e..3eeb7715c6ce 100644
> --- a/arch/arm/boot/dts/Makefile
> +++ b/arch/arm/boot/dts/Makefile
> @@ -174,6 +174,8 @@ dtb-$(CONFIG_ARCH_DAVINCI) += \
>  	da850-lego-ev3.dtb
>  dtb-$(CONFIG_ARCH_DIGICOLOR) += \
>  	cx92755_equinox.dtb
> +dtb-$(CONFIG_ARCH_ECONET) += \
> +	en7523-evb.dtb
>  dtb-$(CONFIG_ARCH_EXYNOS3) += \
>  	exynos3250-artik5-eval.dtb \
>  	exynos3250-monk.dtb \
> diff --git a/arch/arm/boot/dts/en7523-evb.dts b/arch/arm/boot/dts/en7523-evb.dts
> new file mode 100644
> index 000000000000..c5b75eb3715e
> --- /dev/null
> +++ b/arch/arm/boot/dts/en7523-evb.dts
> @@ -0,0 +1,17 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/dts-v1/;
> +#include "en7523.dtsi"
> +
> +/ {
> +	model = "Econet EN7523 Evaluation Board";
> +	compatible = "econet,en7523-evb", "econet,en7523";
> +
> +	aliases {
> +		serial0 = &uart1;
> +	};
> +
> +	chosen {
> +		bootargs = "earlycon=uart8250,mmio32,0x1fbf0000 console=ttyS0,115200";
> +		stdout-path = "serial0:115200n8";
> +	};
> +};
> diff --git a/arch/arm/boot/dts/en7523.dtsi b/arch/arm/boot/dts/en7523.dtsi
> new file mode 100644
> index 000000000000..f4fe1c6f66e8
> --- /dev/null
> +++ b/arch/arm/boot/dts/en7523.dtsi
> @@ -0,0 +1,128 @@
> +// SPDX-License-Identifier: GPL-2.0
> +
> +#include <dt-bindings/interrupt-controller/irq.h>
> +#include <dt-bindings/interrupt-controller/arm-gic.h>
> +
> +/ {
> +	interrupt-parent = <&gic>;
> +	#address-cells = <1>;
> +	#size-cells = <1>;
> +
> +	reserved-memory {
> +		#address-cells = <1>;
> +		#size-cells = <1>;
> +		ranges;
> +
> +		npu_binary@84000000 {
> +			no-map;
> +			reg = <0x84000000 0xA00000>;
> +		};
> +
> +		npu_flag@84B0000 {
> +			no-map;
> +			reg = <0x84B00000 0x100000>;
> +		};
> +
> +		npu_pkt@85000000 {
> +			no-map;
> +			reg = <0x85000000 0x1A00000>;
> +		};
> +
> +		npu_phyaddr@86B00000 {
> +			no-map;
> +			reg = <0x86B00000 0x100000>;
> +		};
> +
> +		npu_rxdesc@86D00000 {
> +			no-map;
> +			reg = <0x86D00000 0x100000>;
> +		};
> +	};
> +
> +	psci {
> +		compatible = "arm,psci-0.2";
> +		method = "smc";
> +	};
> +
> +	cpus {
> +		#address-cells = <1>;
> +		#size-cells = <0>;
> +
> +		cpu-map {
> +			cluster0 {
> +				core0 {
> +					cpu = <&cpu0>;
> +				};
> +				core1 {
> +					cpu = <&cpu1>;
> +				};
> +			};
> +		};
> +
> +		cpu0: cpu@0 {
> +			device_type = "cpu";
> +			compatible = "arm,cortex-a7";
> +			reg = <0x0>;
> +			enable-method = "psci";
> +			clock-frequency = <80000000>;
> +			next-level-cache = <&L2_0>;
> +
> +		};
> +
> +		cpu1: cpu@1 {
> +			device_type = "cpu";
> +			compatible = "arm,cortex-a7";
> +			reg = <0x1>;
> +			enable-method = "psci";
> +			clock-frequency = <80000000>;
> +			next-level-cache = <&L2_0>;
> +		};
> +
> +		L2_0: l2-cache0 {
> +			compatible = "cache";
> +		};
> +	};
> +
> +	gic: interrupt-controller@09000000 {

Please no leading zeros behind the '@', dtc should warn about this.

> +		compatible = "arm,gic-v3";
> +		interrupt-controller;
> +		#interrupt-cells = <3>;
> +		#address-cells = <1>;
> +		#size-cells = <1>;
> +		reg = <0x09000000 0x20000>,

Mmh, 128K for the distributor, is that actually right? Is that to cover
some GIC-500 MBI aliases? I don't think we announce this in the DT,
though?

> +			  <0x09080000 0x80000>;

So this offset and length suggests there are four cores? Is that a
mistake or are there two more cores, that are possibly hidden? 

> +		interrupts = <GIC_PPI 9 IRQ_TYPE_LEVEL_LOW>;
> +
> +		its: gic-its@09020000 {

Another leading zero.

Cheers,
Andre


> +			compatible = "arm,gic-v3-its";
> +			msi-controller;
> +			#msi-cell = <1>;
> +			reg = <0x090200000 0x20000>;
> +		};
> +	};
> +
> +	timer {
> +		compatible = "arm,armv8-timer";
> +		interrupt-parent = <&gic>;
> +		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)>;
> +		clock-frequency = <25000000>;
> +	};
> +
> +	memory@80000000 {
> +		device_type = "memory";
> +		reg = <0x80000000 0x40000000>;
> +	};
> +
> +	uart1: serial@1fbf0000 {
> +		compatible = "ns8250";
> +		reg = <0x1fbf0000 0x30>;
> +		reg-io-width = <4>;
> +		reg-shift = <2>;
> +		interrupts = <GIC_SPI 18 IRQ_TYPE_LEVEL_HIGH>;
> +		clock-frequency = <1843200>;
> +		status = "okay";
> +	};
> +};


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH 3/5] ARM: dts: Add basic support for EcoNet EN7523

[Marc Zyngier]

On 2021-07-30 17:47, Andre Przywara wrote:
> On Fri, 30 Jul 2021 15:45:50 +0200
> Bert Vermeulen <bert@biot.com> wrote:
> 
>> +		compatible = "arm,gic-v3";
>> +		interrupt-controller;
>> +		#interrupt-cells = <3>;
>> +		#address-cells = <1>;
>> +		#size-cells = <1>;
>> +		reg = <0x09000000 0x20000>,
> 
> Mmh, 128K for the distributor, is that actually right? Is that to cover
> some GIC-500 MBI aliases? I don't think we announce this in the DT,
> though?

We do, but not this way. There is a documented binding to that effect.

         M.
-- 
Jazz is not dead. It just smells funny...

Re: [PATCH 3/5] ARM: dts: Add basic support for EcoNet EN7523

[Marc Zyngier]

On 2021-07-30 17:47, Andre Przywara wrote:
> On Fri, 30 Jul 2021 15:45:50 +0200
> Bert Vermeulen <bert@biot.com> wrote:
> 
>> +		compatible = "arm,gic-v3";
>> +		interrupt-controller;
>> +		#interrupt-cells = <3>;
>> +		#address-cells = <1>;
>> +		#size-cells = <1>;
>> +		reg = <0x09000000 0x20000>,
> 
> Mmh, 128K for the distributor, is that actually right? Is that to cover
> some GIC-500 MBI aliases? I don't think we announce this in the DT,
> though?

We do, but not this way. There is a documented binding to that effect.

         M.
-- 
Jazz is not dead. It just smells funny...

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH 4/5] ARM: Add basic support for EcoNet EN7523 SoC

[Bert Vermeulen]

From: John Crispin <john@phrozen.org>

EN7523 is an armv7 based silicon used inside broadband access type devices
such as xPON and xDSL. It shares various silicon blocks with MediaTek
silicon such as the MT7622.

Signed-off-by: John Crispin <john@phrozen.org>
Signed-off-by: Bert Vermeulen <bert@biot.com>
---
 arch/arm/Kconfig  | 14 ++++++++++++++
 arch/arm/Makefile |  1 +
 2 files changed, 15 insertions(+)

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 82f908fa5676..e4a9401f8513 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -580,6 +580,20 @@ config ARCH_VIRT
 	select HAVE_ARM_ARCH_TIMER
 	select ARCH_SUPPORTS_BIG_ENDIAN
 
+config ARCH_ECONET
+	bool "Econet SoC Support"
+	depends on ARCH_MULTI_V7
+	select ARM_AMBA
+	select ARM_GIC
+	select ARM_GIC_V3
+	select ARM_DMA_USE_IOMMU
+	select ARM_PSCI
+	select HAVE_ARM_ARCH_TIMER
+	select IOMMU_DMA
+	select COMMON_CLK
+	help
+	  Support for Econet EN7523 SoCs
+
 #
 # This is sorted alphabetically by mach-* pathname.  However, plat-*
 # Kconfigs may be included either alphabetically (according to the
diff --git a/arch/arm/Makefile b/arch/arm/Makefile
index 173da685a52e..1bff0aa29c07 100644
--- a/arch/arm/Makefile
+++ b/arch/arm/Makefile
@@ -152,6 +152,7 @@ textofs-$(CONFIG_ARCH_MSM8X60) := 0x00208000
 textofs-$(CONFIG_ARCH_MSM8960) := 0x00208000
 textofs-$(CONFIG_ARCH_MESON) := 0x00208000
 textofs-$(CONFIG_ARCH_AXXIA) := 0x00308000
+textofs-$(CONFIG_ARCH_ECONET) := 0x00088000
 
 # Machine directory name.  This list is sorted alphanumerically
 # by CONFIG_* macro name.
-- 
2.25.1

[PATCH 4/5] ARM: Add basic support for EcoNet EN7523 SoC

[Bert Vermeulen]

From: John Crispin <john@phrozen.org>

EN7523 is an armv7 based silicon used inside broadband access type devices
such as xPON and xDSL. It shares various silicon blocks with MediaTek
silicon such as the MT7622.

Signed-off-by: John Crispin <john@phrozen.org>
Signed-off-by: Bert Vermeulen <bert@biot.com>
---
 arch/arm/Kconfig  | 14 ++++++++++++++
 arch/arm/Makefile |  1 +
 2 files changed, 15 insertions(+)

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 82f908fa5676..e4a9401f8513 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -580,6 +580,20 @@ config ARCH_VIRT
 	select HAVE_ARM_ARCH_TIMER
 	select ARCH_SUPPORTS_BIG_ENDIAN
 
+config ARCH_ECONET
+	bool "Econet SoC Support"
+	depends on ARCH_MULTI_V7
+	select ARM_AMBA
+	select ARM_GIC
+	select ARM_GIC_V3
+	select ARM_DMA_USE_IOMMU
+	select ARM_PSCI
+	select HAVE_ARM_ARCH_TIMER
+	select IOMMU_DMA
+	select COMMON_CLK
+	help
+	  Support for Econet EN7523 SoCs
+
 #
 # This is sorted alphabetically by mach-* pathname.  However, plat-*
 # Kconfigs may be included either alphabetically (according to the
diff --git a/arch/arm/Makefile b/arch/arm/Makefile
index 173da685a52e..1bff0aa29c07 100644
--- a/arch/arm/Makefile
+++ b/arch/arm/Makefile
@@ -152,6 +152,7 @@ textofs-$(CONFIG_ARCH_MSM8X60) := 0x00208000
 textofs-$(CONFIG_ARCH_MSM8960) := 0x00208000
 textofs-$(CONFIG_ARCH_MESON) := 0x00208000
 textofs-$(CONFIG_ARCH_AXXIA) := 0x00308000
+textofs-$(CONFIG_ARCH_ECONET) := 0x00088000
 
 # Machine directory name.  This list is sorted alphanumerically
 # by CONFIG_* macro name.
-- 
2.25.1


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH 4/5] ARM: Add basic support for EcoNet EN7523 SoC

[Arnd Bergmann]

On Fri, Jul 30, 2021 at 3:45 PM Bert Vermeulen <bert@biot.com> wrote:
>
> From: John Crispin <john@phrozen.org>
>
> EN7523 is an armv7 based silicon used inside broadband access type devices
> such as xPON and xDSL. It shares various silicon blocks with MediaTek
> silicon such as the MT7622.
>
> Signed-off-by: John Crispin <john@phrozen.org>
> Signed-off-by: Bert Vermeulen <bert@biot.com>

It's always nice to see a new SoC family.

> --- a/arch/arm/Kconfig
> +++ b/arch/arm/Kconfig
> @@ -580,6 +580,20 @@ config ARCH_VIRT
>         select HAVE_ARM_ARCH_TIMER
>         select ARCH_SUPPORTS_BIG_ENDIAN
>
> +config ARCH_ECONET
> +       bool "Econet SoC Support"
> +       depends on ARCH_MULTI_V7
> +       select ARM_AMBA
> +       select ARM_GIC
> +       select ARM_GIC_V3
> +       select ARM_DMA_USE_IOMMU
> +       select ARM_PSCI
> +       select HAVE_ARM_ARCH_TIMER
> +       select IOMMU_DMA
> +       select COMMON_CLK
> +       help
> +         Support for Econet EN7523 SoCs

Given how closely related this probably is to MT7623/MT7622, should this
perhaps just be part of arch/arm/mach-mediatek? According to
https://wikidevi.wi-cat.ru/MediaTek#xPON, the older (mips based) MT752x
chips are apparently just rebranded to EN752x after the business unit
was spun off, but I guess they are still in the same family.

> diff --git a/arch/arm/Makefile b/arch/arm/Makefile
> index 173da685a52e..1bff0aa29c07 100644
> --- a/arch/arm/Makefile
> +++ b/arch/arm/Makefile
> @@ -152,6 +152,7 @@ textofs-$(CONFIG_ARCH_MSM8X60) := 0x00208000
>  textofs-$(CONFIG_ARCH_MSM8960) := 0x00208000
>  textofs-$(CONFIG_ARCH_MESON) := 0x00208000
>  textofs-$(CONFIG_ARCH_AXXIA) := 0x00308000
> +textofs-$(CONFIG_ARCH_ECONET) := 0x00088000

Why is this needed?

Note also the comment directly above it exlaining
# Text offset. This list is sorted numerically by address in order to
# provide a means to avoid/resolve conflicts in multi-arch kernels.

       Arnd

Re: [PATCH 4/5] ARM: Add basic support for EcoNet EN7523 SoC

[Arnd Bergmann]

On Fri, Jul 30, 2021 at 3:45 PM Bert Vermeulen <bert@biot.com> wrote:
>
> From: John Crispin <john@phrozen.org>
>
> EN7523 is an armv7 based silicon used inside broadband access type devices
> such as xPON and xDSL. It shares various silicon blocks with MediaTek
> silicon such as the MT7622.
>
> Signed-off-by: John Crispin <john@phrozen.org>
> Signed-off-by: Bert Vermeulen <bert@biot.com>

It's always nice to see a new SoC family.

> --- a/arch/arm/Kconfig
> +++ b/arch/arm/Kconfig
> @@ -580,6 +580,20 @@ config ARCH_VIRT
>         select HAVE_ARM_ARCH_TIMER
>         select ARCH_SUPPORTS_BIG_ENDIAN
>
> +config ARCH_ECONET
> +       bool "Econet SoC Support"
> +       depends on ARCH_MULTI_V7
> +       select ARM_AMBA
> +       select ARM_GIC
> +       select ARM_GIC_V3
> +       select ARM_DMA_USE_IOMMU
> +       select ARM_PSCI
> +       select HAVE_ARM_ARCH_TIMER
> +       select IOMMU_DMA
> +       select COMMON_CLK
> +       help
> +         Support for Econet EN7523 SoCs

Given how closely related this probably is to MT7623/MT7622, should this
perhaps just be part of arch/arm/mach-mediatek? According to
https://wikidevi.wi-cat.ru/MediaTek#xPON, the older (mips based) MT752x
chips are apparently just rebranded to EN752x after the business unit
was spun off, but I guess they are still in the same family.

> diff --git a/arch/arm/Makefile b/arch/arm/Makefile
> index 173da685a52e..1bff0aa29c07 100644
> --- a/arch/arm/Makefile
> +++ b/arch/arm/Makefile
> @@ -152,6 +152,7 @@ textofs-$(CONFIG_ARCH_MSM8X60) := 0x00208000
>  textofs-$(CONFIG_ARCH_MSM8960) := 0x00208000
>  textofs-$(CONFIG_ARCH_MESON) := 0x00208000
>  textofs-$(CONFIG_ARCH_AXXIA) := 0x00308000
> +textofs-$(CONFIG_ARCH_ECONET) := 0x00088000

Why is this needed?

Note also the comment directly above it exlaining
# Text offset. This list is sorted numerically by address in order to
# provide a means to avoid/resolve conflicts in multi-arch kernels.

       Arnd

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH 4/5] ARM: Add basic support for EcoNet EN7523 SoC

[John Crispin]

On 30.07.21 16:48, Arnd Bergmann wrote:
> Given how closely related this probably is to MT7623/MT7622, should this
> perhaps just be part of arch/arm/mach-mediatek? According to
> https://wikidevi.wi-cat.ru/MediaTek#xPON, the older (mips based) MT752x
> chips are apparently just rebranded to EN752x after the business unit
> was spun off, but I guess they are still in the same family.

Hi,

ECNT (what was once known as trendchip) is now a subsidary of MTK (and 
not a BU if I am understanding it correctly).

the EN7523 is rather similar to the MT7622 for some parts, other parts 
(spi, flash, wdt, gpio, .. drivers all needed to be rewritten and will 
be part of the next series).

the older MIPS silicon shares almost no IP with the current ARM silicon.

not really my call to decide which folder this should live in. it seemed 
natural to just give it its own folder, as ECNT is not a BU of MTK.

we can change that however if required.

     John

Re: [PATCH 4/5] ARM: Add basic support for EcoNet EN7523 SoC

[John Crispin]

On 30.07.21 16:48, Arnd Bergmann wrote:
> Given how closely related this probably is to MT7623/MT7622, should this
> perhaps just be part of arch/arm/mach-mediatek? According to
> https://wikidevi.wi-cat.ru/MediaTek#xPON, the older (mips based) MT752x
> chips are apparently just rebranded to EN752x after the business unit
> was spun off, but I guess they are still in the same family.

Hi,

ECNT (what was once known as trendchip) is now a subsidary of MTK (and 
not a BU if I am understanding it correctly).

the EN7523 is rather similar to the MT7622 for some parts, other parts 
(spi, flash, wdt, gpio, .. drivers all needed to be rewritten and will 
be part of the next series).

the older MIPS silicon shares almost no IP with the current ARM silicon.

not really my call to decide which folder this should live in. it seemed 
natural to just give it its own folder, as ECNT is not a BU of MTK.

we can change that however if required.

     John


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH 4/5] ARM: Add basic support for EcoNet EN7523 SoC

[Arnd Bergmann]

On Fri, Jul 30, 2021 at 5:16 PM John Crispin <john@phrozen.org> wrote:
> On 30.07.21 16:48, Arnd Bergmann wrote:
> > Given how closely related this probably is to MT7623/MT7622, should this
> > perhaps just be part of arch/arm/mach-mediatek? According to
> > https://wikidevi.wi-cat.ru/MediaTek#xPON, the older (mips based) MT752x
> > chips are apparently just rebranded to EN752x after the business unit
> > was spun off, but I guess they are still in the same family.
>
> Hi,
>
> ECNT (what was once known as trendchip) is now a subsidary of MTK (and
> not a BU if I am understanding it correctly).
>
> the EN7523 is rather similar to the MT7622 for some parts, other parts
> (spi, flash, wdt, gpio, .. drivers all needed to be rewritten and will
> be part of the next series).
>
> the older MIPS silicon shares almost no IP with the current ARM silicon.

Ah, so I guess the old Trendchip parts were separately developed separately
from the Ralink parts before the original acquisition, and then Ralink/Mediatek
combined the two product lines before spinning off the dsl products into
a new subsidiary.

> not really my call to decide which folder this should live in. it seemed
> natural to just give it its own folder, as ECNT is not a BU of MTK.
>
> we can change that however if required.

My preference would be to have a common directory for both,
but I'm not going to require that. From the kernel perspective the
main question is actually not who makes the parts but who is going
to maintain the code.

Matthias is doing a good job taking care of the Mediatek parts,
and he's familiar with the arm-soc process. If there is enough overlap
between the Mediatek and EcoNet devices that we would expect
either conflicts between binding/driver patches, or that you would want
each other to review the patches for related parts, then it would
make most sense to have a common directory and maintainer
entry for both, with all patches going through the same git tree.

It would also be nice to have someone listed as second maintainer
for mediatek, since Matthias is currently the only one listed there.
(Doesn't have to be you, I don't mean to drag you into taking up
more work if you don't want to).

Please discuss this between the three of you (Bert, John and
Matthias), and let me know what you think works best for all of
you.

       Arnd

Re: [PATCH 4/5] ARM: Add basic support for EcoNet EN7523 SoC

[Arnd Bergmann]

On Fri, Jul 30, 2021 at 5:16 PM John Crispin <john@phrozen.org> wrote:
> On 30.07.21 16:48, Arnd Bergmann wrote:
> > Given how closely related this probably is to MT7623/MT7622, should this
> > perhaps just be part of arch/arm/mach-mediatek? According to
> > https://wikidevi.wi-cat.ru/MediaTek#xPON, the older (mips based) MT752x
> > chips are apparently just rebranded to EN752x after the business unit
> > was spun off, but I guess they are still in the same family.
>
> Hi,
>
> ECNT (what was once known as trendchip) is now a subsidary of MTK (and
> not a BU if I am understanding it correctly).
>
> the EN7523 is rather similar to the MT7622 for some parts, other parts
> (spi, flash, wdt, gpio, .. drivers all needed to be rewritten and will
> be part of the next series).
>
> the older MIPS silicon shares almost no IP with the current ARM silicon.

Ah, so I guess the old Trendchip parts were separately developed separately
from the Ralink parts before the original acquisition, and then Ralink/Mediatek
combined the two product lines before spinning off the dsl products into
a new subsidiary.

> not really my call to decide which folder this should live in. it seemed
> natural to just give it its own folder, as ECNT is not a BU of MTK.
>
> we can change that however if required.

My preference would be to have a common directory for both,
but I'm not going to require that. From the kernel perspective the
main question is actually not who makes the parts but who is going
to maintain the code.

Matthias is doing a good job taking care of the Mediatek parts,
and he's familiar with the arm-soc process. If there is enough overlap
between the Mediatek and EcoNet devices that we would expect
either conflicts between binding/driver patches, or that you would want
each other to review the patches for related parts, then it would
make most sense to have a common directory and maintainer
entry for both, with all patches going through the same git tree.

It would also be nice to have someone listed as second maintainer
for mediatek, since Matthias is currently the only one listed there.
(Doesn't have to be you, I don't mean to drag you into taking up
more work if you don't want to).

Please discuss this between the three of you (Bert, John and
Matthias), and let me know what you think works best for all of
you.

       Arnd

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH 4/5] ARM: Add basic support for EcoNet EN7523 SoC

[Ard Biesheuvel]

On Fri, 30 Jul 2021 at 16:48, Arnd Bergmann <arnd@arndb.de> wrote:
>
> On Fri, Jul 30, 2021 at 3:45 PM Bert Vermeulen <bert@biot.com> wrote:
> >
> > From: John Crispin <john@phrozen.org>
> >
> > EN7523 is an armv7 based silicon used inside broadband access type devices
> > such as xPON and xDSL. It shares various silicon blocks with MediaTek
> > silicon such as the MT7622.
> >
> > Signed-off-by: John Crispin <john@phrozen.org>
> > Signed-off-by: Bert Vermeulen <bert@biot.com>
>
> It's always nice to see a new SoC family.
>
> > --- a/arch/arm/Kconfig
> > +++ b/arch/arm/Kconfig
> > @@ -580,6 +580,20 @@ config ARCH_VIRT
> >         select HAVE_ARM_ARCH_TIMER
> >         select ARCH_SUPPORTS_BIG_ENDIAN
> >
> > +config ARCH_ECONET
> > +       bool "Econet SoC Support"
> > +       depends on ARCH_MULTI_V7
> > +       select ARM_AMBA
> > +       select ARM_GIC
> > +       select ARM_GIC_V3
> > +       select ARM_DMA_USE_IOMMU
> > +       select ARM_PSCI
> > +       select HAVE_ARM_ARCH_TIMER
> > +       select IOMMU_DMA
> > +       select COMMON_CLK
> > +       help
> > +         Support for Econet EN7523 SoCs
>
> Given how closely related this probably is to MT7623/MT7622, should this
> perhaps just be part of arch/arm/mach-mediatek? According to
> https://wikidevi.wi-cat.ru/MediaTek#xPON, the older (mips based) MT752x
> chips are apparently just rebranded to EN752x after the business unit
> was spun off, but I guess they are still in the same family.
>
> > diff --git a/arch/arm/Makefile b/arch/arm/Makefile
> > index 173da685a52e..1bff0aa29c07 100644
> > --- a/arch/arm/Makefile
> > +++ b/arch/arm/Makefile
> > @@ -152,6 +152,7 @@ textofs-$(CONFIG_ARCH_MSM8X60) := 0x00208000
> >  textofs-$(CONFIG_ARCH_MSM8960) := 0x00208000
> >  textofs-$(CONFIG_ARCH_MESON) := 0x00208000
> >  textofs-$(CONFIG_ARCH_AXXIA) := 0x00308000
> > +textofs-$(CONFIG_ARCH_ECONET) := 0x00088000
>
> Why is this needed?
>
> Note also the comment directly above it exlaining
> # Text offset. This list is sorted numerically by address in order to
> # provide a means to avoid/resolve conflicts in multi-arch kernels.
>

Yes, please drop this - it is a horrible hack and it's already quite
disappointing that we are stuck with it for the foreseeable future.

So I assume the purpose of this is to protect the first 128k of DRAM
to be protected from being overwritten by the decompressor?

It would be best to move this reserved region elsewhere, but I can
understand that this is no longer an option. So the alternatives are
- omit this window from the /memory node, and rely on Geert's recent
decompressor changes which make it discover the usable memory from the
DT, or
- better would be to use a /memreserve/ here (which you may already
have?), and teach the newly added decompressor code to take those into
account when choosing the target window for decompressing the kernel.

--
Ard.

Re: [PATCH 4/5] ARM: Add basic support for EcoNet EN7523 SoC

[Ard Biesheuvel]

On Fri, 30 Jul 2021 at 16:48, Arnd Bergmann <arnd@arndb.de> wrote:
>
> On Fri, Jul 30, 2021 at 3:45 PM Bert Vermeulen <bert@biot.com> wrote:
> >
> > From: John Crispin <john@phrozen.org>
> >
> > EN7523 is an armv7 based silicon used inside broadband access type devices
> > such as xPON and xDSL. It shares various silicon blocks with MediaTek
> > silicon such as the MT7622.
> >
> > Signed-off-by: John Crispin <john@phrozen.org>
> > Signed-off-by: Bert Vermeulen <bert@biot.com>
>
> It's always nice to see a new SoC family.
>
> > --- a/arch/arm/Kconfig
> > +++ b/arch/arm/Kconfig
> > @@ -580,6 +580,20 @@ config ARCH_VIRT
> >         select HAVE_ARM_ARCH_TIMER
> >         select ARCH_SUPPORTS_BIG_ENDIAN
> >
> > +config ARCH_ECONET
> > +       bool "Econet SoC Support"
> > +       depends on ARCH_MULTI_V7
> > +       select ARM_AMBA
> > +       select ARM_GIC
> > +       select ARM_GIC_V3
> > +       select ARM_DMA_USE_IOMMU
> > +       select ARM_PSCI
> > +       select HAVE_ARM_ARCH_TIMER
> > +       select IOMMU_DMA
> > +       select COMMON_CLK
> > +       help
> > +         Support for Econet EN7523 SoCs
>
> Given how closely related this probably is to MT7623/MT7622, should this
> perhaps just be part of arch/arm/mach-mediatek? According to
> https://wikidevi.wi-cat.ru/MediaTek#xPON, the older (mips based) MT752x
> chips are apparently just rebranded to EN752x after the business unit
> was spun off, but I guess they are still in the same family.
>
> > diff --git a/arch/arm/Makefile b/arch/arm/Makefile
> > index 173da685a52e..1bff0aa29c07 100644
> > --- a/arch/arm/Makefile
> > +++ b/arch/arm/Makefile
> > @@ -152,6 +152,7 @@ textofs-$(CONFIG_ARCH_MSM8X60) := 0x00208000
> >  textofs-$(CONFIG_ARCH_MSM8960) := 0x00208000
> >  textofs-$(CONFIG_ARCH_MESON) := 0x00208000
> >  textofs-$(CONFIG_ARCH_AXXIA) := 0x00308000
> > +textofs-$(CONFIG_ARCH_ECONET) := 0x00088000
>
> Why is this needed?
>
> Note also the comment directly above it exlaining
> # Text offset. This list is sorted numerically by address in order to
> # provide a means to avoid/resolve conflicts in multi-arch kernels.
>

Yes, please drop this - it is a horrible hack and it's already quite
disappointing that we are stuck with it for the foreseeable future.

So I assume the purpose of this is to protect the first 128k of DRAM
to be protected from being overwritten by the decompressor?

It would be best to move this reserved region elsewhere, but I can
understand that this is no longer an option. So the alternatives are
- omit this window from the /memory node, and rely on Geert's recent
decompressor changes which make it discover the usable memory from the
DT, or
- better would be to use a /memreserve/ here (which you may already
have?), and teach the newly added decompressor code to take those into
account when choosing the target window for decompressing the kernel.

--
Ard.

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH 4/5] ARM: Add basic support for EcoNet EN7523 SoC

[Felix Fietkau]

On 2021-08-01 18:44, Ard Biesheuvel wrote:
> On Fri, 30 Jul 2021 at 16:48, Arnd Bergmann <arnd@arndb.de> wrote:
>>
>> Why is this needed?
>>
>> Note also the comment directly above it exlaining
>> # Text offset. This list is sorted numerically by address in order to
>> # provide a means to avoid/resolve conflicts in multi-arch kernels.
>>
> 
> Yes, please drop this - it is a horrible hack and it's already quite
> disappointing that we are stuck with it for the foreseeable future.
> 
> So I assume the purpose of this is to protect the first 128k of DRAM
> to be protected from being overwritten by the decompressor?
> 
> It would be best to move this reserved region elsewhere, but I can
> understand that this is no longer an option. So the alternatives are
> - omit this window from the /memory node, and rely on Geert's recent
> decompressor changes which make it discover the usable memory from the
> DT, or
> - better would be to use a /memreserve/ here (which you may already
> have?), and teach the newly added decompressor code to take those into
> account when choosing the target window for decompressing the kernel.
I looked into this issue myself and found that this approach has a
significant drawback: 2 MiB of RAM is permanently wasted for something
that only needs to be preserved during boot time.

If the first 256 or 512 KiB of RAM are reserved in the decompressor, it
means that the first 2 MiB need to be reserved, because that's the
granularity for the kernel page mapping when the MMU is turned on.

If we reserve it, we also need to need to take it out of the physical
RAM address range, so there's no way to reclaim it later.

On the other hand, with the simple textofs solution, I believe it gets
freed in a late initcall, making it usable.

So what's the right approach to deal with this?

- Felix

Re: [PATCH 4/5] ARM: Add basic support for EcoNet EN7523 SoC

[Felix Fietkau]

On 2021-08-01 18:44, Ard Biesheuvel wrote:
> On Fri, 30 Jul 2021 at 16:48, Arnd Bergmann <arnd@arndb.de> wrote:
>>
>> Why is this needed?
>>
>> Note also the comment directly above it exlaining
>> # Text offset. This list is sorted numerically by address in order to
>> # provide a means to avoid/resolve conflicts in multi-arch kernels.
>>
> 
> Yes, please drop this - it is a horrible hack and it's already quite
> disappointing that we are stuck with it for the foreseeable future.
> 
> So I assume the purpose of this is to protect the first 128k of DRAM
> to be protected from being overwritten by the decompressor?
> 
> It would be best to move this reserved region elsewhere, but I can
> understand that this is no longer an option. So the alternatives are
> - omit this window from the /memory node, and rely on Geert's recent
> decompressor changes which make it discover the usable memory from the
> DT, or
> - better would be to use a /memreserve/ here (which you may already
> have?), and teach the newly added decompressor code to take those into
> account when choosing the target window for decompressing the kernel.
I looked into this issue myself and found that this approach has a
significant drawback: 2 MiB of RAM is permanently wasted for something
that only needs to be preserved during boot time.

If the first 256 or 512 KiB of RAM are reserved in the decompressor, it
means that the first 2 MiB need to be reserved, because that's the
granularity for the kernel page mapping when the MMU is turned on.

If we reserve it, we also need to need to take it out of the physical
RAM address range, so there's no way to reclaim it later.

On the other hand, with the simple textofs solution, I believe it gets
freed in a late initcall, making it usable.

So what's the right approach to deal with this?

- Felix

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH 4/5] ARM: Add basic support for EcoNet EN7523 SoC

[Ard Biesheuvel]

On Fri, 3 Sept 2021 at 18:20, Felix Fietkau <nbd@nbd.name> wrote:
>
>
> On 2021-08-01 18:44, Ard Biesheuvel wrote:
> > On Fri, 30 Jul 2021 at 16:48, Arnd Bergmann <arnd@arndb.de> wrote:
> >>
> >> Why is this needed?
> >>
> >> Note also the comment directly above it exlaining
> >> # Text offset. This list is sorted numerically by address in order to
> >> # provide a means to avoid/resolve conflicts in multi-arch kernels.
> >>
> >
> > Yes, please drop this - it is a horrible hack and it's already quite
> > disappointing that we are stuck with it for the foreseeable future.
> >
> > So I assume the purpose of this is to protect the first 128k of DRAM
> > to be protected from being overwritten by the decompressor?
> >
> > It would be best to move this reserved region elsewhere, but I can
> > understand that this is no longer an option. So the alternatives are
> > - omit this window from the /memory node, and rely on Geert's recent
> > decompressor changes which make it discover the usable memory from the
> > DT, or
> > - better would be to use a /memreserve/ here (which you may already
> > have?), and teach the newly added decompressor code to take those into
> > account when choosing the target window for decompressing the kernel.
> I looked into this issue myself and found that this approach has a
> significant drawback: 2 MiB of RAM is permanently wasted for something
> that only needs to be preserved during boot time.
>

How so? If that memory region carries your PSCI implementation, it
should be preserved permanently. So at least the 512k are permanently
reserved.

> If the first 256 or 512 KiB of RAM are reserved in the decompressor, it
> means that the first 2 MiB need to be reserved, because that's the
> granularity for the kernel page mapping when the MMU is turned on.
>

Indeed.

> If we reserve it, we also need to need to take it out of the physical
> RAM address range, so there's no way to reclaim it later.
>
> On the other hand, with the simple textofs solution, I believe it gets
> freed in a late initcall, making it usable.
>
> So what's the right approach to deal with this?
>

The right solution here is to fix your firmware/bootloader so that the
PSCI reserved region is moved to the top of memory. Adding more
TEXT_OFFSET hacks is really not the right approach here.

Re: [PATCH 4/5] ARM: Add basic support for EcoNet EN7523 SoC

[Ard Biesheuvel]

On Fri, 3 Sept 2021 at 18:20, Felix Fietkau <nbd@nbd.name> wrote:
>
>
> On 2021-08-01 18:44, Ard Biesheuvel wrote:
> > On Fri, 30 Jul 2021 at 16:48, Arnd Bergmann <arnd@arndb.de> wrote:
> >>
> >> Why is this needed?
> >>
> >> Note also the comment directly above it exlaining
> >> # Text offset. This list is sorted numerically by address in order to
> >> # provide a means to avoid/resolve conflicts in multi-arch kernels.
> >>
> >
> > Yes, please drop this - it is a horrible hack and it's already quite
> > disappointing that we are stuck with it for the foreseeable future.
> >
> > So I assume the purpose of this is to protect the first 128k of DRAM
> > to be protected from being overwritten by the decompressor?
> >
> > It would be best to move this reserved region elsewhere, but I can
> > understand that this is no longer an option. So the alternatives are
> > - omit this window from the /memory node, and rely on Geert's recent
> > decompressor changes which make it discover the usable memory from the
> > DT, or
> > - better would be to use a /memreserve/ here (which you may already
> > have?), and teach the newly added decompressor code to take those into
> > account when choosing the target window for decompressing the kernel.
> I looked into this issue myself and found that this approach has a
> significant drawback: 2 MiB of RAM is permanently wasted for something
> that only needs to be preserved during boot time.
>

How so? If that memory region carries your PSCI implementation, it
should be preserved permanently. So at least the 512k are permanently
reserved.

> If the first 256 or 512 KiB of RAM are reserved in the decompressor, it
> means that the first 2 MiB need to be reserved, because that's the
> granularity for the kernel page mapping when the MMU is turned on.
>

Indeed.

> If we reserve it, we also need to need to take it out of the physical
> RAM address range, so there's no way to reclaim it later.
>
> On the other hand, with the simple textofs solution, I believe it gets
> freed in a late initcall, making it usable.
>
> So what's the right approach to deal with this?
>

The right solution here is to fix your firmware/bootloader so that the
PSCI reserved region is moved to the top of memory. Adding more
TEXT_OFFSET hacks is really not the right approach here.

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH 4/5] ARM: Add basic support for EcoNet EN7523 SoC

[Bert Vermeulen]

On 7/30/21 4:48 PM, Arnd Bergmann wrote:
> On Fri, Jul 30, 2021 at 3:45 PM Bert Vermeulen <bert@biot.com> wrote:
>> diff --git a/arch/arm/Makefile b/arch/arm/Makefile
>> index 173da685a52e..1bff0aa29c07 100644
>> --- a/arch/arm/Makefile
>> +++ b/arch/arm/Makefile
>> @@ -152,6 +152,7 @@ textofs-$(CONFIG_ARCH_MSM8X60) := 0x00208000
>>  textofs-$(CONFIG_ARCH_MSM8960) := 0x00208000
>>  textofs-$(CONFIG_ARCH_MESON) := 0x00208000
>>  textofs-$(CONFIG_ARCH_AXXIA) := 0x00308000
>> +textofs-$(CONFIG_ARCH_ECONET) := 0x00088000
> 
> Why is this needed?
> 
> Note also the comment directly above it exlaining
> # Text offset. This list is sorted numerically by address in order to
> # provide a means to avoid/resolve conflicts in multi-arch kernels.

I didn't make that patch, but it turns out it's needed to get PSCI working; 
detection hangs without it. That makes no sense to me, but I'll examine further.


-- 
Bert Vermeulen
bert@biot.com

Re: [PATCH 4/5] ARM: Add basic support for EcoNet EN7523 SoC

[Bert Vermeulen]

On 7/30/21 4:48 PM, Arnd Bergmann wrote:
> On Fri, Jul 30, 2021 at 3:45 PM Bert Vermeulen <bert@biot.com> wrote:
>> diff --git a/arch/arm/Makefile b/arch/arm/Makefile
>> index 173da685a52e..1bff0aa29c07 100644
>> --- a/arch/arm/Makefile
>> +++ b/arch/arm/Makefile
>> @@ -152,6 +152,7 @@ textofs-$(CONFIG_ARCH_MSM8X60) := 0x00208000
>>  textofs-$(CONFIG_ARCH_MSM8960) := 0x00208000
>>  textofs-$(CONFIG_ARCH_MESON) := 0x00208000
>>  textofs-$(CONFIG_ARCH_AXXIA) := 0x00308000
>> +textofs-$(CONFIG_ARCH_ECONET) := 0x00088000
> 
> Why is this needed?
> 
> Note also the comment directly above it exlaining
> # Text offset. This list is sorted numerically by address in order to
> # provide a means to avoid/resolve conflicts in multi-arch kernels.

I didn't make that patch, but it turns out it's needed to get PSCI working; 
detection hangs without it. That makes no sense to me, but I'll examine further.


-- 
Bert Vermeulen
bert@biot.com

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH 4/5] ARM: Add basic support for EcoNet EN7523 SoC

[Geert Uytterhoeven]

Hoi Bert,

On Wed, Aug 4, 2021 at 6:43 PM Bert Vermeulen <bert@biot.com> wrote:
> On 7/30/21 4:48 PM, Arnd Bergmann wrote:
> > On Fri, Jul 30, 2021 at 3:45 PM Bert Vermeulen <bert@biot.com> wrote:
> >> diff --git a/arch/arm/Makefile b/arch/arm/Makefile
> >> index 173da685a52e..1bff0aa29c07 100644
> >> --- a/arch/arm/Makefile
> >> +++ b/arch/arm/Makefile
> >> @@ -152,6 +152,7 @@ textofs-$(CONFIG_ARCH_MSM8X60) := 0x00208000
> >>  textofs-$(CONFIG_ARCH_MSM8960) := 0x00208000
> >>  textofs-$(CONFIG_ARCH_MESON) := 0x00208000
> >>  textofs-$(CONFIG_ARCH_AXXIA) := 0x00308000
> >> +textofs-$(CONFIG_ARCH_ECONET) := 0x00088000
> >
> > Why is this needed?
> >
> > Note also the comment directly above it exlaining
> > # Text offset. This list is sorted numerically by address in order to
> > # provide a means to avoid/resolve conflicts in multi-arch kernels.
>
> I didn't make that patch, but it turns out it's needed to get PSCI working;
> detection hangs without it. That makes no sense to me, but I'll examine further.

Probably PSCI relies on the memory contents at the start of RAM not
being overwritten?
Does it help if you remove the first 512 KiB from the /memory node
(which should be declared in en7523-evb.dts instead of en7523.dtsi
BTW)?

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 4/5] ARM: Add basic support for EcoNet EN7523 SoC

[Geert Uytterhoeven]

Hoi Bert,

On Wed, Aug 4, 2021 at 6:43 PM Bert Vermeulen <bert@biot.com> wrote:
> On 7/30/21 4:48 PM, Arnd Bergmann wrote:
> > On Fri, Jul 30, 2021 at 3:45 PM Bert Vermeulen <bert@biot.com> wrote:
> >> diff --git a/arch/arm/Makefile b/arch/arm/Makefile
> >> index 173da685a52e..1bff0aa29c07 100644
> >> --- a/arch/arm/Makefile
> >> +++ b/arch/arm/Makefile
> >> @@ -152,6 +152,7 @@ textofs-$(CONFIG_ARCH_MSM8X60) := 0x00208000
> >>  textofs-$(CONFIG_ARCH_MSM8960) := 0x00208000
> >>  textofs-$(CONFIG_ARCH_MESON) := 0x00208000
> >>  textofs-$(CONFIG_ARCH_AXXIA) := 0x00308000
> >> +textofs-$(CONFIG_ARCH_ECONET) := 0x00088000
> >
> > Why is this needed?
> >
> > Note also the comment directly above it exlaining
> > # Text offset. This list is sorted numerically by address in order to
> > # provide a means to avoid/resolve conflicts in multi-arch kernels.
>
> I didn't make that patch, but it turns out it's needed to get PSCI working;
> detection hangs without it. That makes no sense to me, but I'll examine further.

Probably PSCI relies on the memory contents at the start of RAM not
being overwritten?
Does it help if you remove the first 512 KiB from the /memory node
(which should be declared in en7523-evb.dts instead of en7523.dtsi
BTW)?

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

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH 4/5] ARM: Add basic support for EcoNet EN7523 SoC

[Ard Biesheuvel]

On Mon, 9 Aug 2021 at 14:46, Geert Uytterhoeven <geert@linux-m68k.org> wrote:
>
> Hoi Bert,
>
> On Wed, Aug 4, 2021 at 6:43 PM Bert Vermeulen <bert@biot.com> wrote:
> > On 7/30/21 4:48 PM, Arnd Bergmann wrote:
> > > On Fri, Jul 30, 2021 at 3:45 PM Bert Vermeulen <bert@biot.com> wrote:
> > >> diff --git a/arch/arm/Makefile b/arch/arm/Makefile
> > >> index 173da685a52e..1bff0aa29c07 100644
> > >> --- a/arch/arm/Makefile
> > >> +++ b/arch/arm/Makefile
> > >> @@ -152,6 +152,7 @@ textofs-$(CONFIG_ARCH_MSM8X60) := 0x00208000
> > >>  textofs-$(CONFIG_ARCH_MSM8960) := 0x00208000
> > >>  textofs-$(CONFIG_ARCH_MESON) := 0x00208000
> > >>  textofs-$(CONFIG_ARCH_AXXIA) := 0x00308000
> > >> +textofs-$(CONFIG_ARCH_ECONET) := 0x00088000
> > >
> > > Why is this needed?
> > >
> > > Note also the comment directly above it exlaining
> > > # Text offset. This list is sorted numerically by address in order to
> > > # provide a means to avoid/resolve conflicts in multi-arch kernels.
> >
> > I didn't make that patch, but it turns out it's needed to get PSCI working;
> > detection hangs without it. That makes no sense to me, but I'll examine further.
>
> Probably PSCI relies on the memory contents at the start of RAM not
> being overwritten?
> Does it help if you remove the first 512 KiB from the /memory node

I /think/ we rely on the first memblock being mappable using section
mappings, so it might be better to remove the first 1 MB (or 2 MB in
case the platform is LPAE capable). Note that this memory is discarded
in any case, so this change is not as costly as it may seem.


> (which should be declared in en7523-evb.dts instead of en7523.dtsi
> BTW)?
>
> 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 4/5] ARM: Add basic support for EcoNet EN7523 SoC

[Ard Biesheuvel]

On Mon, 9 Aug 2021 at 14:46, Geert Uytterhoeven <geert@linux-m68k.org> wrote:
>
> Hoi Bert,
>
> On Wed, Aug 4, 2021 at 6:43 PM Bert Vermeulen <bert@biot.com> wrote:
> > On 7/30/21 4:48 PM, Arnd Bergmann wrote:
> > > On Fri, Jul 30, 2021 at 3:45 PM Bert Vermeulen <bert@biot.com> wrote:
> > >> diff --git a/arch/arm/Makefile b/arch/arm/Makefile
> > >> index 173da685a52e..1bff0aa29c07 100644
> > >> --- a/arch/arm/Makefile
> > >> +++ b/arch/arm/Makefile
> > >> @@ -152,6 +152,7 @@ textofs-$(CONFIG_ARCH_MSM8X60) := 0x00208000
> > >>  textofs-$(CONFIG_ARCH_MSM8960) := 0x00208000
> > >>  textofs-$(CONFIG_ARCH_MESON) := 0x00208000
> > >>  textofs-$(CONFIG_ARCH_AXXIA) := 0x00308000
> > >> +textofs-$(CONFIG_ARCH_ECONET) := 0x00088000
> > >
> > > Why is this needed?
> > >
> > > Note also the comment directly above it exlaining
> > > # Text offset. This list is sorted numerically by address in order to
> > > # provide a means to avoid/resolve conflicts in multi-arch kernels.
> >
> > I didn't make that patch, but it turns out it's needed to get PSCI working;
> > detection hangs without it. That makes no sense to me, but I'll examine further.
>
> Probably PSCI relies on the memory contents at the start of RAM not
> being overwritten?
> Does it help if you remove the first 512 KiB from the /memory node

I /think/ we rely on the first memblock being mappable using section
mappings, so it might be better to remove the first 1 MB (or 2 MB in
case the platform is LPAE capable). Note that this memory is discarded
in any case, so this change is not as costly as it may seem.


> (which should be declared in en7523-evb.dts instead of en7523.dtsi
> BTW)?
>
> 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

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH 4/5] ARM: Add basic support for EcoNet EN7523 SoC

[Bert Vermeulen]

On 8/9/21 2:46 PM, Geert Uytterhoeven wrote:
>> I didn't make that patch, but it turns out it's needed to get PSCI working;
>> detection hangs without it. That makes no sense to me, but I'll examine further.
> 
> Probably PSCI relies on the memory contents at the start of RAM not
> being overwritten?

It turns out to hang at the first SMC call, for PSCI_0_2_FN_PSCI_VERSION. I 
assume the receiver of that call, ATF, got dropped in that region by the 
vendor's U-Boot.

> Does it help if you remove the first 512 KiB from the /memory node
> (which should be declared in en7523-evb.dts instead of en7523.dtsi
> BTW)?
No it doesn't, was just trying to work out why not, in your 
fdt_check_mem_start().

Anyway that was Arnd's first suggestion, but I think his second suggestion 
(teach fdt_check_mem_start() about /memreserve/) is the cleaner approach to 
this. Opinions?


-- 
Bert Vermeulen
bert@biot.com

Re: [PATCH 4/5] ARM: Add basic support for EcoNet EN7523 SoC

[Bert Vermeulen]

On 8/9/21 2:46 PM, Geert Uytterhoeven wrote:
>> I didn't make that patch, but it turns out it's needed to get PSCI working;
>> detection hangs without it. That makes no sense to me, but I'll examine further.
> 
> Probably PSCI relies on the memory contents at the start of RAM not
> being overwritten?

It turns out to hang at the first SMC call, for PSCI_0_2_FN_PSCI_VERSION. I 
assume the receiver of that call, ATF, got dropped in that region by the 
vendor's U-Boot.

> Does it help if you remove the first 512 KiB from the /memory node
> (which should be declared in en7523-evb.dts instead of en7523.dtsi
> BTW)?
No it doesn't, was just trying to work out why not, in your 
fdt_check_mem_start().

Anyway that was Arnd's first suggestion, but I think his second suggestion 
(teach fdt_check_mem_start() about /memreserve/) is the cleaner approach to 
this. Opinions?


-- 
Bert Vermeulen
bert@biot.com

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH 5/5] ARM: multi_v7_defconfig: Add support for EcoNet EN7523 SoC

[Bert Vermeulen]

From: John Crispin <john@phrozen.org>

This enables basic bootup support for the EcoNet EN7523 SoC.

Signed-off-by: Bert Vermeulen <bert@biot.com>
---
 arch/arm/configs/multi_v7_defconfig | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/arm/configs/multi_v7_defconfig b/arch/arm/configs/multi_v7_defconfig
index d9abaae118dd..18a10ef6df5d 100644
--- a/arch/arm/configs/multi_v7_defconfig
+++ b/arch/arm/configs/multi_v7_defconfig
@@ -31,6 +31,7 @@ CONFIG_MACH_BERLIN_BG2=y
 CONFIG_MACH_BERLIN_BG2CD=y
 CONFIG_MACH_BERLIN_BG2Q=y
 CONFIG_ARCH_DIGICOLOR=y
+CONFIG_ARCH_ECONET=y
 CONFIG_ARCH_EXYNOS=y
 CONFIG_ARCH_HIGHBANK=y
 CONFIG_ARCH_HISI=y
@@ -983,6 +984,7 @@ CONFIG_STAGING_BOARD=y
 CONFIG_MFD_CROS_EC_DEV=m
 CONFIG_CROS_EC_I2C=m
 CONFIG_CROS_EC_SPI=m
+CONFIG_COMMON_CLK_EN7523=y
 CONFIG_COMMON_CLK_MAX77686=y
 CONFIG_COMMON_CLK_RK808=m
 CONFIG_COMMON_CLK_SCMI=y
-- 
2.25.1

[PATCH 5/5] ARM: multi_v7_defconfig: Add support for EcoNet EN7523 SoC

[Bert Vermeulen]

From: John Crispin <john@phrozen.org>

This enables basic bootup support for the EcoNet EN7523 SoC.

Signed-off-by: Bert Vermeulen <bert@biot.com>
---
 arch/arm/configs/multi_v7_defconfig | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/arm/configs/multi_v7_defconfig b/arch/arm/configs/multi_v7_defconfig
index d9abaae118dd..18a10ef6df5d 100644
--- a/arch/arm/configs/multi_v7_defconfig
+++ b/arch/arm/configs/multi_v7_defconfig
@@ -31,6 +31,7 @@ CONFIG_MACH_BERLIN_BG2=y
 CONFIG_MACH_BERLIN_BG2CD=y
 CONFIG_MACH_BERLIN_BG2Q=y
 CONFIG_ARCH_DIGICOLOR=y
+CONFIG_ARCH_ECONET=y
 CONFIG_ARCH_EXYNOS=y
 CONFIG_ARCH_HIGHBANK=y
 CONFIG_ARCH_HISI=y
@@ -983,6 +984,7 @@ CONFIG_STAGING_BOARD=y
 CONFIG_MFD_CROS_EC_DEV=m
 CONFIG_CROS_EC_I2C=m
 CONFIG_CROS_EC_SPI=m
+CONFIG_COMMON_CLK_EN7523=y
 CONFIG_COMMON_CLK_MAX77686=y
 CONFIG_COMMON_CLK_RK808=m
 CONFIG_COMMON_CLK_SCMI=y
-- 
2.25.1


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH 0/4] Add support for EcoNet EN7523 SoC

[Linus Walleij]

On Fri, Jul 30, 2021 at 3:48 PM Bert Vermeulen <bert@biot.com> wrote:

> This patchset adds support for the EcoNet EN7523 SoC, intended primarily
> for xPON/xDSL routers.
>
> John Crispin (4):
>   dt-bindings: Add vendor prefix for EcoNet
>   dt-bindings: arm: econet: Add binding for EN7523 SoC and EVB
>   ARM: dts: Add basic support for EcoNet EN7523
>   ARM: Add basic support for EcoNet EN7523 SoC

Given that this uses GIC v3 and so forth I recognize that this is brand new
ARM32 silicon. :O

All patches look good. Very interesting platform!
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>

Yours,
Linus Walleij

Re: [PATCH 0/4] Add support for EcoNet EN7523 SoC

[Linus Walleij]

On Fri, Jul 30, 2021 at 3:48 PM Bert Vermeulen <bert@biot.com> wrote:

> This patchset adds support for the EcoNet EN7523 SoC, intended primarily
> for xPON/xDSL routers.
>
> John Crispin (4):
>   dt-bindings: Add vendor prefix for EcoNet
>   dt-bindings: arm: econet: Add binding for EN7523 SoC and EVB
>   ARM: dts: Add basic support for EcoNet EN7523
>   ARM: Add basic support for EcoNet EN7523 SoC

Given that this uses GIC v3 and so forth I recognize that this is brand new
ARM32 silicon. :O

All patches look good. Very interesting platform!
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>

Yours,
Linus Walleij

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel