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

[Andreas Färber]

Add a Kconfig option ARCH_REALTEK.

Acked-by: Arnd Bergmann <ar...@arndb.de>
Signed-off-by: Andreas Färber <afae...@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

[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 a...@kernel.org again (Olof)

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

Cc: Arnd Bergmann <ar...@arndb.de>
Cc: Olof Johansson <ol...@lixom.net>
Cc: Roc He <hep...@zidoo.tv>
Cc: devic...@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

[Andreas Färber]

Add myself as maintainer.

Signed-off-by: Andreas Färber <afae...@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 <ker...@wantstofly.org>
L: linux-ar...@lists.infradead.org (moderated for non-subscribers)
S: Maintained

+ARM/REALTEK ARCHITECTURE
+M: Andreas Färber <afae...@suse.de>
+L: linux-ar...@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 <ho...@verge.net.au>
M: Magnus Damm <magnu...@gmail.com>
--
2.12.0

[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 <ar...@arndb.de>

Signed-off-by: Andreas Färber <afae...@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

[Rob Herring]

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

[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)

[Arnd Bergmann]

On Tue, Sep 5, 2017 at 12:09 AM, Andreas Färber <afae...@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

[Andreas Färber]

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.