[PATCH v3 0/5] arm64: Initial Realtek RTD1295 enablement

[PATCH v3 0/5] arm64: Initial Realtek RTD1295 enablement

[Andreas Färber]

Hello,

This mini-series adds initial support for the Realtek RTD1295 SoC and
the Zidoo X9S TV box.

v3 changes #address-cells, #size-cells and ranges.

With these patches CPU0 can be booted with earlycon.

PSCI doesn't work despite present in the vendor device tree; as enable-method
it instead used a custom "rtk-spin-table" that I sadly have no source code of.

The UARTs use a custom interrupt controller that I again lack source code of;
with interrupts = <GIC_SPI 41 IRQ_TYPE_LEVEL_HIGH> it can boot into an initrd.

The boot process is slightly twisted: The files need to be loaded from a
32-bit U-Boot, then boot into 64-bit U-Boot where the kernel can be booted.
Similar to my previous Amlogic S905 work, the TEXT_OFFSET poses a problem, so
a uImage needs to be used (or the kernel patched) for load address 0x00280000.
I haven't succeeded loading an initrd via bootm/booti; but as quick workaround
initrd=$rootfs_loadaddr,0x$filesize can manually be specified in $bootargs.

Cf. https://en.opensuse.org/HCL:Zidoo_X9S

More experimental patches at:
https://github.com/afaerber/linux/commits/rtd1295-next

Have a lot of fun!

Cheers,
Andreas

v2 -> v3:
* DT cleanups (Rob)
* Drop arm@kernel.org again (Olof)

v1 -> v2:
* Add Acked-bys
* Tweak DT subjects
* Reword DT bindings
* Drop one memreserve
* Add MAINTAINERS patch

Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Olof Johansson <olof@lixom.net>
Cc: Roc He <hepeng@zidoo.tv>
Cc: devicetree@vger.kernel.org

Andreas Färber (5):
  dt-bindings: Add vendor prefix for Zidoo
  dt-bindings: arm: Add Realtek RTD1295 bindings
  ARM64: Prepare Realtek RTD1295
  ARM64: dts: Add Realtek RTD1295 and Zidoo X9S
  MAINTAINERS: Add Realtek section

 Documentation/devicetree/bindings/arm/realtek.txt  |  20 ++++
 .../devicetree/bindings/vendor-prefixes.txt        |   1 +
 MAINTAINERS                                        |   7 ++
 arch/arm64/Kconfig.platforms                       |   6 +
 arch/arm64/boot/dts/Makefile                       |   1 +
 arch/arm64/boot/dts/realtek/Makefile               |   5 +
 arch/arm64/boot/dts/realtek/rtd1295-zidoo-x9s.dts  |  42 +++++++
 arch/arm64/boot/dts/realtek/rtd1295.dtsi           | 131 +++++++++++++++++++++
 8 files changed, 213 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/arm/realtek.txt
 create mode 100644 arch/arm64/boot/dts/realtek/Makefile
 create mode 100644 arch/arm64/boot/dts/realtek/rtd1295-zidoo-x9s.dts
 create mode 100644 arch/arm64/boot/dts/realtek/rtd1295.dtsi

-- 
2.12.0

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

[Andreas Färber]

Zidoo is a Chinese manufacturer of TV boxes.

Acked-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: Rob Herring <robh@kernel.org>
Acked-by: Roc He <hepeng@zidoo.tv>
Signed-off-by: Andreas Färber <afaerber@suse.de>
---
 v2 -> v3: unchanged
 
 v1 -> v2:
 * Changed subject
 * Extended commit message
 
 Documentation/devicetree/bindings/vendor-prefixes.txt | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt b/Documentation/devicetree/bindings/vendor-prefixes.txt
index c03d20140366..f032fa69f9d1 100644
--- a/Documentation/devicetree/bindings/vendor-prefixes.txt
+++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
@@ -356,6 +356,7 @@ xlnx	Xilinx
 xunlong	Shenzhen Xunlong Software CO.,Limited
 zarlink	Zarlink Semiconductor
 zeitec	ZEITEC Semiconductor Co., LTD.
+zidoo	Shenzhen Zidoo Technology Co., Ltd.
 zii	Zodiac Inflight Innovations
 zte	ZTE Corp.
 zyxel	ZyXEL Communications Corp.
-- 
2.12.0

[PATCH v3 2/5] dt-bindings: arm: Add Realtek RTD1295 bindings

