This series restructures the Juno DT files and introduces the DT
for the new Juno R1. The board is an update of the Juno R0 with
support for PCIe, but the current series only brings the board to
parity with Juno R0. The series that enable the PCIe Generic Host
Bridge to be used on Juno R1 will be posted separately.
Liviu Dudau (5):
arm64: Juno: Fix the GIC node address label and the frequency of FAXI clock.
arm64: Juno: Split juno.dts into juno-base.dtsi and juno.dts.
arm64: Juno: Add memory mapped timer node
arm64: Juno: Add GICv2m support in device tree.
arm64: Add DT support for Juno r1 board.
arch/arm64/boot/dts/arm/Makefile | 2 +-
arch/arm64/boot/dts/arm/juno-base.dtsi | 147 +++++++++++++++++++++++++++++++
arch/arm64/boot/dts/arm/juno-clocks.dtsi | 4 +-
arch/arm64/boot/dts/arm/juno-r1.dts | 123 ++++++++++++++++++++++++++
arch/arm64/boot/dts/arm/juno.dts | 122 +------------------------
5 files changed, 274 insertions(+), 124 deletions(-)
create mode 100644 arch/arm64/boot/dts/arm/juno-base.dtsi
create mode 100644 arch/arm64/boot/dts/arm/juno-r1.dts
--
2.3.6
During the review of the Juno DT files I've noticed that the GIC
node label had two digits swapped leading to a different address
being shown in the /sys/devices fs.
Sudeep also pointed that public revisions of the Juno documentation
list a different frequency for the FAXI system than what the one
I've been using when creating the DT file. Verified with the firmware
people to be the correct value in the shipped systems.
Reported-by: Sudeep Holla <[email protected]>
Signed-off-by: Liviu Dudau <[email protected]>
---
arch/arm64/boot/dts/arm/juno-clocks.dtsi | 4 ++--
arch/arm64/boot/dts/arm/juno.dts | 2 +-
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/arm64/boot/dts/arm/juno-clocks.dtsi b/arch/arm64/boot/dts/arm/juno-clocks.dtsi
index c9b89ef..25352ed 100644
--- a/arch/arm64/boot/dts/arm/juno-clocks.dtsi
+++ b/arch/arm64/boot/dts/arm/juno-clocks.dtsi
@@ -36,9 +36,9 @@
clock-output-names = "apb_pclk";
};
- soc_faxiclk: refclk533mhz {
+ soc_faxiclk: refclk400mhz {
compatible = "fixed-clock";
#clock-cells = <0>;
- clock-frequency = <533000000>;
+ clock-frequency = <400000000>;
clock-output-names = "faxi_clk";
};
diff --git a/arch/arm64/boot/dts/arm/juno.dts b/arch/arm64/boot/dts/arm/juno.dts
index 5e9110a..7ab0713 100644
--- a/arch/arm64/boot/dts/arm/juno.dts
+++ b/arch/arm64/boot/dts/arm/juno.dts
@@ -98,7 +98,7 @@
<0x00000008 0x80000000 0x1 0x80000000>;
};
- gic: interrupt-controller@2c001000 {
+ gic: interrupt-controller@2c010000 {
compatible = "arm,gic-400", "arm,cortex-a15-gic";
reg = <0x0 0x2c010000 0 0x1000>,
<0x0 0x2c02f000 0 0x2000>,
--
2.3.6
Prepare the device tree for adding more boards based on Juno r0.
Signed-off-by: Liviu Dudau <[email protected]>
---
arch/arm64/boot/dts/arm/juno-base.dtsi | 125 +++++++++++++++++++++++++++++++++
arch/arm64/boot/dts/arm/juno.dts | 122 +-------------------------------
2 files changed, 126 insertions(+), 121 deletions(-)
create mode 100644 arch/arm64/boot/dts/arm/juno-base.dtsi
diff --git a/arch/arm64/boot/dts/arm/juno-base.dtsi b/arch/arm64/boot/dts/arm/juno-base.dtsi
new file mode 100644
index 0000000..2faa68a
--- /dev/null
+++ b/arch/arm64/boot/dts/arm/juno-base.dtsi
@@ -0,0 +1,125 @@
+ /*
+ * Devices shared by all Juno boards
+ */
+
+ gic: interrupt-controller@2c010000 {
+ compatible = "arm,gic-400", "arm,cortex-a15-gic";
+ reg = <0x0 0x2c010000 0 0x1000>,
+ <0x0 0x2c02f000 0 0x2000>,
+ <0x0 0x2c04f000 0 0x2000>,
+ <0x0 0x2c06f000 0 0x2000>;
+ #address-cells = <0>;
+ #interrupt-cells = <3>;
+ interrupt-controller;
+ interrupts = <GIC_PPI 9 (GIC_CPU_MASK_SIMPLE(6) | IRQ_TYPE_LEVEL_HIGH)>;
+ };
+
+ timer {
+ compatible = "arm,armv8-timer";
+ interrupts = <GIC_PPI 13 (GIC_CPU_MASK_SIMPLE(6) | IRQ_TYPE_LEVEL_LOW)>,
+ <GIC_PPI 14 (GIC_CPU_MASK_SIMPLE(6) | IRQ_TYPE_LEVEL_LOW)>,
+ <GIC_PPI 11 (GIC_CPU_MASK_SIMPLE(6) | IRQ_TYPE_LEVEL_LOW)>,
+ <GIC_PPI 10 (GIC_CPU_MASK_SIMPLE(6) | IRQ_TYPE_LEVEL_LOW)>;
+ };
+
+ /include/ "juno-clocks.dtsi"
+
+ dma@7ff00000 {
+ compatible = "arm,pl330", "arm,primecell";
+ reg = <0x0 0x7ff00000 0 0x1000>;
+ #dma-cells = <1>;
+ #dma-channels = <8>;
+ #dma-requests = <32>;
+ interrupts = <GIC_SPI 88 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 89 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 90 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 91 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 108 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 109 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 110 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 111 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&soc_faxiclk>;
+ clock-names = "apb_pclk";
+ };
+
+ soc_uart0: uart@7ff80000 {
+ compatible = "arm,pl011", "arm,primecell";
+ reg = <0x0 0x7ff80000 0x0 0x1000>;
+ interrupts = <GIC_SPI 83 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&soc_uartclk>, <&soc_refclk100mhz>;
+ clock-names = "uartclk", "apb_pclk";
+ };
+
+ i2c@7ffa0000 {
+ compatible = "snps,designware-i2c";
+ reg = <0x0 0x7ffa0000 0x0 0x1000>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ interrupts = <GIC_SPI 104 IRQ_TYPE_LEVEL_HIGH>;
+ clock-frequency = <400000>;
+ i2c-sda-hold-time-ns = <500>;
+ clocks = <&soc_smc50mhz>;
+
+ dvi0: dvi-transmitter@70 {
+ compatible = "nxp,tda998x";
+ reg = <0x70>;
+ };
+
+ dvi1: dvi-transmitter@71 {
+ compatible = "nxp,tda998x";
+ reg = <0x71>;
+ };
+ };
+
+ ohci@7ffb0000 {
+ compatible = "generic-ohci";
+ reg = <0x0 0x7ffb0000 0x0 0x10000>;
+ interrupts = <GIC_SPI 116 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&soc_usb48mhz>;
+ };
+
+ ehci@7ffc0000 {
+ compatible = "generic-ehci";
+ reg = <0x0 0x7ffc0000 0x0 0x10000>;
+ interrupts = <GIC_SPI 117 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&soc_usb48mhz>;
+ };
+
+ memory-controller@7ffd0000 {
+ compatible = "arm,pl354", "arm,primecell";
+ reg = <0 0x7ffd0000 0 0x1000>;
+ interrupts = <GIC_SPI 86 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 87 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&soc_smc50mhz>;
+ clock-names = "apb_pclk";
+ };
+
+ smb {
+ compatible = "simple-bus";
+ #address-cells = <2>;
+ #size-cells = <1>;
+ ranges = <0 0 0 0x08000000 0x04000000>,
+ <1 0 0 0x14000000 0x04000000>,
+ <2 0 0 0x18000000 0x04000000>,
+ <3 0 0 0x1c000000 0x04000000>,
+ <4 0 0 0x0c000000 0x04000000>,
+ <5 0 0 0x10000000 0x04000000>;
+
+ #interrupt-cells = <1>;
+ interrupt-map-mask = <0 0 15>;
+ interrupt-map = <0 0 0 &gic 0 68 IRQ_TYPE_LEVEL_HIGH>,
+ <0 0 1 &gic 0 69 IRQ_TYPE_LEVEL_HIGH>,
+ <0 0 2 &gic 0 70 IRQ_TYPE_LEVEL_HIGH>,
+ <0 0 3 &gic 0 160 IRQ_TYPE_LEVEL_HIGH>,
+ <0 0 4 &gic 0 161 IRQ_TYPE_LEVEL_HIGH>,
+ <0 0 5 &gic 0 162 IRQ_TYPE_LEVEL_HIGH>,
+ <0 0 6 &gic 0 163 IRQ_TYPE_LEVEL_HIGH>,
+ <0 0 7 &gic 0 164 IRQ_TYPE_LEVEL_HIGH>,
+ <0 0 8 &gic 0 165 IRQ_TYPE_LEVEL_HIGH>,
+ <0 0 9 &gic 0 166 IRQ_TYPE_LEVEL_HIGH>,
+ <0 0 10 &gic 0 167 IRQ_TYPE_LEVEL_HIGH>,
+ <0 0 11 &gic 0 168 IRQ_TYPE_LEVEL_HIGH>,
+ <0 0 12 &gic 0 169 IRQ_TYPE_LEVEL_HIGH>;
+
+ /include/ "juno-motherboard.dtsi"
+ };
diff --git a/arch/arm64/boot/dts/arm/juno.dts b/arch/arm64/boot/dts/arm/juno.dts
index 7ab0713..60e8928 100644
--- a/arch/arm64/boot/dts/arm/juno.dts
+++ b/arch/arm64/boot/dts/arm/juno.dts
@@ -98,26 +98,6 @@
<0x00000008 0x80000000 0x1 0x80000000>;
};
- gic: interrupt-controller@2c010000 {
- compatible = "arm,gic-400", "arm,cortex-a15-gic";
- reg = <0x0 0x2c010000 0 0x1000>,
- <0x0 0x2c02f000 0 0x2000>,
- <0x0 0x2c04f000 0 0x2000>,
- <0x0 0x2c06f000 0 0x2000>;
- #address-cells = <0>;
- #interrupt-cells = <3>;
- interrupt-controller;
- interrupts = <GIC_PPI 9 (GIC_CPU_MASK_SIMPLE(6) | IRQ_TYPE_LEVEL_HIGH)>;
- };
-
- timer {
- compatible = "arm,armv8-timer";
- interrupts = <GIC_PPI 13 (GIC_CPU_MASK_SIMPLE(6) | IRQ_TYPE_LEVEL_LOW)>,
- <GIC_PPI 14 (GIC_CPU_MASK_SIMPLE(6) | IRQ_TYPE_LEVEL_LOW)>,
- <GIC_PPI 11 (GIC_CPU_MASK_SIMPLE(6) | IRQ_TYPE_LEVEL_LOW)>,
- <GIC_PPI 10 (GIC_CPU_MASK_SIMPLE(6) | IRQ_TYPE_LEVEL_LOW)>;
- };
-
pmu {
compatible = "arm,armv8-pmuv3";
interrupts = <GIC_SPI 02 IRQ_TYPE_LEVEL_HIGH>,
@@ -134,105 +114,5 @@
<&A53_3>;
};
- /include/ "juno-clocks.dtsi"
-
- dma@7ff00000 {
- compatible = "arm,pl330", "arm,primecell";
- reg = <0x0 0x7ff00000 0 0x1000>;
- #dma-cells = <1>;
- #dma-channels = <8>;
- #dma-requests = <32>;
- interrupts = <GIC_SPI 88 IRQ_TYPE_LEVEL_HIGH>,
- <GIC_SPI 89 IRQ_TYPE_LEVEL_HIGH>,
- <GIC_SPI 90 IRQ_TYPE_LEVEL_HIGH>,
- <GIC_SPI 91 IRQ_TYPE_LEVEL_HIGH>,
- <GIC_SPI 108 IRQ_TYPE_LEVEL_HIGH>,
- <GIC_SPI 109 IRQ_TYPE_LEVEL_HIGH>,
- <GIC_SPI 110 IRQ_TYPE_LEVEL_HIGH>,
- <GIC_SPI 111 IRQ_TYPE_LEVEL_HIGH>;
- clocks = <&soc_faxiclk>;
- clock-names = "apb_pclk";
- };
-
- soc_uart0: uart@7ff80000 {
- compatible = "arm,pl011", "arm,primecell";
- reg = <0x0 0x7ff80000 0x0 0x1000>;
- interrupts = <GIC_SPI 83 IRQ_TYPE_LEVEL_HIGH>;
- clocks = <&soc_uartclk>, <&soc_refclk100mhz>;
- clock-names = "uartclk", "apb_pclk";
- };
-
- i2c@7ffa0000 {
- compatible = "snps,designware-i2c";
- reg = <0x0 0x7ffa0000 0x0 0x1000>;
- #address-cells = <1>;
- #size-cells = <0>;
- interrupts = <GIC_SPI 104 IRQ_TYPE_LEVEL_HIGH>;
- clock-frequency = <400000>;
- i2c-sda-hold-time-ns = <500>;
- clocks = <&soc_smc50mhz>;
-
- dvi0: dvi-transmitter@70 {
- compatible = "nxp,tda998x";
- reg = <0x70>;
- };
-
- dvi1: dvi-transmitter@71 {
- compatible = "nxp,tda998x";
- reg = <0x71>;
- };
- };
-
- ohci@7ffb0000 {
- compatible = "generic-ohci";
- reg = <0x0 0x7ffb0000 0x0 0x10000>;
- interrupts = <GIC_SPI 116 IRQ_TYPE_LEVEL_HIGH>;
- clocks = <&soc_usb48mhz>;
- };
-
- ehci@7ffc0000 {
- compatible = "generic-ehci";
- reg = <0x0 0x7ffc0000 0x0 0x10000>;
- interrupts = <GIC_SPI 117 IRQ_TYPE_LEVEL_HIGH>;
- clocks = <&soc_usb48mhz>;
- };
-
- memory-controller@7ffd0000 {
- compatible = "arm,pl354", "arm,primecell";
- reg = <0 0x7ffd0000 0 0x1000>;
- interrupts = <GIC_SPI 86 IRQ_TYPE_LEVEL_HIGH>,
- <GIC_SPI 87 IRQ_TYPE_LEVEL_HIGH>;
- clocks = <&soc_smc50mhz>;
- clock-names = "apb_pclk";
- };
-
- smb {
- compatible = "simple-bus";
- #address-cells = <2>;
- #size-cells = <1>;
- ranges = <0 0 0 0x08000000 0x04000000>,
- <1 0 0 0x14000000 0x04000000>,
- <2 0 0 0x18000000 0x04000000>,
- <3 0 0 0x1c000000 0x04000000>,
- <4 0 0 0x0c000000 0x04000000>,
- <5 0 0 0x10000000 0x04000000>;
-
- #interrupt-cells = <1>;
- interrupt-map-mask = <0 0 15>;
- interrupt-map = <0 0 0 &gic 0 68 IRQ_TYPE_LEVEL_HIGH>,
- <0 0 1 &gic 0 69 IRQ_TYPE_LEVEL_HIGH>,
- <0 0 2 &gic 0 70 IRQ_TYPE_LEVEL_HIGH>,
- <0 0 3 &gic 0 160 IRQ_TYPE_LEVEL_HIGH>,
- <0 0 4 &gic 0 161 IRQ_TYPE_LEVEL_HIGH>,
- <0 0 5 &gic 0 162 IRQ_TYPE_LEVEL_HIGH>,
- <0 0 6 &gic 0 163 IRQ_TYPE_LEVEL_HIGH>,
- <0 0 7 &gic 0 164 IRQ_TYPE_LEVEL_HIGH>,
- <0 0 8 &gic 0 165 IRQ_TYPE_LEVEL_HIGH>,
- <0 0 9 &gic 0 166 IRQ_TYPE_LEVEL_HIGH>,
- <0 0 10 &gic 0 167 IRQ_TYPE_LEVEL_HIGH>,
- <0 0 11 &gic 0 168 IRQ_TYPE_LEVEL_HIGH>,
- <0 0 12 &gic 0 169 IRQ_TYPE_LEVEL_HIGH>;
-
- /include/ "juno-motherboard.dtsi"
- };
+ #include "juno-base.dtsi"
};
--
2.3.6
Juno based boards have a memory mapped timer @ 0x2a810000. This
is disabled on r0 version of the board due to an SoC errata.
Signed-off-by: Liviu Dudau <[email protected]>
---
arch/arm64/boot/dts/arm/juno-base.dtsi | 15 +++++++++++++++
1 file changed, 15 insertions(+)
diff --git a/arch/arm64/boot/dts/arm/juno-base.dtsi b/arch/arm64/boot/dts/arm/juno-base.dtsi
index 2faa68a..78f8a07 100644
--- a/arch/arm64/boot/dts/arm/juno-base.dtsi
+++ b/arch/arm64/boot/dts/arm/juno-base.dtsi
@@ -2,6 +2,21 @@
* Devices shared by all Juno boards
*/
+ memtimer: timer@2a810000 {
+ compatible = "arm,armv7-timer-mem";
+ reg = <0x0 0x2a810000 0x0 0x10000>;
+ clock-frequency = <50000000>;
+ #address-cells = <2>;
+ #size-cells = <2>;
+ ranges;
+ status = "disabled";
+ frame@2a830000 {
+ frame-number = <1>;
+ interrupts = <0 60 4>;
+ reg = <0x0 0x2a830000 0x0 0x10000>;
+ };
+ };
+
gic: interrupt-controller@2c010000 {
compatible = "arm,gic-400", "arm,cortex-a15-gic";
reg = <0x0 0x2c010000 0 0x1000>,
--
2.3.6
Juno contains a GICv2m extension for handling PCIe MSI messages.
Add a node declaring the first frame of the extension.
Signed-off-by: Liviu Dudau <[email protected]>
---
arch/arm64/boot/dts/arm/juno-base.dtsi | 35 ++++++++++++++++++++--------------
1 file changed, 21 insertions(+), 14 deletions(-)
diff --git a/arch/arm64/boot/dts/arm/juno-base.dtsi b/arch/arm64/boot/dts/arm/juno-base.dtsi
index 78f8a07..e6a4e99 100644
--- a/arch/arm64/boot/dts/arm/juno-base.dtsi
+++ b/arch/arm64/boot/dts/arm/juno-base.dtsi
@@ -23,10 +23,17 @@
<0x0 0x2c02f000 0 0x2000>,
<0x0 0x2c04f000 0 0x2000>,
<0x0 0x2c06f000 0 0x2000>;
- #address-cells = <0>;
+ #address-cells = <2>;
#interrupt-cells = <3>;
+ #size-cells = <2>;
interrupt-controller;
interrupts = <GIC_PPI 9 (GIC_CPU_MASK_SIMPLE(6) | IRQ_TYPE_LEVEL_HIGH)>;
+ ranges = <0 0 0 0x2c1c0000 0 0x40000>;
+ v2m_0: v2m@0 {
+ compatible = "arm,gic-v2m-frame";
+ msi-controller;
+ reg = <0 0 0 0x1000>;
+ };
};
timer {
@@ -122,19 +129,19 @@
#interrupt-cells = <1>;
interrupt-map-mask = <0 0 15>;
- interrupt-map = <0 0 0 &gic 0 68 IRQ_TYPE_LEVEL_HIGH>,
- <0 0 1 &gic 0 69 IRQ_TYPE_LEVEL_HIGH>,
- <0 0 2 &gic 0 70 IRQ_TYPE_LEVEL_HIGH>,
- <0 0 3 &gic 0 160 IRQ_TYPE_LEVEL_HIGH>,
- <0 0 4 &gic 0 161 IRQ_TYPE_LEVEL_HIGH>,
- <0 0 5 &gic 0 162 IRQ_TYPE_LEVEL_HIGH>,
- <0 0 6 &gic 0 163 IRQ_TYPE_LEVEL_HIGH>,
- <0 0 7 &gic 0 164 IRQ_TYPE_LEVEL_HIGH>,
- <0 0 8 &gic 0 165 IRQ_TYPE_LEVEL_HIGH>,
- <0 0 9 &gic 0 166 IRQ_TYPE_LEVEL_HIGH>,
- <0 0 10 &gic 0 167 IRQ_TYPE_LEVEL_HIGH>,
- <0 0 11 &gic 0 168 IRQ_TYPE_LEVEL_HIGH>,
- <0 0 12 &gic 0 169 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-map = <0 0 0 &gic 0 0 0 68 IRQ_TYPE_LEVEL_HIGH>,
+ <0 0 1 &gic 0 0 0 69 IRQ_TYPE_LEVEL_HIGH>,
+ <0 0 2 &gic 0 0 0 70 IRQ_TYPE_LEVEL_HIGH>,
+ <0 0 3 &gic 0 0 0 160 IRQ_TYPE_LEVEL_HIGH>,
+ <0 0 4 &gic 0 0 0 161 IRQ_TYPE_LEVEL_HIGH>,
+ <0 0 5 &gic 0 0 0 162 IRQ_TYPE_LEVEL_HIGH>,
+ <0 0 6 &gic 0 0 0 163 IRQ_TYPE_LEVEL_HIGH>,
+ <0 0 7 &gic 0 0 0 164 IRQ_TYPE_LEVEL_HIGH>,
+ <0 0 8 &gic 0 0 0 165 IRQ_TYPE_LEVEL_HIGH>,
+ <0 0 9 &gic 0 0 0 166 IRQ_TYPE_LEVEL_HIGH>,
+ <0 0 10 &gic 0 0 0 167 IRQ_TYPE_LEVEL_HIGH>,
+ <0 0 11 &gic 0 0 0 168 IRQ_TYPE_LEVEL_HIGH>,
+ <0 0 12 &gic 0 0 0 169 IRQ_TYPE_LEVEL_HIGH>;
/include/ "juno-motherboard.dtsi"
};
--
2.3.6
This board is based on Juno r0 with updated Cortex A5x revisions
and board errata fixes. It also contains coherent ThinLinks ports
on the expansion slot that allow for an AXI master on the daughter
card to participate in a coherency domain.
Support for SoC PCIe host bridge will be added as a separate series.
Signed-off-by: Liviu Dudau <[email protected]>
---
arch/arm64/boot/dts/arm/Makefile | 2 +-
arch/arm64/boot/dts/arm/juno-r1.dts | 123 ++++++++++++++++++++++++++++++++++++
2 files changed, 124 insertions(+), 1 deletion(-)
create mode 100644 arch/arm64/boot/dts/arm/juno-r1.dts
diff --git a/arch/arm64/boot/dts/arm/Makefile b/arch/arm64/boot/dts/arm/Makefile
index 301a0da..c5c98b9 100644
--- a/arch/arm64/boot/dts/arm/Makefile
+++ b/arch/arm64/boot/dts/arm/Makefile
@@ -1,5 +1,5 @@
dtb-$(CONFIG_ARCH_VEXPRESS) += foundation-v8.dtb
-dtb-$(CONFIG_ARCH_VEXPRESS) += juno.dtb
+dtb-$(CONFIG_ARCH_VEXPRESS) += juno.dtb juno-r1.dtb
dtb-$(CONFIG_ARCH_VEXPRESS) += rtsm_ve-aemv8a.dtb
always := $(dtb-y)
diff --git a/arch/arm64/boot/dts/arm/juno-r1.dts b/arch/arm64/boot/dts/arm/juno-r1.dts
new file mode 100644
index 0000000..f6bc073
--- /dev/null
+++ b/arch/arm64/boot/dts/arm/juno-r1.dts
@@ -0,0 +1,123 @@
+/*
+ * ARM Ltd. Juno Platform
+ *
+ * Copyright (c) 2015 ARM Ltd.
+ *
+ * This file is licensed under a dual GPLv2 or BSD license.
+ */
+
+/dts-v1/;
+
+#include <dt-bindings/interrupt-controller/arm-gic.h>
+
+/ {
+ model = "ARM Juno development board (r1)";
+ compatible = "arm,juno", "arm,vexpress";
+ interrupt-parent = <&gic>;
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ aliases {
+ serial0 = &soc_uart0;
+ };
+
+ chosen {
+ stdout-path = "serial0:115200n8";
+ };
+
+ psci {
+ compatible = "arm,psci-0.2";
+ method = "smc";
+ };
+
+ cpus {
+ #address-cells = <2>;
+ #size-cells = <0>;
+
+ A57_0: cpu@0 {
+ compatible = "arm,cortex-a57","arm,armv8";
+ reg = <0x0 0x0>;
+ device_type = "cpu";
+ enable-method = "psci";
+ next-level-cache = <&A57_L2>;
+ };
+
+ A57_1: cpu@1 {
+ compatible = "arm,cortex-a57","arm,armv8";
+ reg = <0x0 0x1>;
+ device_type = "cpu";
+ enable-method = "psci";
+ next-level-cache = <&A57_L2>;
+ };
+
+ A53_0: cpu@100 {
+ compatible = "arm,cortex-a53","arm,armv8";
+ reg = <0x0 0x100>;
+ device_type = "cpu";
+ enable-method = "psci";
+ next-level-cache = <&A53_L2>;
+ };
+
+ A53_1: cpu@101 {
+ compatible = "arm,cortex-a53","arm,armv8";
+ reg = <0x0 0x101>;
+ device_type = "cpu";
+ enable-method = "psci";
+ next-level-cache = <&A53_L2>;
+ };
+
+ A53_2: cpu@102 {
+ compatible = "arm,cortex-a53","arm,armv8";
+ reg = <0x0 0x102>;
+ device_type = "cpu";
+ enable-method = "psci";
+ next-level-cache = <&A53_L2>;
+ };
+
+ A53_3: cpu@103 {
+ compatible = "arm,cortex-a53","arm,armv8";
+ reg = <0x0 0x103>;
+ device_type = "cpu";
+ enable-method = "psci";
+ next-level-cache = <&A53_L2>;
+ };
+
+ A57_L2: l2-cache0 {
+ compatible = "cache";
+ };
+
+ A53_L2: l2-cache1 {
+ compatible = "cache";
+ };
+ };
+
+ memory@80000000 {
+ device_type = "memory";
+ /* last 16MB of the first memory area is reserved for secure world use by firmware */
+ reg = <0x00000000 0x80000000 0x0 0x7f000000>,
+ <0x00000008 0x80000000 0x1 0x80000000>;
+ };
+
+ pmu {
+ compatible = "arm,armv8-pmuv3";
+ interrupts = <GIC_SPI 02 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 06 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 18 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 22 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 26 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 30 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-affinity = <&A57_0>,
+ <&A57_1>,
+ <&A53_0>,
+ <&A53_1>,
+ <&A53_2>,
+ <&A53_3>;
+ };
+
+ #include "juno-base.dtsi"
+
+};
+
+&memtimer {
+ status = "okay";
+};
--
2.3.6
On Wed, 2015-05-13 at 18:11 +0100, Liviu Dudau wrote:
> Prepare the device tree for adding more boards based on Juno r0.
>
> Signed-off-by: Liviu Dudau <[email protected]>
> ---
> arch/arm64/boot/dts/arm/juno-base.dtsi | 125 +++++++++++++++++++++++++++++++++
> arch/arm64/boot/dts/arm/juno.dts | 122 +-------------------------------
What criteria were used to select the contents of juno-base.dtsi?
>From what I can see, the stuff left out of base is still the same for r0
and r1 (cpu, pmu, memory, psci!). And so juno-r1.dts could just be
-------------------------------------------------------------------------
#include "juno.dts"
/ {
model = "ARM Juno development board (r1)";
};
&memtimer {
status = "okay";
};
-------------------------------------------------------------------------
Yes, it's a bit hacky, but avoids duplication of source code.
I can only assume there are come non-public differences between r0 and
r1?
--
Tixy
On Thu, May 14, 2015 at 10:35:42AM +0100, Jon Medhurst (Tixy) wrote:
> On Wed, 2015-05-13 at 18:11 +0100, Liviu Dudau wrote:
> > Prepare the device tree for adding more boards based on Juno r0.
> >
> > Signed-off-by: Liviu Dudau <[email protected]>
> > ---
> > arch/arm64/boot/dts/arm/juno-base.dtsi | 125 +++++++++++++++++++++++++++++++++
> > arch/arm64/boot/dts/arm/juno.dts | 122 +-------------------------------
>
>
> What criteria were used to select the contents of juno-base.dtsi?
> From what I can see, the stuff left out of base is still the same for r0
> and r1 (cpu, pmu, memory, psci!). And so juno-r1.dts could just be
>
> -------------------------------------------------------------------------
> #include "juno.dts"
>
> / {
> model = "ARM Juno development board (r1)";
>
> };
>
> &memtimer {
> status = "okay";
> };
> -------------------------------------------------------------------------
>
> Yes, it's a bit hacky, but avoids duplication of source code.
>
> I can only assume there are come non-public differences between r0 and
> r1?
Hi Tixy,
There are potential differences. Cortex-A53 cluster in r1 has limited
CPUfreq functionality due to a chip errata and there were talks internally
to actually disable it, hence the reason for keeping CPUs outside the
juno-base.dtsi. r2 will have a different set of big CPUs as well, so this
is preparing for the future as well.
PMU are linked to the CPUs, hence the reason they stayed. As for the
memory and psci nodes the thinking behind it was mostly to allow for
ACPI to make changes there, but it does look now like retrofitting an
explanation to something that I did not give too much thought at that
moment.
Best regards,
Liviu
>
> --
> Tixy
>
--
====================
| I would like to |
| fix the world, |
| but they're not |
| giving me the |
\ source code! /
---------------
¯\_(ツ)_/¯
On Thu, 2015-05-14 at 11:30 +0100, Liviu Dudau wrote:
> On Thu, May 14, 2015 at 10:35:42AM +0100, Jon Medhurst (Tixy) wrote:
[...]
> >
> > What criteria were used to select the contents of juno-base.dtsi?
> > From what I can see, the stuff left out of base is still the same for r0
> > and r1 (cpu, pmu, memory, psci!).
[...]
>
> There are potential differences. Cortex-A53 cluster in r1 has limited
> CPUfreq functionality due to a chip errata and there were talks internally
> to actually disable it, hence the reason for keeping CPUs outside the
> juno-base.dtsi. r2 will have a different set of big CPUs as well, so this
> is preparing for the future as well.
>
> PMU are linked to the CPUs, hence the reason they stayed. As for the
> memory and psci nodes the thinking behind it was mostly to allow for
> ACPI to make changes there, but it does look now like retrofitting an
> explanation to something that I did not give too much thought at that
> moment.
I guess my concern was motivated by the selfish aspect of having to
maintain a bunch of out-of-tree Juno patches (like cpuidle and cpufreq
related DT updates) and having to duplicate those in more than one DT,
and also having backport DT reorgs like this patch. Of course, none of
that should be a consideration in deciding what goes into mainline, I
just wanted to make sure there was a reason for the patch.
--
Tixy
On Thu, May 14, 2015 at 12:04:31PM +0100, Jon Medhurst (Tixy) wrote:
> On Thu, 2015-05-14 at 11:30 +0100, Liviu Dudau wrote:
> > On Thu, May 14, 2015 at 10:35:42AM +0100, Jon Medhurst (Tixy) wrote:
> [...]
> > >
> > > What criteria were used to select the contents of juno-base.dtsi?
> > > From what I can see, the stuff left out of base is still the same for r0
> > > and r1 (cpu, pmu, memory, psci!).
> [...]
> >
> > There are potential differences. Cortex-A53 cluster in r1 has limited
> > CPUfreq functionality due to a chip errata and there were talks internally
> > to actually disable it, hence the reason for keeping CPUs outside the
> > juno-base.dtsi. r2 will have a different set of big CPUs as well, so this
> > is preparing for the future as well.
> >
> > PMU are linked to the CPUs, hence the reason they stayed. As for the
> > memory and psci nodes the thinking behind it was mostly to allow for
> > ACPI to make changes there, but it does look now like retrofitting an
> > explanation to something that I did not give too much thought at that
> > moment.
>
> I guess my concern was motivated by the selfish aspect of having to
> maintain a bunch of out-of-tree Juno patches (like cpuidle and cpufreq
> related DT updates) and having to duplicate those in more than one DT,
> and also having backport DT reorgs like this patch. Of course, none of
> that should be a consideration in deciding what goes into mainline, I
> just wanted to make sure there was a reason for the patch.
You are probably the best placed engineer to offer feedback on these patches,
as it will affect you in the downstream.
Given that cpufreq will have limited ranges for Juno r1 (~200MHz spread) and
that HMP/EAS will not be working optimally on R1, do you still want to see
the CPUs nodes moved into juno-base.dtsi?
Best regards,
Liviu
>
> --
> Tixy
>
>
--
====================
| I would like to |
| fix the world, |
| but they're not |
| giving me the |
\ source code! /
---------------
¯\_(ツ)_/¯
On 14/05/15 12:04, Jon Medhurst (Tixy) wrote:
> On Thu, 2015-05-14 at 11:30 +0100, Liviu Dudau wrote:
>> On Thu, May 14, 2015 at 10:35:42AM +0100, Jon Medhurst (Tixy) wrote:
> [...]
>>>
>>> What criteria were used to select the contents of juno-base.dtsi?
>>> From what I can see, the stuff left out of base is still the same for r0
>>> and r1 (cpu, pmu, memory, psci!).
> [...]
>>
>> There are potential differences. Cortex-A53 cluster in r1 has limited
>> CPUfreq functionality due to a chip errata and there were talks internally
>> to actually disable it, hence the reason for keeping CPUs outside the
>> juno-base.dtsi. r2 will have a different set of big CPUs as well, so this
>> is preparing for the future as well.
>>
>> PMU are linked to the CPUs, hence the reason they stayed. As for the
>> memory and psci nodes the thinking behind it was mostly to allow for
>> ACPI to make changes there, but it does look now like retrofitting an
>> explanation to something that I did not give too much thought at that
>> moment.
>
> I guess my concern was motivated by the selfish aspect of having to
> maintain a bunch of out-of-tree Juno patches (like cpuidle and cpufreq
Hopefully not too long :)
> related DT updates) and having to duplicate those in more than one DT,
> and also having backport DT reorgs like this patch. Of course, none of
> that should be a consideration in deciding what goes into mainline, I
> just wanted to make sure there was a reason for the patch.
>
But I agree with you to remove duplicates as much as possible. Since
it's not possible to speculate how things will be in future platform,
IMO we can have all the device nodes that are common to both r0 and r1
in juno-base.dtsi for now and move them out as and when required.
Regards,
Sudeep
On Thu, 2015-05-14 at 14:11 +0100, Liviu Dudau wrote:
> On Thu, May 14, 2015 at 12:04:31PM +0100, Jon Medhurst (Tixy) wrote:
> > On Thu, 2015-05-14 at 11:30 +0100, Liviu Dudau wrote:
> > > On Thu, May 14, 2015 at 10:35:42AM +0100, Jon Medhurst (Tixy) wrote:
> > [...]
> > > >
> > > > What criteria were used to select the contents of juno-base.dtsi?
> > > > From what I can see, the stuff left out of base is still the same for r0
> > > > and r1 (cpu, pmu, memory, psci!).
> > [...]
> > >
> > > There are potential differences. Cortex-A53 cluster in r1 has limited
> > > CPUfreq functionality due to a chip errata and there were talks internally
> > > to actually disable it, hence the reason for keeping CPUs outside the
> > > juno-base.dtsi. r2 will have a different set of big CPUs as well, so this
> > > is preparing for the future as well.
> > >
> > > PMU are linked to the CPUs, hence the reason they stayed. As for the
> > > memory and psci nodes the thinking behind it was mostly to allow for
> > > ACPI to make changes there, but it does look now like retrofitting an
> > > explanation to something that I did not give too much thought at that
> > > moment.
> >
> > I guess my concern was motivated by the selfish aspect of having to
> > maintain a bunch of out-of-tree Juno patches (like cpuidle and cpufreq
> > related DT updates) and having to duplicate those in more than one DT,
> > and also having backport DT reorgs like this patch. Of course, none of
> > that should be a consideration in deciding what goes into mainline, I
> > just wanted to make sure there was a reason for the patch.
>
> You are probably the best placed engineer to offer feedback on these patches,
> as it will affect you in the downstream.
>
> Given that cpufreq will have limited ranges for Juno r1 (~200MHz spread) and
> that HMP/EAS will not be working optimally on R1, do you still want to see
> the CPUs nodes moved into juno-base.dtsi?
Well, I can only answer that if I knew what the requirements were for
the kernels I maintain, and as I'm unlikely to get any sensible answer,
or one that doesn't change depending on the day of the week or the
person I ask, then I think it probably best that we have the greatest
flexibility and have the cpu-nodes in separate files as you plan. I can
always carry a patch to make juno-r1.dts #include juno.dts if that makes
my life easier ;-) Hopefully the cpufreq and cpuidle stuff will find it
way into mainline in a kernel version or two anyway.
--
Tixy
On Wed, 2015-05-13 at 18:11 +0100, Liviu Dudau wrote:
> This board is based on Juno r0 with updated Cortex A5x revisions
> and board errata fixes. It also contains coherent ThinLinks ports
> on the expansion slot that allow for an AXI master on the daughter
> card to participate in a coherency domain.
>
> Support for SoC PCIe host bridge will be added as a separate series.
>
> Signed-off-by: Liviu Dudau <[email protected]>
> ---
> arch/arm64/boot/dts/arm/Makefile | 2 +-
> arch/arm64/boot/dts/arm/juno-r1.dts | 123 ++++++++++++++++++++++++++++++++++++
> 2 files changed, 124 insertions(+), 1 deletion(-)
> create mode 100644 arch/arm64/boot/dts/arm/juno-r1.dts
>
> diff --git a/arch/arm64/boot/dts/arm/Makefile b/arch/arm64/boot/dts/arm/Makefile
> index 301a0da..c5c98b9 100644
> --- a/arch/arm64/boot/dts/arm/Makefile
> +++ b/arch/arm64/boot/dts/arm/Makefile
> @@ -1,5 +1,5 @@
> dtb-$(CONFIG_ARCH_VEXPRESS) += foundation-v8.dtb
> -dtb-$(CONFIG_ARCH_VEXPRESS) += juno.dtb
> +dtb-$(CONFIG_ARCH_VEXPRESS) += juno.dtb juno-r1.dtb
> dtb-$(CONFIG_ARCH_VEXPRESS) += rtsm_ve-aemv8a.dtb
>
> always := $(dtb-y)
> diff --git a/arch/arm64/boot/dts/arm/juno-r1.dts b/arch/arm64/boot/dts/arm/juno-r1.dts
> new file mode 100644
> index 0000000..f6bc073
> --- /dev/null
> +++ b/arch/arm64/boot/dts/arm/juno-r1.dts
> @@ -0,0 +1,123 @@
> +/*
> + * ARM Ltd. Juno Platform
> + *
> + * Copyright (c) 2015 ARM Ltd.
> + *
> + * This file is licensed under a dual GPLv2 or BSD license.
> + */
> +
> +/dts-v1/;
> +
> +#include <dt-bindings/interrupt-controller/arm-gic.h>
> +
> +/ {
> + model = "ARM Juno development board (r1)";
> + compatible = "arm,juno", "arm,vexpress";
Is there scope for adding "arm,juno-r1" to the front of that list?
Reason I ask, is that I can't help but think [1] that userside code
(like Android) which wants to select device-specific configuration,
should use something like the devices compatible string rather than what
they currently propose [2].
[1] https://lists.linaro.org/pipermail/linaro-android/2015-April/002743.html
[2] https://lists.linaro.org/pipermail/linaro-android/2015-April/002742.html
--
Tixy
On Thu, May 14, 2015 at 03:07:31PM +0100, Jon Medhurst (Tixy) wrote:
> On Wed, 2015-05-13 at 18:11 +0100, Liviu Dudau wrote:
> > This board is based on Juno r0 with updated Cortex A5x revisions
> > and board errata fixes. It also contains coherent ThinLinks ports
> > on the expansion slot that allow for an AXI master on the daughter
> > card to participate in a coherency domain.
> >
> > Support for SoC PCIe host bridge will be added as a separate series.
> >
> > Signed-off-by: Liviu Dudau <[email protected]>
> > ---
> > arch/arm64/boot/dts/arm/Makefile | 2 +-
> > arch/arm64/boot/dts/arm/juno-r1.dts | 123 ++++++++++++++++++++++++++++++++++++
> > 2 files changed, 124 insertions(+), 1 deletion(-)
> > create mode 100644 arch/arm64/boot/dts/arm/juno-r1.dts
> >
> > diff --git a/arch/arm64/boot/dts/arm/Makefile b/arch/arm64/boot/dts/arm/Makefile
> > index 301a0da..c5c98b9 100644
> > --- a/arch/arm64/boot/dts/arm/Makefile
> > +++ b/arch/arm64/boot/dts/arm/Makefile
> > @@ -1,5 +1,5 @@
> > dtb-$(CONFIG_ARCH_VEXPRESS) += foundation-v8.dtb
> > -dtb-$(CONFIG_ARCH_VEXPRESS) += juno.dtb
> > +dtb-$(CONFIG_ARCH_VEXPRESS) += juno.dtb juno-r1.dtb
> > dtb-$(CONFIG_ARCH_VEXPRESS) += rtsm_ve-aemv8a.dtb
> >
> > always := $(dtb-y)
> > diff --git a/arch/arm64/boot/dts/arm/juno-r1.dts b/arch/arm64/boot/dts/arm/juno-r1.dts
> > new file mode 100644
> > index 0000000..f6bc073
> > --- /dev/null
> > +++ b/arch/arm64/boot/dts/arm/juno-r1.dts
> > @@ -0,0 +1,123 @@
> > +/*
> > + * ARM Ltd. Juno Platform
> > + *
> > + * Copyright (c) 2015 ARM Ltd.
> > + *
> > + * This file is licensed under a dual GPLv2 or BSD license.
> > + */
> > +
> > +/dts-v1/;
> > +
> > +#include <dt-bindings/interrupt-controller/arm-gic.h>
> > +
> > +/ {
> > + model = "ARM Juno development board (r1)";
> > + compatible = "arm,juno", "arm,vexpress";
>
> Is there scope for adding "arm,juno-r1" to the front of that list?
> Reason I ask, is that I can't help but think [1] that userside code
> (like Android) which wants to select device-specific configuration,
> should use something like the devices compatible string rather than what
> they currently propose [2].
Sure, I can do that for the next revision of the patch.
Best regards,
Liviu
>
> [1] https://lists.linaro.org/pipermail/linaro-android/2015-April/002743.html
> [2] https://lists.linaro.org/pipermail/linaro-android/2015-April/002742.html
>
> --
> Tixy
>
--
====================
| I would like to |
| fix the world, |
| but they're not |
| giving me the |
\ source code! /
---------------
¯\_(ツ)_/¯
On Thu, May 14, 2015 at 03:07:31PM +0100, Jon Medhurst (Tixy) wrote:
> On Wed, 2015-05-13 at 18:11 +0100, Liviu Dudau wrote:
> > This board is based on Juno r0 with updated Cortex A5x revisions
> > and board errata fixes. It also contains coherent ThinLinks ports
> > on the expansion slot that allow for an AXI master on the daughter
> > card to participate in a coherency domain.
> >
> > Support for SoC PCIe host bridge will be added as a separate series.
> >
> > Signed-off-by: Liviu Dudau <[email protected]>
> > ---
> > arch/arm64/boot/dts/arm/Makefile | 2 +-
> > arch/arm64/boot/dts/arm/juno-r1.dts | 123 ++++++++++++++++++++++++++++++++++++
> > 2 files changed, 124 insertions(+), 1 deletion(-)
> > create mode 100644 arch/arm64/boot/dts/arm/juno-r1.dts
> >
> > diff --git a/arch/arm64/boot/dts/arm/Makefile b/arch/arm64/boot/dts/arm/Makefile
> > index 301a0da..c5c98b9 100644
> > --- a/arch/arm64/boot/dts/arm/Makefile
> > +++ b/arch/arm64/boot/dts/arm/Makefile
> > @@ -1,5 +1,5 @@
> > dtb-$(CONFIG_ARCH_VEXPRESS) += foundation-v8.dtb
> > -dtb-$(CONFIG_ARCH_VEXPRESS) += juno.dtb
> > +dtb-$(CONFIG_ARCH_VEXPRESS) += juno.dtb juno-r1.dtb
> > dtb-$(CONFIG_ARCH_VEXPRESS) += rtsm_ve-aemv8a.dtb
> >
> > always := $(dtb-y)
> > diff --git a/arch/arm64/boot/dts/arm/juno-r1.dts b/arch/arm64/boot/dts/arm/juno-r1.dts
> > new file mode 100644
> > index 0000000..f6bc073
> > --- /dev/null
> > +++ b/arch/arm64/boot/dts/arm/juno-r1.dts
> > @@ -0,0 +1,123 @@
> > +/*
> > + * ARM Ltd. Juno Platform
> > + *
> > + * Copyright (c) 2015 ARM Ltd.
> > + *
> > + * This file is licensed under a dual GPLv2 or BSD license.
> > + */
> > +
> > +/dts-v1/;
> > +
> > +#include <dt-bindings/interrupt-controller/arm-gic.h>
> > +
> > +/ {
> > + model = "ARM Juno development board (r1)";
> > + compatible = "arm,juno", "arm,vexpress";
>
> Is there scope for adding "arm,juno-r1" to the front of that list?
> Reason I ask, is that I can't help but think [1] that userside code
> (like Android) which wants to select device-specific configuration,
> should use something like the devices compatible string rather than what
> they currently propose [2].
> [1] https://lists.linaro.org/pipermail/linaro-android/2015-April/002743.html
> [2] https://lists.linaro.org/pipermail/linaro-android/2015-April/002742.html
Ideally, userspace shouldn't need to know what specific device they're
running on (though obviously there will always be cases...). To that
end, it would be interesting to know what this data would be used for.
If it's just a string for some "About device" menu, the model string
should be ok.
I'm a bit lost with the suggestion in [2]. It doesn't seem to have
anything to do with firmware, though perhaps I'm missing something? What
information are they trying to get at?
Thanks,
Mark.
On Thu, 2015-05-14 at 15:18 +0100, Mark Rutland wrote:
> On Thu, May 14, 2015 at 03:07:31PM +0100, Jon Medhurst (Tixy) wrote:
> > On Wed, 2015-05-13 at 18:11 +0100, Liviu Dudau wrote:
> > > This board is based on Juno r0 with updated Cortex A5x revisions
> > > and board errata fixes. It also contains coherent ThinLinks ports
> > > on the expansion slot that allow for an AXI master on the daughter
> > > card to participate in a coherency domain.
> > >
> > > Support for SoC PCIe host bridge will be added as a separate series.
> > >
> > > Signed-off-by: Liviu Dudau <[email protected]>
> > > ---
> > > arch/arm64/boot/dts/arm/Makefile | 2 +-
> > > arch/arm64/boot/dts/arm/juno-r1.dts | 123 ++++++++++++++++++++++++++++++++++++
> > > 2 files changed, 124 insertions(+), 1 deletion(-)
> > > create mode 100644 arch/arm64/boot/dts/arm/juno-r1.dts
> > >
> > > diff --git a/arch/arm64/boot/dts/arm/Makefile b/arch/arm64/boot/dts/arm/Makefile
> > > index 301a0da..c5c98b9 100644
> > > --- a/arch/arm64/boot/dts/arm/Makefile
> > > +++ b/arch/arm64/boot/dts/arm/Makefile
> > > @@ -1,5 +1,5 @@
> > > dtb-$(CONFIG_ARCH_VEXPRESS) += foundation-v8.dtb
> > > -dtb-$(CONFIG_ARCH_VEXPRESS) += juno.dtb
> > > +dtb-$(CONFIG_ARCH_VEXPRESS) += juno.dtb juno-r1.dtb
> > > dtb-$(CONFIG_ARCH_VEXPRESS) += rtsm_ve-aemv8a.dtb
> > >
> > > always := $(dtb-y)
> > > diff --git a/arch/arm64/boot/dts/arm/juno-r1.dts b/arch/arm64/boot/dts/arm/juno-r1.dts
> > > new file mode 100644
> > > index 0000000..f6bc073
> > > --- /dev/null
> > > +++ b/arch/arm64/boot/dts/arm/juno-r1.dts
> > > @@ -0,0 +1,123 @@
> > > +/*
> > > + * ARM Ltd. Juno Platform
> > > + *
> > > + * Copyright (c) 2015 ARM Ltd.
> > > + *
> > > + * This file is licensed under a dual GPLv2 or BSD license.
> > > + */
> > > +
> > > +/dts-v1/;
> > > +
> > > +#include <dt-bindings/interrupt-controller/arm-gic.h>
> > > +
> > > +/ {
> > > + model = "ARM Juno development board (r1)";
> > > + compatible = "arm,juno", "arm,vexpress";
> >
> > Is there scope for adding "arm,juno-r1" to the front of that list?
> > Reason I ask, is that I can't help but think [1] that userside code
> > (like Android) which wants to select device-specific configuration,
> > should use something like the devices compatible string rather than what
> > they currently propose [2].
>
> > [1] https://lists.linaro.org/pipermail/linaro-android/2015-April/002743.html
> > [2] https://lists.linaro.org/pipermail/linaro-android/2015-April/002742.html
>
> Ideally, userspace shouldn't need to know what specific device they're
> running on (though obviously there will always be cases...). To that
> end, it would be interesting to know what this data would be used for.
> If it's just a string for some "About device" menu, the model string
> should be ok.
The 'hardware name' is used to selected the correct init scripts, fstab,
userside graphics/audio drivers for the device.
> I'm a bit lost with the suggestion in [2]. It doesn't seem to have
> anything to do with firmware, though perhaps I'm missing something?
That was my reaction. Before they were parsing /proc/cpuinfo to get the
device name. But that information got removed.
--
Tixy