[Andreas Färber]

The Zidoo X9S and a few other recent TV boxes feature the Realtek RTD1295,
a quad-core ARM Cortex-A53 SoC.

Acked-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: Roc He <hepeng@zidoo.tv>
Acked-by: Rob Herring <robh@kernel.org>
Signed-off-by: Andreas Färber <afaerber@suse.de>
---
 v2 -> v3: unchanged
 
 v1 -> v2:
 * Changed subject
 * Extended commit message
 * Clarified wording
 
 Documentation/devicetree/bindings/arm/realtek.txt | 20 ++++++++++++++++++++
 1 file changed, 20 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/arm/realtek.txt

diff --git a/Documentation/devicetree/bindings/arm/realtek.txt b/Documentation/devicetree/bindings/arm/realtek.txt
new file mode 100644
index 000000000000..13d755787b4f
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/realtek.txt
@@ -0,0 +1,20 @@
+Realtek platforms device tree bindings
+--------------------------------------
+
+
+RTD1295 SoC
+===========
+
+Required root node properties:
+
+ - compatible :  must contain "realtek,rtd1295"
+
+
+Root node property compatible must contain, depending on board:
+
+ - Zidoo X9S: "zidoo,x9s"
+
+
+Example:
+
+    compatible = "zidoo,x9s", "realtek,rtd1295";
-- 
2.12.0

[PATCH v3 3/5] ARM64: Prepare Realtek RTD1295

[Andreas Färber]

Add a Kconfig option ARCH_REALTEK.

Acked-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Andreas Färber <afaerber@suse.de>
---
 v1 -> v2 -> v3: unchanged
 
 arch/arm64/Kconfig.platforms | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/arch/arm64/Kconfig.platforms b/arch/arm64/Kconfig.platforms
index 73272f43ca01..b4e919ac73f6 100644
--- a/arch/arm64/Kconfig.platforms
+++ b/arch/arm64/Kconfig.platforms
@@ -126,6 +126,12 @@ config ARCH_QCOM
 	help
 	  This enables support for the ARMv8 based Qualcomm chipsets.
 
+config ARCH_REALTEK
+	bool "Realtek Platforms"
+	help
+	  This enables support for the ARMv8 based Realtek chipsets,
+	  like the RTD1295.
+
 config ARCH_ROCKCHIP
 	bool "Rockchip Platforms"
 	select ARCH_HAS_RESET_CONTROLLER
-- 
2.12.0

[PATCH v3 4/5] ARM64: dts: Add Realtek RTD1295 and Zidoo X9S

[Andreas Färber]

Add initial device trees for the RTD1295 SoC and the Zidoo X9S TV box.

The CPUs lack the enable-method property because the vendor device tree
uses a custom "rtk-spin-table" method and "psci" did not appear to work.

The UARTs lack the interrupts properties because the vendor device tree
connects them to a custom interrupt controller. earlycon works without.

A list of memory reservations is adopted from v1.2.11 vendor device tree:
0x02200000 can be used for an initrd, 0x01b00000 is audio-related;
ion-related 0x02600000, 0x02c00000 and 0x11000000 are left out;
0x10000000 is used for sharing the U-Boot environment; others remain
to be investigated.

Acked-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Andreas Färber <afaerber@suse.de>
---
 v2 -> v3:
 * Adopted SPDX-License-Identifier (Rob)
 * Added ranges for /soc node (Rob)
 * Changed #address-cells and #size-cells to 1 (Rob)
 
 v1 -> v2:
 * Dropped 0x0000000010000000 /memreserve/
 
 arch/arm64/boot/dts/Makefile                      |   1 +
 arch/arm64/boot/dts/realtek/Makefile              |   5 +
 arch/arm64/boot/dts/realtek/rtd1295-zidoo-x9s.dts |  42 +++++++
 arch/arm64/boot/dts/realtek/rtd1295.dtsi          | 131 ++++++++++++++++++++++
 4 files changed, 179 insertions(+)
 create mode 100644 arch/arm64/boot/dts/realtek/Makefile
 create mode 100644 arch/arm64/boot/dts/realtek/rtd1295-zidoo-x9s.dts
 create mode 100644 arch/arm64/boot/dts/realtek/rtd1295.dtsi

diff --git a/arch/arm64/boot/dts/Makefile b/arch/arm64/boot/dts/Makefile
index 080232b0270e..78f7991a5906 100644
--- a/arch/arm64/boot/dts/Makefile
+++ b/arch/arm64/boot/dts/Makefile
@@ -14,6 +14,7 @@ dts-dirs += marvell
 dts-dirs += mediatek
 dts-dirs += nvidia
 dts-dirs += qcom
+dts-dirs += realtek
 dts-dirs += renesas
 dts-dirs += rockchip
 dts-dirs += socionext
diff --git a/arch/arm64/boot/dts/realtek/Makefile b/arch/arm64/boot/dts/realtek/Makefile
new file mode 100644
index 000000000000..8521e921e59a
--- /dev/null
+++ b/arch/arm64/boot/dts/realtek/Makefile
@@ -0,0 +1,5 @@
+dtb-$(CONFIG_ARCH_REALTEK) += rtd1295-zidoo-x9s.dtb
+
+always		:= $(dtb-y)
+subdir-y	:= $(dts-dirs)
+clean-files	:= *.dtb
diff --git a/arch/arm64/boot/dts/realtek/rtd1295-zidoo-x9s.dts b/arch/arm64/boot/dts/realtek/rtd1295-zidoo-x9s.dts
new file mode 100644
index 000000000000..6efa8091bb30
--- /dev/null
+++ b/arch/arm64/boot/dts/realtek/rtd1295-zidoo-x9s.dts
@@ -0,0 +1,42 @@
+/*
+ * Copyright (c) 2016-2017 Andreas Färber
+ *
+ * SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+ */
+
+/dts-v1/;
+
+/memreserve/	0x0000000000000000 0x0000000000030000;
+/memreserve/	0x000000000001f000 0x0000000000001000;
+/memreserve/	0x0000000000030000 0x00000000000d0000;
+/memreserve/	0x0000000001b00000 0x00000000004be000;
+/memreserve/	0x0000000001ffe000 0x0000000000004000;
+
+#include "rtd1295.dtsi"
+
+/ {
+	compatible = "zidoo,x9s", "realtek,rtd1295";
+	model = "Zidoo X9S";
+
+	memory@0 {
+		device_type = "memory";
+		reg = <0x0 0x80000000>;
+	};
+
+	aliases {
+		serial0 = &uart0;
+		serial1 = &uart1;
+	};
+
+	chosen {
+		stdout-path = "serial0:115200n8";
+	};
+};
+
+&uart0 {
+	status = "okay";
+};
+
+&uart1 {
+	status = "okay";
+};
diff --git a/arch/arm64/boot/dts/realtek/rtd1295.dtsi b/arch/arm64/boot/dts/realtek/rtd1295.dtsi
new file mode 100644
index 000000000000..d8f84666c8ce
--- /dev/null
+++ b/arch/arm64/boot/dts/realtek/rtd1295.dtsi
@@ -0,0 +1,131 @@
+/*
+ * Realtek RTD1295 SoC
+ *
+ * Copyright (c) 2016-2017 Andreas Färber
+ *
+ * SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+ */
+
+#include <dt-bindings/interrupt-controller/arm-gic.h>
+
+/ {
+	compatible = "realtek,rtd1295";
+	interrupt-parent = <&gic>;
+	#address-cells = <1>;
+	#size-cells = <1>;
+
+	cpus {
+		#address-cells = <2>;
+		#size-cells = <0>;
+
+		cpu0: cpu@0 {
+			device_type = "cpu";
+			compatible = "arm,cortex-a53", "arm,armv8";
+			reg = <0x0 0x0>;
+			next-level-cache = <&l2>;
+		};
+
+		cpu1: cpu@1 {
+			device_type = "cpu";
+			compatible = "arm,cortex-a53", "arm,armv8";
+			reg = <0x0 0x1>;
+			next-level-cache = <&l2>;
+		};
+
+		cpu2: cpu@2 {
+			device_type = "cpu";
+			compatible = "arm,cortex-a53", "arm,armv8";
+			reg = <0x0 0x2>;
+			next-level-cache = <&l2>;
+		};
+
+		cpu3: cpu@3 {
+			device_type = "cpu";
+			compatible = "arm,cortex-a53", "arm,armv8";
+			reg = <0x0 0x3>;
+			next-level-cache = <&l2>;
+		};
+
+		l2: l2-cache {
+			compatible = "cache";
+		};
+	};
+
+	reserved-memory {
+		#address-cells = <1>;
+		#size-cells = <1>;
+		ranges;
+
+		tee@10100000 {
+			reg = <0x10100000 0xf00000>;
+			no-map;
+		};
+	};
+
+	arm-pmu {
+		compatible = "arm,cortex-a53-pmu";
+		interrupts = <GIC_SPI 48 IRQ_TYPE_LEVEL_HIGH>;
+		interrupt-affinity = <&cpu0>, <&cpu1>, <&cpu2>, <&cpu3>;
+	};
+
+	timer {
+		compatible = "arm,armv8-timer";
+		interrupts = <GIC_PPI 13
+			(GIC_CPU_MASK_RAW(0xf) | IRQ_TYPE_LEVEL_LOW)>,
+			     <GIC_PPI 14
+			(GIC_CPU_MASK_RAW(0xf) | IRQ_TYPE_LEVEL_LOW)>,
+			     <GIC_PPI 11
+			(GIC_CPU_MASK_RAW(0xf) | IRQ_TYPE_LEVEL_LOW)>,
+			     <GIC_PPI 10
+			(GIC_CPU_MASK_RAW(0xf) | IRQ_TYPE_LEVEL_LOW)>;
+	};
+
+	soc {
+		compatible = "simple-bus";
+		#address-cells = <1>;
+		#size-cells = <1>;
+		/* Exclude up to 2 GiB of RAM */
+		ranges = <0x80000000 0x80000000 0x80000000>;
+
+		uart0: serial@98007800 {
+			compatible = "snps,dw-apb-uart";
+			reg = <0x98007800 0x400>,
+			      <0x98007000 0x100>;
+			reg-shift = <2>;
+			reg-io-width = <4>;
+			clock-frequency = <27000000>;
+			status = "disabled";
+		};
+
+		uart1: serial@9801b200 {
+			compatible = "snps,dw-apb-uart";
+			reg = <0x9801b200 0x100>,
+			      <0x9801b00c 0x100>;
+			reg-shift = <2>;
+			reg-io-width = <4>;
+			clock-frequency = <432000000>;
+			status = "disabled";
+		};
+
+		uart2: serial@9801b400 {
+			compatible = "snps,dw-apb-uart";
+			reg = <0x9801b400 0x100>,
+			      <0x9801b00c 0x100>;
+			reg-shift = <2>;
+			reg-io-width = <4>;
+			clock-frequency = <432000000>;
+			status = "disabled";
+		};
+
+		gic: interrupt-controller@ff011000 {
+			compatible = "arm,gic-400";
+			reg = <0xff011000 0x1000>,
+			      <0xff012000 0x2000>,
+			      <0xff014000 0x2000>,
+			      <0xff016000 0x2000>;
+			interrupts = <GIC_PPI 9 (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_LOW)>;
+			interrupt-controller;
+			#interrupt-cells = <3>;
+		};
+	};
+};
-- 
2.12.0

[PATCH v3 5/5] MAINTAINERS: Add Realtek section

[Andreas Färber]

Add myself as maintainer.

Signed-off-by: Andreas Färber <afaerber@suse.de>
---
 v2 -> v3:
 * Changed status to Maintained
 
 v2: new
 
 MAINTAINERS | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index 5ae4f7975b19..92c65bbc4ef3 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1678,6 +1678,13 @@ M:	Lennert Buytenhek <kernel@wantstofly.org>
 L:	linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
 S:	Maintained
 
+ARM/REALTEK ARCHITECTURE
+M:	Andreas Färber <afaerber@suse.de>
+L:	linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
+S:	Maintained
+F:	arch/arm64/boot/dts/realtek/
+F:	Documentation/devicetree/bindings/arm/realtek.txt
+
 ARM/RENESAS ARM64 ARCHITECTURE
 M:	Simon Horman <horms@verge.net.au>
 M:	Magnus Damm <magnus.damm@gmail.com>
-- 
2.12.0

Re: [PATCH v3 4/5] ARM64: dts: Add Realtek RTD1295 and Zidoo X9S

[Rob Herring]

On Sat, May 13, 2017 at 9:24 PM, Andreas Färber <afaerber@suse.de> wrote:
> Add initial device trees for the RTD1295 SoC and the Zidoo X9S TV box.
>
> The CPUs lack the enable-method property because the vendor device tree
> uses a custom "rtk-spin-table" method and "psci" did not appear to work.
>
> The UARTs lack the interrupts properties because the vendor device tree
> connects them to a custom interrupt controller. earlycon works without.
>
> A list of memory reservations is adopted from v1.2.11 vendor device tree:
> 0x02200000 can be used for an initrd, 0x01b00000 is audio-related;
> ion-related 0x02600000, 0x02c00000 and 0x11000000 are left out;
> 0x10000000 is used for sharing the U-Boot environment; others remain
> to be investigated.
>
> Acked-by: Arnd Bergmann <arnd@arndb.de>
> Signed-off-by: Andreas Färber <afaerber@suse.de>
> ---
>  v2 -> v3:
>  * Adopted SPDX-License-Identifier (Rob)
>  * Added ranges for /soc node (Rob)
>  * Changed #address-cells and #size-cells to 1 (Rob)
>
>  v1 -> v2:
>  * Dropped 0x0000000010000000 /memreserve/
>
>  arch/arm64/boot/dts/Makefile                      |   1 +
>  arch/arm64/boot/dts/realtek/Makefile              |   5 +
>  arch/arm64/boot/dts/realtek/rtd1295-zidoo-x9s.dts |  42 +++++++
>  arch/arm64/boot/dts/realtek/rtd1295.dtsi          | 131 ++++++++++++++++++++++
>  4 files changed, 179 insertions(+)
>  create mode 100644 arch/arm64/boot/dts/realtek/Makefile
>  create mode 100644 arch/arm64/boot/dts/realtek/rtd1295-zidoo-x9s.dts
>  create mode 100644 arch/arm64/boot/dts/realtek/rtd1295.dtsi

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

Re: [PATCH v3 0/5] arm64: Initial Realtek RTD1295 enablement

[Andreas Färber]

Hi,

Am 14.05.2017 um 04:24 schrieb Andreas Färber:
> This mini-series adds initial support for the Realtek RTD1295 SoC and
> the Zidoo X9S TV box.
> 
> v3 changes #address-cells, #size-cells and ranges.
> 
> With these patches CPU0 can be booted with earlycon.
> 
> PSCI doesn't work despite present in the vendor device tree; as enable-method
> it instead used a custom "rtk-spin-table" that I sadly have no source code of.

Synology has now published source code for RTD1293/1296. This has
allowed me to narrow the RTD1295 CPU1..3 issue down to two changes in
arch/arm64/kernel/smp_spin_table.c:smp_spin_table_cpu_prepare():

1) writel_relaxed() instead of writeq_relaxed()
2) ioremap() instead of ioremap_cache()

Without those changes it hangs in earlycon after this line:
[    0.043674] Mountpoint-cache hash table entries: 4096 (order: 3,
32768 bytes)

The size difference sounds easy enough - we could introduce an optional
cpu-release-size property to handle this or derive a "spin-table-32bit"
enable-method to that effect.

The second one appears to be caused by PROT_NORMAL vs.
PROT_DEVICE_nGnRE. Is there any simple check we could do on
cpu-release-addr to choose which MT to use?

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit?id=113954c6463d1d80a206e91627ae49711f8b47cd

Any other ideas?

[...]
> The boot process is slightly twisted: The files need to be loaded from a
> 32-bit U-Boot, then boot into 64-bit U-Boot where the kernel can be booted.
> Similar to my previous Amlogic S905 work, the TEXT_OFFSET poses a problem, so
> a uImage needs to be used (or the kernel patched) for load address 0x00280000.
> I haven't succeeded loading an initrd via bootm/booti; but as quick workaround
> initrd=$rootfs_loadaddr,0x$filesize can manually be specified in $bootargs.
> 
> Cf. https://en.opensuse.org/HCL:Zidoo_X9S
> 
> More experimental patches at:
> https://github.com/afaerber/linux/commits/rtd1295-next
[snip]

My above branch includes the above spin-table hack for now.

Regards,
Andreas

-- 
SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nürnberg)

Re: [PATCH v3 0/5] arm64: Initial Realtek RTD1295 enablement

[Arnd Bergmann]

On Tue, Sep 5, 2017 at 12:09 AM, Andreas Färber <afaerber@suse.de> wrote:
> Am 14.05.2017 um 04:24 schrieb Andreas Färber:
>> This mini-series adds initial support for the Realtek RTD1295 SoC and
>> the Zidoo X9S TV box.
>>
>> v3 changes #address-cells, #size-cells and ranges.
>>
>> With these patches CPU0 can be booted with earlycon.
>>
>> PSCI doesn't work despite present in the vendor device tree; as enable-method
>> it instead used a custom "rtk-spin-table" that I sadly have no source code of.
>
> Synology has now published source code for RTD1293/1296. This has
> allowed me to narrow the RTD1295 CPU1..3 issue down to two changes in
> arch/arm64/kernel/smp_spin_table.c:smp_spin_table_cpu_prepare():
>
> 1) writel_relaxed() instead of writeq_relaxed()
> 2) ioremap() instead of ioremap_cache()
>
> Without those changes it hangs in earlycon after this line:
> [    0.043674] Mountpoint-cache hash table entries: 4096 (order: 3,
> 32768 bytes)
>
> The size difference sounds easy enough - we could introduce an optional
> cpu-release-size property to handle this or derive a "spin-table-32bit"
> enable-method to that effect.
>
> The second one appears to be caused by PROT_NORMAL vs.
> PROT_DEVICE_nGnRE. Is there any simple check we could do on
> cpu-release-addr to choose which MT to use?
>
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit?id=113954c6463d1d80a206e91627ae49711f8b47cd
>
> Any other ideas?

I think we had a similar problem before and concluded that something
requiring a write into an MMIO register is simply not a spin-table
implementation but something else.

Is this simply using a copy of the spin-table code to trigger the actual
booting of the secondary CPU? Can you identify the MMIO address?

      Arnd

Re: [PATCH v3 0/5] arm64: Initial Realtek RTD1295 enablement

[Andreas Färber]

Am 05.09.2017 um 09:18 schrieb Arnd Bergmann:
> On Tue, Sep 5, 2017 at 12:09 AM, Andreas Färber <afaerber@suse.de> wrote:
>> Am 14.05.2017 um 04:24 schrieb Andreas Färber:
>>> This mini-series adds initial support for the Realtek RTD1295 SoC and
>>> the Zidoo X9S TV box.
>>>
>>> v3 changes #address-cells, #size-cells and ranges.
>>>
>>> With these patches CPU0 can be booted with earlycon.
>>>
>>> PSCI doesn't work despite present in the vendor device tree; as enable-method
>>> it instead used a custom "rtk-spin-table" that I sadly have no source code of.
>>
>> Synology has now published source code for RTD1293/1296. This has
>> allowed me to narrow the RTD1295 CPU1..3 issue down to two changes in
>> arch/arm64/kernel/smp_spin_table.c:smp_spin_table_cpu_prepare():
>>
>> 1) writel_relaxed() instead of writeq_relaxed()
>> 2) ioremap() instead of ioremap_cache()
>>
>> Without those changes it hangs in earlycon after this line:
>> [    0.043674] Mountpoint-cache hash table entries: 4096 (order: 3,
>> 32768 bytes)
>>
>> The size difference sounds easy enough - we could introduce an optional
>> cpu-release-size property to handle this or derive a "spin-table-32bit"
>> enable-method to that effect.
>>
>> The second one appears to be caused by PROT_NORMAL vs.
>> PROT_DEVICE_nGnRE. Is there any simple check we could do on
>> cpu-release-addr to choose which MT to use?
>>
>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit?id=113954c6463d1d80a206e91627ae49711f8b47cd
>>
>> Any other ideas?
> 
> I think we had a similar problem before and concluded that something
> requiring a write into an MMIO register is simply not a spin-table
> implementation but something else.

Well, my understanding was that "something else" is not acceptable for
arm64. And still being without ATF, U-Boot and OP-TEE sources I don't
see how I could reimplement PSCI instead.

> Is this simply using a copy of the spin-table code to trigger the actual
> booting of the secondary CPU?

Yes. Realtek have duplicated and modified the file - I've instead tried
to reuse the existing code with those minimal changes, for a chance to
get this mainline with suitable conditions.

The only other Realtek changes are additions for cpu_disable/cpu_die
that I am ignoring for now. Happy that the cores are finally up!

> Can you identify the MMIO address?

The magic 32-bit register is 0x9801aa44, with RAM being 0..0x80000000.

Thus I was hoping there might be some handy is_ram_addr(phys_addr) that
we could use in generic code to choose the right ioremap function.

Regards,
Andreas

-- 
SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nürnberg)