The AM62 SoC family is the follow on AM335x built on K3 Multicore SoC
architecture platform, providing ultra-low-power modes, dual display,
multi-sensor edge compute, security and other BOM-saving integration.
The AM62 SoC targets broad market to enable applications such as
Industrial HMI, PLC/CNC/Robot control, Medical Equipment, Building
Automation, Appliances and more.
Some highlights of this SoC are:
* Quad-Cortex-A53s (running up to 1.4GHz) in a single cluster.
Pin-to-pin compatible options for single and quad core are available.
* Cortex-M4F for general-purpose or safety usage.
* Dual display support, providing 24-bit RBG parallel interface and
OLDI/LVDS-4 Lane x2, up to 200MHz pixel clock support for 2K display
resolution.
* Selectable GPUsupport, up to 8GFLOPS, providing better user experience
in 3D graphic display case and Android.
* PRU(Programmable Realtime Unit) support for customized programmable
interfaces/IOs.
* Integrated Giga-bit Ethernet switch supporting up to a total of two
external ports (TSN capable).
* 9xUARTs, 5xSPI, 6xI2C, 2xUSB2, 3xCAN-FD, 3x eMMC and SD, GPMC for
NAND/FPGA connection, OSPI memory controller, 3xMcASP for audio,
1x CSI-RX-4L for Camera, eCAP/eQEP, ePWM, among other peripherals.
* Dedicated Centralized System Controller for Security, Power, and
Resource Management.
* Multiple low power modes support, ex: Deep sleep,Standby, MCU-only,
enabling battery powered system design.
This add bare minimum DT describing ARM compute clusters, Main, MCU and
Wakeup domain and interconnects, UARTs and I2Cs to enable booting using
ramdisk.
More details can be found in the Technical Reference Manual:
https://www.ti.com/lit/pdf/spruiv7
Co-developed-by: Suman Anna <[email protected]>
Signed-off-by: Suman Anna <[email protected]>
Co-developed-by: Nishanth Menon <[email protected]>
Signed-off-by: Nishanth Menon <[email protected]>
Signed-off-by: Vignesh Raghavendra <[email protected]>
---
arch/arm64/boot/dts/ti/k3-am62-main.dtsi | 263 +++++++++++++++++++++
arch/arm64/boot/dts/ti/k3-am62-mcu.dtsi | 36 +++
arch/arm64/boot/dts/ti/k3-am62-wakeup.dtsi | 41 ++++
arch/arm64/boot/dts/ti/k3-am62.dtsi | 104 ++++++++
arch/arm64/boot/dts/ti/k3-am625.dtsi | 103 ++++++++
5 files changed, 547 insertions(+)
create mode 100644 arch/arm64/boot/dts/ti/k3-am62-main.dtsi
create mode 100644 arch/arm64/boot/dts/ti/k3-am62-mcu.dtsi
create mode 100644 arch/arm64/boot/dts/ti/k3-am62-wakeup.dtsi
create mode 100644 arch/arm64/boot/dts/ti/k3-am62.dtsi
create mode 100644 arch/arm64/boot/dts/ti/k3-am625.dtsi
diff --git a/arch/arm64/boot/dts/ti/k3-am62-main.dtsi b/arch/arm64/boot/dts/ti/k3-am62-main.dtsi
new file mode 100644
index 000000000000..81d6d99ca180
--- /dev/null
+++ b/arch/arm64/boot/dts/ti/k3-am62-main.dtsi
@@ -0,0 +1,263 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Device Tree Source for AM625 SoC Family Main Domain peripherals
+ *
+ * Copyright (C) 2020-2022 Texas Instruments Incorporated - https://www.ti.com/
+ */
+
+&cbass_main {
+ gic500: interrupt-controller@1800000 {
+ compatible = "arm,gic-v3";
+ #address-cells = <2>;
+ #size-cells = <2>;
+ ranges;
+ #interrupt-cells = <3>;
+ interrupt-controller;
+ reg = <0x00 0x01800000 0x00 0x10000>, /* GICD */
+ <0x00 0x01880000 0x00 0xC0000>; /* GICR */
+ /*
+ * vcpumntirq:
+ * virtual CPU interface maintenance interrupt
+ */
+ interrupts = <GIC_PPI 9 IRQ_TYPE_LEVEL_HIGH>;
+
+ gic_its: msi-controller@1820000 {
+ compatible = "arm,gic-v3-its";
+ reg = <0x00 0x01820000 0x00 0x10000>;
+ socionext,synquacer-pre-its = <0x1000000 0x400000>;
+ msi-controller;
+ #msi-cells = <1>;
+ };
+ };
+
+ main_conf: syscon@100000 {
+ compatible = "syscon", "simple-mfd";
+ reg = <0x00 0x00100000 0x00 0x20000>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges = <0x0 0x00 0x00100000 0x20000>;
+ };
+
+ dmss: bus@48000000 {
+ compatible = "simple-mfd";
+ #address-cells = <2>;
+ #size-cells = <2>;
+ dma-ranges;
+ ranges = <0x00 0x48000000 0x00 0x48000000 0x00 0x06400000>;
+
+ ti,sci-dev-id = <25>;
+
+ secure_proxy_main: mailbox@4d000000 {
+ compatible = "ti,am654-secure-proxy";
+ #mbox-cells = <1>;
+ reg-names = "target_data", "rt", "scfg";
+ reg = <0x00 0x4d000000 0x00 0x80000>,
+ <0x00 0x4a600000 0x00 0x80000>,
+ <0x00 0x4a400000 0x00 0x80000>;
+ interrupt-names = "rx_012";
+ interrupts = <GIC_SPI 34 IRQ_TYPE_LEVEL_HIGH>;
+ };
+ };
+
+ dmsc: system-controller@44043000 {
+ compatible = "ti,k2g-sci";
+ ti,host-id = <12>;
+ mbox-names = "rx", "tx";
+ mboxes= <&secure_proxy_main 12>,
+ <&secure_proxy_main 13>;
+ reg-names = "debug_messages";
+ reg = <0x00 0x44043000 0x00 0xfe0>;
+
+ k3_pds: power-controller {
+ compatible = "ti,sci-pm-domain";
+ #power-domain-cells = <2>;
+ };
+
+ k3_clks: clock-controller {
+ compatible = "ti,k2g-sci-clk";
+ #clock-cells = <2>;
+ };
+
+ k3_reset: reset-controller {
+ compatible = "ti,sci-reset";
+ #reset-cells = <2>;
+ };
+ };
+
+ main_pmx0: pinctrl@f4000 {
+ compatible = "pinctrl-single";
+ reg = <0x00 0xf4000 0x00 0x2ac>;
+ #pinctrl-cells = <1>;
+ pinctrl-single,register-width = <32>;
+ pinctrl-single,function-mask = <0xffffffff>;
+ };
+
+ main_uart0: serial@2800000 {
+ compatible = "ti,am64-uart", "ti,am654-uart";
+ reg = <0x00 0x02800000 0x00 0x100>;
+ interrupts = <GIC_SPI 178 IRQ_TYPE_LEVEL_HIGH>;
+ power-domains = <&k3_pds 146 TI_SCI_PD_EXCLUSIVE>;
+ clocks = <&k3_clks 146 0>;
+ clock-names = "fclk";
+ };
+
+ main_uart1: serial@2810000 {
+ compatible = "ti,am64-uart", "ti,am654-uart";
+ reg = <0x00 0x02810000 0x00 0x100>;
+ interrupts = <GIC_SPI 179 IRQ_TYPE_LEVEL_HIGH>;
+ power-domains = <&k3_pds 152 TI_SCI_PD_EXCLUSIVE>;
+ clocks = <&k3_clks 152 0>;
+ clock-names = "fclk";
+ };
+
+ main_uart2: serial@2820000 {
+ compatible = "ti,am64-uart", "ti,am654-uart";
+ reg = <0x00 0x02820000 0x00 0x100>;
+ interrupts = <GIC_SPI 180 IRQ_TYPE_LEVEL_HIGH>;
+ power-domains = <&k3_pds 153 TI_SCI_PD_EXCLUSIVE>;
+ clocks = <&k3_clks 153 0>;
+ clock-names = "fclk";
+ };
+
+ main_uart3: serial@2830000 {
+ compatible = "ti,am64-uart", "ti,am654-uart";
+ reg = <0x00 0x02830000 0x00 0x100>;
+ interrupts = <GIC_SPI 181 IRQ_TYPE_LEVEL_HIGH>;
+ power-domains = <&k3_pds 154 TI_SCI_PD_EXCLUSIVE>;
+ clocks = <&k3_clks 154 0>;
+ clock-names = "fclk";
+ };
+
+ main_uart4: serial@2840000 {
+ compatible = "ti,am64-uart", "ti,am654-uart";
+ reg = <0x00 0x02840000 0x00 0x100>;
+ interrupts = <GIC_SPI 182 IRQ_TYPE_LEVEL_HIGH>;
+ power-domains = <&k3_pds 155 TI_SCI_PD_EXCLUSIVE>;
+ clocks = <&k3_clks 155 0>;
+ clock-names = "fclk";
+ };
+
+ main_uart5: serial@2850000 {
+ compatible = "ti,am64-uart", "ti,am654-uart";
+ reg = <0x00 0x02850000 0x00 0x100>;
+ interrupts = <GIC_SPI 183 IRQ_TYPE_LEVEL_HIGH>;
+ power-domains = <&k3_pds 156 TI_SCI_PD_EXCLUSIVE>;
+ clocks = <&k3_clks 156 0>;
+ clock-names = "fclk";
+ };
+
+ main_uart6: serial@2860000 {
+ compatible = "ti,am64-uart", "ti,am654-uart";
+ reg = <0x00 0x02860000 0x00 0x100>;
+ interrupts = <GIC_SPI 184 IRQ_TYPE_LEVEL_HIGH>;
+ power-domains = <&k3_pds 158 TI_SCI_PD_EXCLUSIVE>;
+ clocks = <&k3_clks 158 0>;
+ clock-names = "fclk";
+ };
+
+ main_i2c0: i2c@20000000 {
+ compatible = "ti,am64-i2c", "ti,omap4-i2c";
+ reg = <0x00 0x20000000 0x00 0x100>;
+ interrupts = <GIC_SPI 161 IRQ_TYPE_LEVEL_HIGH>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ power-domains = <&k3_pds 102 TI_SCI_PD_EXCLUSIVE>;
+ clocks = <&k3_clks 102 2>;
+ clock-names = "fck";
+ };
+
+ main_i2c1: i2c@20010000 {
+ compatible = "ti,am64-i2c", "ti,omap4-i2c";
+ reg = <0x00 0x20010000 0x00 0x100>;
+ interrupts = <GIC_SPI 162 IRQ_TYPE_LEVEL_HIGH>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ power-domains = <&k3_pds 103 TI_SCI_PD_EXCLUSIVE>;
+ clocks = <&k3_clks 103 2>;
+ clock-names = "fck";
+ };
+
+ main_i2c2: i2c@20020000 {
+ compatible = "ti,am64-i2c", "ti,omap4-i2c";
+ reg = <0x00 0x20020000 0x00 0x100>;
+ interrupts = <GIC_SPI 163 IRQ_TYPE_LEVEL_HIGH>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ power-domains = <&k3_pds 104 TI_SCI_PD_EXCLUSIVE>;
+ clocks = <&k3_clks 104 2>;
+ clock-names = "fck";
+ };
+
+ main_i2c3: i2c@20030000 {
+ compatible = "ti,am64-i2c", "ti,omap4-i2c";
+ reg = <0x00 0x20030000 0x00 0x100>;
+ interrupts = <GIC_SPI 164 IRQ_TYPE_LEVEL_HIGH>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ power-domains = <&k3_pds 105 TI_SCI_PD_EXCLUSIVE>;
+ clocks = <&k3_clks 105 2>;
+ clock-names = "fck";
+ };
+
+ main_gpio_intr: interrupt-controller@a00000 {
+ compatible = "ti,sci-intr";
+ reg = <0x00 0x00a00000 0x00 0x800>;
+ ti,intr-trigger-type = <1>;
+ interrupt-controller;
+ interrupt-parent = <&gic500>;
+ #interrupt-cells = <1>;
+ ti,sci = <&dmsc>;
+ ti,sci-dev-id = <3>;
+ ti,interrupt-ranges = <0 32 16>;
+ };
+
+ main_gpio0: gpio@600000 {
+ compatible = "ti,am64-gpio", "ti,keystone-gpio";
+ reg = <0x0 0x00600000 0x0 0x100>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ interrupt-parent = <&main_gpio_intr>;
+ interrupts = <190>, <191>, <192>,
+ <193>, <194>, <195>;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ ti,ngpio = <87>;
+ ti,davinci-gpio-unbanked = <0>;
+ power-domains = <&k3_pds 77 TI_SCI_PD_EXCLUSIVE>;
+ clocks = <&k3_clks 77 0>;
+ clock-names = "gpio";
+ };
+
+ main_gpio1: gpio@601000 {
+ compatible = "ti,am64-gpio", "ti,keystone-gpio";
+ reg = <0x0 0x00601000 0x0 0x100>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ interrupt-parent = <&main_gpio_intr>;
+ interrupts = <180>, <181>, <182>,
+ <183>, <184>, <185>;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ ti,ngpio = <88>;
+ ti,davinci-gpio-unbanked = <0>;
+ power-domains = <&k3_pds 78 TI_SCI_PD_EXCLUSIVE>;
+ clocks = <&k3_clks 78 0>;
+ clock-names = "gpio";
+ };
+
+ hwspinlock: spinlock@2a000000 {
+ compatible = "ti,am64-hwspinlock";
+ reg = <0x00 0x2a000000 0x00 0x1000>;
+ #hwlock-cells = <1>;
+ };
+
+ mailbox0_cluster0: mailbox@29000000 {
+ compatible = "ti,am64-mailbox";
+ reg = <0x00 0x29000000 0x00 0x200>;
+ interrupts = <GIC_SPI 76 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 77 IRQ_TYPE_LEVEL_HIGH>;
+ #mbox-cells = <1>;
+ ti,mbox-num-users = <4>;
+ ti,mbox-num-fifos = <16>;
+ };
+};
diff --git a/arch/arm64/boot/dts/ti/k3-am62-mcu.dtsi b/arch/arm64/boot/dts/ti/k3-am62-mcu.dtsi
new file mode 100644
index 000000000000..9d210d55fc71
--- /dev/null
+++ b/arch/arm64/boot/dts/ti/k3-am62-mcu.dtsi
@@ -0,0 +1,36 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Device Tree Source for AM625 SoC Family MCU Domain peripherals
+ *
+ * Copyright (C) 2020-2022 Texas Instruments Incorporated - https://www.ti.com/
+ */
+
+&cbass_mcu {
+ mcu_pmx0: pinctrl@4084000 {
+ compatible = "pinctrl-single";
+ reg = <0x00 0x04084000 0x00 0x88>;
+ #pinctrl-cells = <1>;
+ pinctrl-single,register-width = <32>;
+ pinctrl-single,function-mask = <0xffffffff>;
+ };
+
+ mcu_uart0: serial@4a00000 {
+ compatible = "ti,am64-uart", "ti,am654-uart";
+ reg = <0x00 0x04a00000 0x00 0x100>;
+ interrupts = <GIC_SPI 185 IRQ_TYPE_LEVEL_HIGH>;
+ power-domains = <&k3_pds 149 TI_SCI_PD_EXCLUSIVE>;
+ clocks = <&k3_clks 149 0>;
+ clock-names = "fclk";
+ };
+
+ mcu_i2c0: i2c@4900000 {
+ compatible = "ti,am64-i2c", "ti,omap4-i2c";
+ reg = <0x00 0x04900000 0x00 0x100>;
+ interrupts = <GIC_SPI 107 IRQ_TYPE_LEVEL_HIGH>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ power-domains = <&k3_pds 106 TI_SCI_PD_EXCLUSIVE>;
+ clocks = <&k3_clks 106 2>;
+ clock-names = "fck";
+ };
+};
diff --git a/arch/arm64/boot/dts/ti/k3-am62-wakeup.dtsi b/arch/arm64/boot/dts/ti/k3-am62-wakeup.dtsi
new file mode 100644
index 000000000000..4090134676cf
--- /dev/null
+++ b/arch/arm64/boot/dts/ti/k3-am62-wakeup.dtsi
@@ -0,0 +1,41 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Device Tree Source for AM625 SoC Family Wakeup Domain peripherals
+ *
+ * Copyright (C) 2020-2022 Texas Instruments Incorporated - https://www.ti.com/
+ */
+
+&cbass_wakeup {
+ wkup_conf: syscon@43000000 {
+ compatible = "syscon", "simple-mfd";
+ reg = <0x00 0x43000000 0x00 0x20000>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges = <0x0 0x00 0x43000000 0x20000>;
+
+ chipid: chipid@14 {
+ compatible = "ti,am654-chipid";
+ reg = <0x14 0x4>;
+ };
+ };
+
+ wkup_uart0: serial@2b300000 {
+ compatible = "ti,am64-uart", "ti,am654-uart";
+ reg = <0x00 0x2b300000 0x00 0x100>;
+ interrupts = <GIC_SPI 186 IRQ_TYPE_LEVEL_HIGH>;
+ power-domains = <&k3_pds 114 TI_SCI_PD_EXCLUSIVE>;
+ clocks = <&k3_clks 114 0>;
+ clock-names = "fclk";
+ };
+
+ wkup_i2c0: i2c@2b200000 {
+ compatible = "ti,am64-i2c", "ti,omap4-i2c";
+ reg = <0x00 0x02b200000 0x00 0x100>;
+ interrupts = <GIC_SPI 165 IRQ_TYPE_LEVEL_HIGH>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ power-domains = <&k3_pds 107 TI_SCI_PD_EXCLUSIVE>;
+ clocks = <&k3_clks 107 4>;
+ clock-names = "fck";
+ };
+};
diff --git a/arch/arm64/boot/dts/ti/k3-am62.dtsi b/arch/arm64/boot/dts/ti/k3-am62.dtsi
new file mode 100644
index 000000000000..f1a46be27c37
--- /dev/null
+++ b/arch/arm64/boot/dts/ti/k3-am62.dtsi
@@ -0,0 +1,104 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Device Tree Source for AM62 SoC Family
+ *
+ * Copyright (C) 2020-2022 Texas Instruments Incorporated - https://www.ti.com/
+ */
+
+#include <dt-bindings/gpio/gpio.h>
+#include <dt-bindings/interrupt-controller/irq.h>
+#include <dt-bindings/interrupt-controller/arm-gic.h>
+#include <dt-bindings/pinctrl/k3.h>
+#include <dt-bindings/soc/ti,sci_pm_domain.h>
+
+/ {
+ model = "Texas Instruments K3 AM625 SoC";
+ compatible = "ti,am625";
+ interrupt-parent = <&gic500>;
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ chosen { };
+
+ firmware {
+ optee {
+ compatible = "linaro,optee-tz";
+ method = "smc";
+ };
+
+ psci: psci {
+ compatible = "arm,psci-1.0";
+ method = "smc";
+ };
+ };
+
+ a53_timer0: timer-cl0-cpu0 {
+ compatible = "arm,armv8-timer";
+ interrupts = <GIC_PPI 13 IRQ_TYPE_LEVEL_LOW>, /* cntpsirq */
+ <GIC_PPI 14 IRQ_TYPE_LEVEL_LOW>, /* cntpnsirq */
+ <GIC_PPI 11 IRQ_TYPE_LEVEL_LOW>, /* cntvirq */
+ <GIC_PPI 10 IRQ_TYPE_LEVEL_LOW>; /* cnthpirq */
+ };
+
+ pmu: pmu {
+ compatible = "arm,cortex-a53-pmu";
+ interrupts = <GIC_PPI 7 IRQ_TYPE_LEVEL_HIGH>;
+ };
+
+ cbass_main: bus@f0000 {
+ compatible = "simple-bus";
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ ranges = <0x00 0x000f0000 0x00 0x000f0000 0x00 0x00030000>, /* Main MMRs */
+ <0x00 0x30040000 0x00 0x30040000 0x00 0x00080000>, /* PRUSS-M */
+ <0x00 0x00600000 0x00 0x00600000 0x00 0x00001100>, /* GPIO */
+ <0x00 0x00703000 0x00 0x00703000 0x00 0x00000200>, /* USB0 debug trace */
+ <0x00 0x0070C000 0x00 0x0070C000 0x00 0x00000200>, /* USB1 debug trace */
+ <0x00 0x00a40000 0x00 0x00a40000 0x00 0x00000800>, /* Timesync router */
+ <0x00 0x0fd00000 0x00 0x0fd00000 0x00 0x00020000>, /* GPU */
+ <0x00 0x01000000 0x00 0x01000000 0x00 0x01b28400>, /* First peripheral window */
+ <0x00 0x60000000 0x00 0x60000000 0x00 0x08000000>, /* FSS0 DAT1 */
+ <0x00 0x70000000 0x00 0x70000000 0x00 0x00010000>, /* OCSRAM */
+ <0x00 0x08000000 0x00 0x08000000 0x00 0x00200000>, /* Main CPSW */
+ <0x00 0x0e000000 0x00 0x0e000000 0x00 0x01d20000>, /* Second peripheral window */
+ <0x00 0x20000000 0x00 0x20000000 0x00 0x0a008000>, /* Third peripheral window */
+ <0x00 0x30200000 0x00 0x30200000 0x00 0x00010000>, /* DSS */
+ <0x00 0x43600000 0x00 0x43600000 0x00 0x00010000>, /* sa3 sproxy data */
+ <0x00 0x44043000 0x00 0x44043000 0x00 0x00000fe0>, /* TI SCI DEBUG */
+ <0x00 0x44860000 0x00 0x44860000 0x00 0x00040000>, /* sa3 sproxy config */
+ <0x00 0x48000000 0x00 0x48000000 0x00 0x06400000>, /* DMSS */
+ <0x00 0x60000000 0x00 0x60000000 0x00 0x08000000>, /* FSS0 DAT1 */
+ <0x05 0x00000000 0x05 0x00000000 0x01 0x00000000>, /* FSS0 DAT3 */
+ <0x00 0x31000000 0x00 0x31000000 0x00 0x00050000>, /* USB0 DWC3 Core window */
+ <0x00 0x31100000 0x00 0x31100000 0x00 0x00050000>, /* USB1 DWC3 Core window */
+ <0x00 0x30101000 0x00 0x30101000 0x00 0x00010100>, /* CSI window */
+
+ /* MCU Domain Range */
+ <0x00 0x04000000 0x00 0x04000000 0x00 0x01ff1400>,
+
+ /* Wakeup Domain Range */
+ <0x00 0x2b000000 0x00 0x2b000000 0x00 0x00300400>,
+ <0x00 0x43000000 0x00 0x43000000 0x00 0x00020000>;
+
+ cbass_mcu: bus@4000000 {
+ compatible = "simple-bus";
+ #address-cells = <2>;
+ #size-cells = <2>;
+ ranges = <0x00 0x04000000 0x00 0x04000000 0x00 0x01ff1400>; /* Peripheral window */
+ };
+
+ cbass_wakeup: bus@2b000000 {
+ compatible = "simple-bus";
+ #address-cells = <2>;
+ #size-cells = <2>;
+ ranges = <0x00 0x2b000000 0x00 0x2b000000 0x00 0x00300400>, /* Peripheral Window */
+ <0x00 0x43000000 0x00 0x43000000 0x00 0x00020000>;
+ };
+ };
+};
+
+/* Now include the peripherals for each bus segments */
+#include "k3-am62-main.dtsi"
+#include "k3-am62-mcu.dtsi"
+#include "k3-am62-wakeup.dtsi"
diff --git a/arch/arm64/boot/dts/ti/k3-am625.dtsi b/arch/arm64/boot/dts/ti/k3-am625.dtsi
new file mode 100644
index 000000000000..887f31c23fef
--- /dev/null
+++ b/arch/arm64/boot/dts/ti/k3-am625.dtsi
@@ -0,0 +1,103 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Device Tree Source for AM625 SoC family in Quad core configuration
+ *
+ * TRM: https://www.ti.com/lit/pdf/spruiv7
+ *
+ * Copyright (C) 2020-2022 Texas Instruments Incorporated - https://www.ti.com/
+ */
+
+/dts-v1/;
+
+#include "k3-am62.dtsi"
+
+/ {
+ cpus {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ cpu-map {
+ cluster0: cluster0 {
+ core0 {
+ cpu = <&cpu0>;
+ };
+
+ core1 {
+ cpu = <&cpu1>;
+ };
+
+ core2 {
+ cpu = <&cpu2>;
+ };
+
+ core3 {
+ cpu = <&cpu3>;
+ };
+ };
+ };
+
+ cpu0: cpu@0 {
+ compatible = "arm,cortex-a53";
+ reg = <0x000>;
+ device_type = "cpu";
+ enable-method = "psci";
+ i-cache-size = <0x8000>;
+ i-cache-line-size = <64>;
+ i-cache-sets = <256>;
+ d-cache-size = <0x8000>;
+ d-cache-line-size = <64>;
+ d-cache-sets = <128>;
+ next-level-cache = <&L2_0>;
+ };
+
+ cpu1: cpu@1 {
+ compatible = "arm,cortex-a53";
+ reg = <0x001>;
+ device_type = "cpu";
+ enable-method = "psci";
+ i-cache-size = <0x8000>;
+ i-cache-line-size = <64>;
+ i-cache-sets = <256>;
+ d-cache-size = <0x8000>;
+ d-cache-line-size = <64>;
+ d-cache-sets = <128>;
+ next-level-cache = <&L2_0>;
+ };
+
+ cpu2: cpu@2 {
+ compatible = "arm,cortex-a53";
+ reg = <0x002>;
+ device_type = "cpu";
+ enable-method = "psci";
+ i-cache-size = <0x8000>;
+ i-cache-line-size = <64>;
+ i-cache-sets = <256>;
+ d-cache-size = <0x8000>;
+ d-cache-line-size = <64>;
+ d-cache-sets = <128>;
+ next-level-cache = <&L2_0>;
+ };
+
+ cpu3: cpu@3 {
+ compatible = "arm,cortex-a53";
+ reg = <0x003>;
+ device_type = "cpu";
+ enable-method = "psci";
+ i-cache-size = <0x8000>;
+ i-cache-line-size = <64>;
+ i-cache-sets = <256>;
+ d-cache-size = <0x8000>;
+ d-cache-line-size = <64>;
+ d-cache-sets = <128>;
+ next-level-cache = <&L2_0>;
+ };
+ };
+
+ L2_0: l2-cache0 {
+ compatible = "cache";
+ cache-level = <2>;
+ cache-size = <0x40000>;
+ cache-line-size = <64>;
+ cache-sets = <512>;
+ };
+};
--
2.35.1
On 08/02/2022 14:18, Vignesh Raghavendra wrote:
> The AM62 SoC family is the follow on AM335x built on K3 Multicore SoC
> architecture platform, providing ultra-low-power modes, dual display,
> multi-sensor edge compute, security and other BOM-saving integration.
> The AM62 SoC targets broad market to enable applications such as
> Industrial HMI, PLC/CNC/Robot control, Medical Equipment, Building
> Automation, Appliances and more.
>
> Some highlights of this SoC are:
>
> * Quad-Cortex-A53s (running up to 1.4GHz) in a single cluster.
> Pin-to-pin compatible options for single and quad core are available.
> * Cortex-M4F for general-purpose or safety usage.
> * Dual display support, providing 24-bit RBG parallel interface and
> OLDI/LVDS-4 Lane x2, up to 200MHz pixel clock support for 2K display
> resolution.
> * Selectable GPUsupport, up to 8GFLOPS, providing better user experience
> in 3D graphic display case and Android.
> * PRU(Programmable Realtime Unit) support for customized programmable
> interfaces/IOs.
> * Integrated Giga-bit Ethernet switch supporting up to a total of two
> external ports (TSN capable).
> * 9xUARTs, 5xSPI, 6xI2C, 2xUSB2, 3xCAN-FD, 3x eMMC and SD, GPMC for
> NAND/FPGA connection, OSPI memory controller, 3xMcASP for audio,
> 1x CSI-RX-4L for Camera, eCAP/eQEP, ePWM, among other peripherals.
> * Dedicated Centralized System Controller for Security, Power, and
> Resource Management.
> * Multiple low power modes support, ex: Deep sleep,Standby, MCU-only,
> enabling battery powered system design.
>
> This add bare minimum DT describing ARM compute clusters, Main, MCU and
> Wakeup domain and interconnects, UARTs and I2Cs to enable booting using
> ramdisk.
>
> More details can be found in the Technical Reference Manual:
> https://www.ti.com/lit/pdf/spruiv7
>
> Co-developed-by: Suman Anna <[email protected]>
> Signed-off-by: Suman Anna <[email protected]>
> Co-developed-by: Nishanth Menon <[email protected]>
> Signed-off-by: Nishanth Menon <[email protected]>
> Signed-off-by: Vignesh Raghavendra <[email protected]>
> ---
> arch/arm64/boot/dts/ti/k3-am62-main.dtsi | 263 +++++++++++++++++++++
> arch/arm64/boot/dts/ti/k3-am62-mcu.dtsi | 36 +++
> arch/arm64/boot/dts/ti/k3-am62-wakeup.dtsi | 41 ++++
> arch/arm64/boot/dts/ti/k3-am62.dtsi | 104 ++++++++
> arch/arm64/boot/dts/ti/k3-am625.dtsi | 103 ++++++++
> 5 files changed, 547 insertions(+)
> create mode 100644 arch/arm64/boot/dts/ti/k3-am62-main.dtsi
> create mode 100644 arch/arm64/boot/dts/ti/k3-am62-mcu.dtsi
> create mode 100644 arch/arm64/boot/dts/ti/k3-am62-wakeup.dtsi
> create mode 100644 arch/arm64/boot/dts/ti/k3-am62.dtsi
> create mode 100644 arch/arm64/boot/dts/ti/k3-am625.dtsi
>
(...)
> diff --git a/arch/arm64/boot/dts/ti/k3-am62.dtsi b/arch/arm64/boot/dts/ti/k3-am62.dtsi
> new file mode 100644
> index 000000000000..f1a46be27c37
> --- /dev/null
> +++ b/arch/arm64/boot/dts/ti/k3-am62.dtsi
> @@ -0,0 +1,104 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Device Tree Source for AM62 SoC Family
> + *
> + * Copyright (C) 2020-2022 Texas Instruments Incorporated - https://www.ti.com/
> + */
> +
> +#include <dt-bindings/gpio/gpio.h>
> +#include <dt-bindings/interrupt-controller/irq.h>
> +#include <dt-bindings/interrupt-controller/arm-gic.h>
> +#include <dt-bindings/pinctrl/k3.h>
> +#include <dt-bindings/soc/ti,sci_pm_domain.h>
> +
> +/ {
> + model = "Texas Instruments K3 AM625 SoC";
> + compatible = "ti,am625";
This is am625, but the file is am62. Why having the split?
> + interrupt-parent = <&gic500>;
> + #address-cells = <2>;
> + #size-cells = <2>;
> +
> + chosen { };
> +
> + firmware {
> + optee {
> + compatible = "linaro,optee-tz";
> + method = "smc";
> + };
> +
> + psci: psci {
> + compatible = "arm,psci-1.0";
> + method = "smc";
> + };
> + };
> +
> + a53_timer0: timer-cl0-cpu0 {
> + compatible = "arm,armv8-timer";
> + interrupts = <GIC_PPI 13 IRQ_TYPE_LEVEL_LOW>, /* cntpsirq */
> + <GIC_PPI 14 IRQ_TYPE_LEVEL_LOW>, /* cntpnsirq */
> + <GIC_PPI 11 IRQ_TYPE_LEVEL_LOW>, /* cntvirq */
> + <GIC_PPI 10 IRQ_TYPE_LEVEL_LOW>; /* cnthpirq */
> + };
> +
> + pmu: pmu {
> + compatible = "arm,cortex-a53-pmu";
> + interrupts = <GIC_PPI 7 IRQ_TYPE_LEVEL_HIGH>;
> + };
> +
> + cbass_main: bus@f0000 {
> + compatible = "simple-bus";
> + #address-cells = <2>;
> + #size-cells = <2>;
> +
> + ranges = <0x00 0x000f0000 0x00 0x000f0000 0x00 0x00030000>, /* Main MMRs */
> + <0x00 0x30040000 0x00 0x30040000 0x00 0x00080000>, /* PRUSS-M */
> + <0x00 0x00600000 0x00 0x00600000 0x00 0x00001100>, /* GPIO */
> + <0x00 0x00703000 0x00 0x00703000 0x00 0x00000200>, /* USB0 debug trace */
> + <0x00 0x0070C000 0x00 0x0070C000 0x00 0x00000200>, /* USB1 debug trace */
> + <0x00 0x00a40000 0x00 0x00a40000 0x00 0x00000800>, /* Timesync router */
> + <0x00 0x0fd00000 0x00 0x0fd00000 0x00 0x00020000>, /* GPU */
> + <0x00 0x01000000 0x00 0x01000000 0x00 0x01b28400>, /* First peripheral window */
> + <0x00 0x60000000 0x00 0x60000000 0x00 0x08000000>, /* FSS0 DAT1 */
> + <0x00 0x70000000 0x00 0x70000000 0x00 0x00010000>, /* OCSRAM */
> + <0x00 0x08000000 0x00 0x08000000 0x00 0x00200000>, /* Main CPSW */
> + <0x00 0x0e000000 0x00 0x0e000000 0x00 0x01d20000>, /* Second peripheral window */
> + <0x00 0x20000000 0x00 0x20000000 0x00 0x0a008000>, /* Third peripheral window */
> + <0x00 0x30200000 0x00 0x30200000 0x00 0x00010000>, /* DSS */
> + <0x00 0x43600000 0x00 0x43600000 0x00 0x00010000>, /* sa3 sproxy data */
> + <0x00 0x44043000 0x00 0x44043000 0x00 0x00000fe0>, /* TI SCI DEBUG */
> + <0x00 0x44860000 0x00 0x44860000 0x00 0x00040000>, /* sa3 sproxy config */
> + <0x00 0x48000000 0x00 0x48000000 0x00 0x06400000>, /* DMSS */
> + <0x00 0x60000000 0x00 0x60000000 0x00 0x08000000>, /* FSS0 DAT1 */
> + <0x05 0x00000000 0x05 0x00000000 0x01 0x00000000>, /* FSS0 DAT3 */
> + <0x00 0x31000000 0x00 0x31000000 0x00 0x00050000>, /* USB0 DWC3 Core window */
> + <0x00 0x31100000 0x00 0x31100000 0x00 0x00050000>, /* USB1 DWC3 Core window */
> + <0x00 0x30101000 0x00 0x30101000 0x00 0x00010100>, /* CSI window */
> +
> + /* MCU Domain Range */
> + <0x00 0x04000000 0x00 0x04000000 0x00 0x01ff1400>,
> +
> + /* Wakeup Domain Range */
> + <0x00 0x2b000000 0x00 0x2b000000 0x00 0x00300400>,
> + <0x00 0x43000000 0x00 0x43000000 0x00 0x00020000>;
> +
> + cbass_mcu: bus@4000000 {
> + compatible = "simple-bus";
> + #address-cells = <2>;
> + #size-cells = <2>;
> + ranges = <0x00 0x04000000 0x00 0x04000000 0x00 0x01ff1400>; /* Peripheral window */
> + };
> +
> + cbass_wakeup: bus@2b000000 {
> + compatible = "simple-bus";
> + #address-cells = <2>;
> + #size-cells = <2>;
> + ranges = <0x00 0x2b000000 0x00 0x2b000000 0x00 0x00300400>, /* Peripheral Window */
> + <0x00 0x43000000 0x00 0x43000000 0x00 0x00020000>;
> + };
> + };
> +};
> +
> +/* Now include the peripherals for each bus segments */
> +#include "k3-am62-main.dtsi"
> +#include "k3-am62-mcu.dtsi"
> +#include "k3-am62-wakeup.dtsi"
> diff --git a/arch/arm64/boot/dts/ti/k3-am625.dtsi b/arch/arm64/boot/dts/ti/k3-am625.dtsi
> new file mode 100644
> index 000000000000..887f31c23fef
> --- /dev/null
> +++ b/arch/arm64/boot/dts/ti/k3-am625.dtsi
> @@ -0,0 +1,103 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Device Tree Source for AM625 SoC family in Quad core configuration
> + *
> + * TRM: https://www.ti.com/lit/pdf/spruiv7
> + *
> + * Copyright (C) 2020-2022 Texas Instruments Incorporated - https://www.ti.com/
> + */
> +
> +/dts-v1/;
> +
> +#include "k3-am62.dtsi"
> +
> +/ {
> + cpus {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
This file is not included anywhere, so does it mean that your SoC comes
without the cores and each board designer plugs the cores separately?
Best regards,
Krzysztof
On 2022-02-08 13:18, Vignesh Raghavendra wrote:
> The AM62 SoC family is the follow on AM335x built on K3 Multicore SoC
> architecture platform, providing ultra-low-power modes, dual display,
> multi-sensor edge compute, security and other BOM-saving integration.
> The AM62 SoC targets broad market to enable applications such as
> Industrial HMI, PLC/CNC/Robot control, Medical Equipment, Building
> Automation, Appliances and more.
>
> Some highlights of this SoC are:
>
> * Quad-Cortex-A53s (running up to 1.4GHz) in a single cluster.
> Pin-to-pin compatible options for single and quad core are available.
> * Cortex-M4F for general-purpose or safety usage.
> * Dual display support, providing 24-bit RBG parallel interface and
> OLDI/LVDS-4 Lane x2, up to 200MHz pixel clock support for 2K display
> resolution.
> * Selectable GPUsupport, up to 8GFLOPS, providing better user
> experience
> in 3D graphic display case and Android.
> * PRU(Programmable Realtime Unit) support for customized programmable
> interfaces/IOs.
> * Integrated Giga-bit Ethernet switch supporting up to a total of two
> external ports (TSN capable).
> * 9xUARTs, 5xSPI, 6xI2C, 2xUSB2, 3xCAN-FD, 3x eMMC and SD, GPMC for
> NAND/FPGA connection, OSPI memory controller, 3xMcASP for audio,
> 1x CSI-RX-4L for Camera, eCAP/eQEP, ePWM, among other peripherals.
> * Dedicated Centralized System Controller for Security, Power, and
> Resource Management.
> * Multiple low power modes support, ex: Deep sleep,Standby, MCU-only,
> enabling battery powered system design.
>
> This add bare minimum DT describing ARM compute clusters, Main, MCU and
> Wakeup domain and interconnects, UARTs and I2Cs to enable booting using
> ramdisk.
>
> More details can be found in the Technical Reference Manual:
> https://www.ti.com/lit/pdf/spruiv7
>
> Co-developed-by: Suman Anna <[email protected]>
> Signed-off-by: Suman Anna <[email protected]>
> Co-developed-by: Nishanth Menon <[email protected]>
> Signed-off-by: Nishanth Menon <[email protected]>
> Signed-off-by: Vignesh Raghavendra <[email protected]>
> ---
> arch/arm64/boot/dts/ti/k3-am62-main.dtsi | 263 +++++++++++++++++++++
> arch/arm64/boot/dts/ti/k3-am62-mcu.dtsi | 36 +++
> arch/arm64/boot/dts/ti/k3-am62-wakeup.dtsi | 41 ++++
> arch/arm64/boot/dts/ti/k3-am62.dtsi | 104 ++++++++
> arch/arm64/boot/dts/ti/k3-am625.dtsi | 103 ++++++++
> 5 files changed, 547 insertions(+)
> create mode 100644 arch/arm64/boot/dts/ti/k3-am62-main.dtsi
> create mode 100644 arch/arm64/boot/dts/ti/k3-am62-mcu.dtsi
> create mode 100644 arch/arm64/boot/dts/ti/k3-am62-wakeup.dtsi
> create mode 100644 arch/arm64/boot/dts/ti/k3-am62.dtsi
> create mode 100644 arch/arm64/boot/dts/ti/k3-am625.dtsi
>
> diff --git a/arch/arm64/boot/dts/ti/k3-am62-main.dtsi
> b/arch/arm64/boot/dts/ti/k3-am62-main.dtsi
> new file mode 100644
> index 000000000000..81d6d99ca180
> --- /dev/null
> +++ b/arch/arm64/boot/dts/ti/k3-am62-main.dtsi
> @@ -0,0 +1,263 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Device Tree Source for AM625 SoC Family Main Domain peripherals
> + *
> + * Copyright (C) 2020-2022 Texas Instruments Incorporated -
> https://www.ti.com/
> + */
> +
> +&cbass_main {
> + gic500: interrupt-controller@1800000 {
> + compatible = "arm,gic-v3";
> + #address-cells = <2>;
> + #size-cells = <2>;
> + ranges;
> + #interrupt-cells = <3>;
> + interrupt-controller;
> + reg = <0x00 0x01800000 0x00 0x10000>, /* GICD */
> + <0x00 0x01880000 0x00 0xC0000>; /* GICR */
Usual rant: you are missing the GICC, GICH and GICV regions
that are implemented by the CPU. Cortex-A53 implements them
(they are not optional), so please describe them.
> + /*
> + * vcpumntirq:
> + * virtual CPU interface maintenance interrupt
> + */
> + interrupts = <GIC_PPI 9 IRQ_TYPE_LEVEL_HIGH>;
> +
> + gic_its: msi-controller@1820000 {
> + compatible = "arm,gic-v3-its";
> + reg = <0x00 0x01820000 0x00 0x10000>;
> + socionext,synquacer-pre-its = <0x1000000 0x400000>;
The mind boggles...
M.
--
Jazz is not dead. It just smells funny...
Hi Krzysztof,
On 08/02/22 10:35 pm, Krzysztof Kozlowski wrote:
[...]
>
> (...)
>
>> diff --git a/arch/arm64/boot/dts/ti/k3-am62.dtsi b/arch/arm64/boot/dts/ti/k3-am62.dtsi
>> new file mode 100644
>> index 000000000000..f1a46be27c37
>> --- /dev/null
>> +++ b/arch/arm64/boot/dts/ti/k3-am62.dtsi
>> @@ -0,0 +1,104 @@
>> +// SPDX-License-Identifier: GPL-2.0
>> +/*
>> + * Device Tree Source for AM62 SoC Family
>> + *
>> + * Copyright (C) 2020-2022 Texas Instruments Incorporated - https://www.ti.com/
>> + */
>> +
>> +#include <dt-bindings/gpio/gpio.h>
>> +#include <dt-bindings/interrupt-controller/irq.h>
>> +#include <dt-bindings/interrupt-controller/arm-gic.h>
>> +#include <dt-bindings/pinctrl/k3.h>
>> +#include <dt-bindings/soc/ti,sci_pm_domain.h>
>> +
>> +/ {
>> + model = "Texas Instruments K3 AM625 SoC";
>> + compatible = "ti,am625";
>
> This is am625, but the file is am62. Why having the split?
Hierarchy is:
am62.dtsi:
-> base SoC skeleton ie arch timers and interconnects which is common
across am62xx family of SoCs
-> includes am62-main.dtsi, am62-mcu.dtsi and am62-wakeup.dtsi
representing 3 domains and peripherals in each of these domain
-> describes all peripherals in the family (except CPU cluster)
am625.dtsi:
-> describes CPU cluster (Quad A53s). Since, am625 is a current superset
device with all peripherals, am625.dtsi includes am62.dtsi completing
SoC definition.
-> individual EVMs using this SoC will just need to include am625.dtsi
thus making things easier for Board and SOM Vendors.
In future:
am62{1-9}{1-9}.dtsi:
-> Includes am625.dtsi
-> Overrides top compatible: ti,am62{1-9}{1-9}
-> disables CPUs and peripherals not present (cutdowns of current SoC).
-> -> individual EVM dts files using this SoC will just need to include
am625.dtsi as starting point, thus making things easier for Board and
SOM Vendors.
Top level compatible is set to "ti,am625.dtsi" which is first device in
family and superset.
Hope this clears up? Will add this to commit msg
>
>> + interrupt-parent = <&gic500>;
>> + #address-cells = <2>;
>> + #size-cells = <2>;
>> +
>> + chosen { };
>> +
>> + firmware {
>> + optee {
>> + compatible = "linaro,optee-tz";
>> + method = "smc";
>> + };
>> +
>> + psci: psci {
>> + compatible = "arm,psci-1.0";
>> + method = "smc";
>> + };
>> + };
>> +
>> + a53_timer0: timer-cl0-cpu0 {
>> + compatible = "arm,armv8-timer";
>> + interrupts = <GIC_PPI 13 IRQ_TYPE_LEVEL_LOW>, /* cntpsirq */
>> + <GIC_PPI 14 IRQ_TYPE_LEVEL_LOW>, /* cntpnsirq */
>> + <GIC_PPI 11 IRQ_TYPE_LEVEL_LOW>, /* cntvirq */
>> + <GIC_PPI 10 IRQ_TYPE_LEVEL_LOW>; /* cnthpirq */
>> + };
>> +
>> + pmu: pmu {
>> + compatible = "arm,cortex-a53-pmu";
>> + interrupts = <GIC_PPI 7 IRQ_TYPE_LEVEL_HIGH>;
>> + };
>> +
>> + cbass_main: bus@f0000 {
>> + compatible = "simple-bus";
>> + #address-cells = <2>;
>> + #size-cells = <2>;
>> +
>> + ranges = <0x00 0x000f0000 0x00 0x000f0000 0x00 0x00030000>, /* Main MMRs */
>> + <0x00 0x30040000 0x00 0x30040000 0x00 0x00080000>, /* PRUSS-M */
>> + <0x00 0x00600000 0x00 0x00600000 0x00 0x00001100>, /* GPIO */
>> + <0x00 0x00703000 0x00 0x00703000 0x00 0x00000200>, /* USB0 debug trace */
>> + <0x00 0x0070C000 0x00 0x0070C000 0x00 0x00000200>, /* USB1 debug trace */
>> + <0x00 0x00a40000 0x00 0x00a40000 0x00 0x00000800>, /* Timesync router */
>> + <0x00 0x0fd00000 0x00 0x0fd00000 0x00 0x00020000>, /* GPU */
>> + <0x00 0x01000000 0x00 0x01000000 0x00 0x01b28400>, /* First peripheral window */
>> + <0x00 0x60000000 0x00 0x60000000 0x00 0x08000000>, /* FSS0 DAT1 */
>> + <0x00 0x70000000 0x00 0x70000000 0x00 0x00010000>, /* OCSRAM */
>> + <0x00 0x08000000 0x00 0x08000000 0x00 0x00200000>, /* Main CPSW */
>> + <0x00 0x0e000000 0x00 0x0e000000 0x00 0x01d20000>, /* Second peripheral window */
>> + <0x00 0x20000000 0x00 0x20000000 0x00 0x0a008000>, /* Third peripheral window */
>> + <0x00 0x30200000 0x00 0x30200000 0x00 0x00010000>, /* DSS */
>> + <0x00 0x43600000 0x00 0x43600000 0x00 0x00010000>, /* sa3 sproxy data */
>> + <0x00 0x44043000 0x00 0x44043000 0x00 0x00000fe0>, /* TI SCI DEBUG */
>> + <0x00 0x44860000 0x00 0x44860000 0x00 0x00040000>, /* sa3 sproxy config */
>> + <0x00 0x48000000 0x00 0x48000000 0x00 0x06400000>, /* DMSS */
>> + <0x00 0x60000000 0x00 0x60000000 0x00 0x08000000>, /* FSS0 DAT1 */
>> + <0x05 0x00000000 0x05 0x00000000 0x01 0x00000000>, /* FSS0 DAT3 */
>> + <0x00 0x31000000 0x00 0x31000000 0x00 0x00050000>, /* USB0 DWC3 Core window */
>> + <0x00 0x31100000 0x00 0x31100000 0x00 0x00050000>, /* USB1 DWC3 Core window */
>> + <0x00 0x30101000 0x00 0x30101000 0x00 0x00010100>, /* CSI window */
>> +
>> + /* MCU Domain Range */
>> + <0x00 0x04000000 0x00 0x04000000 0x00 0x01ff1400>,
>> +
>> + /* Wakeup Domain Range */
>> + <0x00 0x2b000000 0x00 0x2b000000 0x00 0x00300400>,
>> + <0x00 0x43000000 0x00 0x43000000 0x00 0x00020000>;
>> +
>> + cbass_mcu: bus@4000000 {
>> + compatible = "simple-bus";
>> + #address-cells = <2>;
>> + #size-cells = <2>;
>> + ranges = <0x00 0x04000000 0x00 0x04000000 0x00 0x01ff1400>; /* Peripheral window */
>> + };
>> +
>> + cbass_wakeup: bus@2b000000 {
>> + compatible = "simple-bus";
>> + #address-cells = <2>;
>> + #size-cells = <2>;
>> + ranges = <0x00 0x2b000000 0x00 0x2b000000 0x00 0x00300400>, /* Peripheral Window */
>> + <0x00 0x43000000 0x00 0x43000000 0x00 0x00020000>;
>> + };
>> + };
>> +};
>> +
>> +/* Now include the peripherals for each bus segments */
>> +#include "k3-am62-main.dtsi"
>> +#include "k3-am62-mcu.dtsi"
>> +#include "k3-am62-wakeup.dtsi"
>> diff --git a/arch/arm64/boot/dts/ti/k3-am625.dtsi b/arch/arm64/boot/dts/ti/k3-am625.dtsi
>> new file mode 100644
>> index 000000000000..887f31c23fef
>> --- /dev/null
>> +++ b/arch/arm64/boot/dts/ti/k3-am625.dtsi
>> @@ -0,0 +1,103 @@
>> +// SPDX-License-Identifier: GPL-2.0
>> +/*
>> + * Device Tree Source for AM625 SoC family in Quad core configuration
>> + *
>> + * TRM: https://www.ti.com/lit/pdf/spruiv7
>> + *
>> + * Copyright (C) 2020-2022 Texas Instruments Incorporated - https://www.ti.com/
>> + */
>> +
>> +/dts-v1/;
>> +
>> +#include "k3-am62.dtsi"
>> +
>> +/ {
>> + cpus {
>> + #address-cells = <1>;
>> + #size-cells = <0>;
>> +
>
> This file is not included anywhere, so does it mean that your SoC comes
> without the cores and each board designer plugs the cores separately?
>
Please see above for explanation. File is included in am625-sk.dts (see
5/5).
>
> Best regards,
> Krzysztof
On 09/02/2022 20:04, Vignesh Raghavendra wrote:
> Hi Krzysztof,
>
> On 08/02/22 10:35 pm, Krzysztof Kozlowski wrote:
> [...]
>>
>> (...)
>>
>>> diff --git a/arch/arm64/boot/dts/ti/k3-am62.dtsi b/arch/arm64/boot/dts/ti/k3-am62.dtsi
>>> new file mode 100644
>>> index 000000000000..f1a46be27c37
>>> --- /dev/null
>>> +++ b/arch/arm64/boot/dts/ti/k3-am62.dtsi
>>> @@ -0,0 +1,104 @@
>>> +// SPDX-License-Identifier: GPL-2.0
>>> +/*
>>> + * Device Tree Source for AM62 SoC Family
>>> + *
>>> + * Copyright (C) 2020-2022 Texas Instruments Incorporated - https://www.ti.com/
>>> + */
>>> +
>>> +#include <dt-bindings/gpio/gpio.h>
>>> +#include <dt-bindings/interrupt-controller/irq.h>
>>> +#include <dt-bindings/interrupt-controller/arm-gic.h>
>>> +#include <dt-bindings/pinctrl/k3.h>
>>> +#include <dt-bindings/soc/ti,sci_pm_domain.h>
>>> +
>>> +/ {
>>> + model = "Texas Instruments K3 AM625 SoC";
>>> + compatible = "ti,am625";
>>
>> This is am625, but the file is am62. Why having the split?
>
>
> Hierarchy is:
>
> am62.dtsi:
> -> base SoC skeleton ie arch timers and interconnects which is common
> across am62xx family of SoCs
> -> includes am62-main.dtsi, am62-mcu.dtsi and am62-wakeup.dtsi
> representing 3 domains and peripherals in each of these domain
> -> describes all peripherals in the family (except CPU cluster)
>
>
> am625.dtsi:
> -> describes CPU cluster (Quad A53s). Since, am625 is a current superset
> device with all peripherals, am625.dtsi includes am62.dtsi completing
> SoC definition.
> -> individual EVMs using this SoC will just need to include am625.dtsi
> thus making things easier for Board and SOM Vendors.
>
>
> In future:
> am62{1-9}{1-9}.dtsi:
> -> Includes am625.dtsi
> -> Overrides top compatible: ti,am62{1-9}{1-9}
> -> disables CPUs and peripherals not present (cutdowns of current SoC).
> -> -> individual EVM dts files using this SoC will just need to include
> am625.dtsi as starting point, thus making things easier for Board and
> SOM Vendors.
>
> Top level compatible is set to "ti,am625.dtsi" which is first device in
> family and superset.
>
> Hope this clears up? Will add this to commit msg
>
Hm, if I understand correctly: you might have later some future
am6211.dtsi which includes am625.dtsi and in general is compatible with
am625 but with disabled parts?
It's as bit counter-intuitive - I expect compatible to be extended
instead of overridden. But it looks also ok, if you build entire design
around it.
Best regards,
Krzysztof
On 19:10-20220209, Marc Zyngier wrote:
[...]
> > +&cbass_main {
> > + gic500: interrupt-controller@1800000 {
> > + compatible = "arm,gic-v3";
> > + #address-cells = <2>;
> > + #size-cells = <2>;
> > + ranges;
> > + #interrupt-cells = <3>;
> > + interrupt-controller;
> > + reg = <0x00 0x01800000 0x00 0x10000>, /* GICD */
> > + <0x00 0x01880000 0x00 0xC0000>; /* GICR */
>
> Usual rant: you are missing the GICC, GICH and GICV regions
> that are implemented by the CPU. Cortex-A53 implements them
> (they are not optional), so please describe them.
>
-ECONFUSED. TRM for GIC500 refers to just GICD, GICR and ITS range[1].
Same thing is indicated by Generic Interrupt Controller Architecture
Specification[2] See table 1-1 (page 23).
I think you are expecting GICV3's backward compatibility mode (Table 1-2
in page 24), But in K3 architecture, are_option meant for backward
compatibility is set to true (aka no backward compatibility). I think
this did popup sometime back as well (first k3 SoC)[3]. I think the more
clearer description is available in [4].
I believe the argumentation that GICC/H/V is mandatory for A53 if GIC500
is used is not accurate. Please correct me if I am mistaken.
[1] https://developer.arm.com/documentation/ddi0516/e/programmers-model/the-gic-500-register-map?lang=en
[2] https://developer.arm.com/documentation/ihi0069/d
[3] https://patchwork.kernel.org/project/linux-arm-kernel/patch/20180607233853.p7iw7nlxxuyi66og@kahuna/
[4] https://developer.arm.com/documentation/ddi0516/e/functional-description/operation/backwards-compatibility?lang=en
--
Regards,
Nishanth Menon
Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5 849D 1736 249D
On Thu, 10 Feb 2022 19:34:59 +0000,
Nishanth Menon <[email protected]> wrote:
>
> On 19:10-20220209, Marc Zyngier wrote:
> [...]
>
> > > +&cbass_main {
> > > + gic500: interrupt-controller@1800000 {
> > > + compatible = "arm,gic-v3";
> > > + #address-cells = <2>;
> > > + #size-cells = <2>;
> > > + ranges;
> > > + #interrupt-cells = <3>;
> > > + interrupt-controller;
> > > + reg = <0x00 0x01800000 0x00 0x10000>, /* GICD */
> > > + <0x00 0x01880000 0x00 0xC0000>; /* GICR */
> >
> > Usual rant: you are missing the GICC, GICH and GICV regions
> > that are implemented by the CPU. Cortex-A53 implements them
> > (they are not optional), so please describe them.
> >
>
>
> -ECONFUSED. TRM for GIC500 refers to just GICD, GICR and ITS range[1].
And I'm not talking about the GIC, but of the CPU interface. The fact
that we describe both in the GIC binding doesn't mean they are
implemented by the same IP block (and the architecture is quite clear
about that).
> Same thing is indicated by Generic Interrupt Controller Architecture
> Specification[2] See table 1-1 (page 23).
>
> I think you are expecting GICV3's backward compatibility mode (Table 1-2
> in page 24), But in K3 architecture, are_option meant for backward
> compatibility is set to true (aka no backward compatibility). I think
> this did popup sometime back as well (first k3 SoC)[3]. I think the more
> clearer description is available in [4].
No, this description is for the architecture as a whole. ARE being
disabled *int the GIC* doesn't mean it is disabled overall, and the
CPU is free to implement the CPU interface by any mean it wants as
long as it communicates with the GIC using the Stream Protocol.
Cortex-A32, A34, 35, A53, A57, A72 and A73 all implement both the
sysreg and MMIO CPU interfaces. Later ARM CPUs don't. Both can work
with GIC500.
> I believe the argumentation that GICC/H/V is mandatory for A53 if GIC500
> is used is not accurate. Please correct me if I am mistaken.
GIC500 is not involved at all, and A53 always implements both the
system register and MMIO interfaces. See the A53 TRM, chapter 9. The
only way to disable this interface is to assert GICCDISABLE, which
disables the whole of the CPU interface. Given that you have a (more
or less) functional system, it probably isn't the case.
See Table 9-1, which tells you where these registers are as an offset
from PERIPHBASE. Dumping these registers should show you that they are
indeed implemented and not solely a figment of my own imagination.
Thanks,
M.
--
Without deviation from the norm, progress is not possible.
On 11:33-20220211, Marc Zyngier wrote:
> On Thu, 10 Feb 2022 19:34:59 +0000,
> Nishanth Menon <[email protected]> wrote:
> >
> > On 19:10-20220209, Marc Zyngier wrote:
> > [...]
> >
> > > > +&cbass_main {
> > > > + gic500: interrupt-controller@1800000 {
> > > > + compatible = "arm,gic-v3";
> > > > + #address-cells = <2>;
> > > > + #size-cells = <2>;
> > > > + ranges;
> > > > + #interrupt-cells = <3>;
> > > > + interrupt-controller;
> > > > + reg = <0x00 0x01800000 0x00 0x10000>, /* GICD */
> > > > + <0x00 0x01880000 0x00 0xC0000>; /* GICR */
> > >
> > > Usual rant: you are missing the GICC, GICH and GICV regions
> > > that are implemented by the CPU. Cortex-A53 implements them
> > > (they are not optional), so please describe them.
> > >
> >
> >
> > -ECONFUSED. TRM for GIC500 refers to just GICD, GICR and ITS range[1].
>
> And I'm not talking about the GIC, but of the CPU interface. The fact
> that we describe both in the GIC binding doesn't mean they are
> implemented by the same IP block (and the architecture is quite clear
> about that).
>
> > Same thing is indicated by Generic Interrupt Controller Architecture
> > Specification[2] See table 1-1 (page 23).
> >
> > I think you are expecting GICV3's backward compatibility mode (Table 1-2
> > in page 24), But in K3 architecture, are_option meant for backward
> > compatibility is set to true (aka no backward compatibility). I think
> > this did popup sometime back as well (first k3 SoC)[3]. I think the more
> > clearer description is available in [4].
>
> No, this description is for the architecture as a whole. ARE being
> disabled *int the GIC* doesn't mean it is disabled overall, and the
> CPU is free to implement the CPU interface by any mean it wants as
> long as it communicates with the GIC using the Stream Protocol.
> Cortex-A32, A34, 35, A53, A57, A72 and A73 all implement both the
> sysreg and MMIO CPU interfaces. Later ARM CPUs don't. Both can work
> with GIC500.
>
> > I believe the argumentation that GICC/H/V is mandatory for A53 if GIC500
> > is used is not accurate. Please correct me if I am mistaken.
>
> GIC500 is not involved at all, and A53 always implements both the
> system register and MMIO interfaces. See the A53 TRM, chapter 9. The
> only way to disable this interface is to assert GICCDISABLE, which
> disables the whole of the CPU interface. Given that you have a (more
> or less) functional system, it probably isn't the case.
>
> See Table 9-1, which tells you where these registers are as an offset
> from PERIPHBASE. Dumping these registers should show you that they are
> indeed implemented and not solely a figment of my own imagination.
Thanks for explaining.. I don't see this is working in practise.. Let me
know if I am making a mistake in my interpretation.
Quote from our internal integration spec (yep it leaves it to ARM cluster's
use):
""
Note: GIC periphery base tieoff to ARM corepacs for GIC v2 compatibility
requires a dedicated unallocated space to be passed as input to ARM corepac.
The CC internal region 0F00_0000-0x0F03_FFFF is assigned as GIC periphery
base tieoff to the corepac.
When GIC-500 is in v3 mode, and A72 with GICCDISABLE=0 and PERIPHBASE set:
- the CPU interface registers are accessed via ICC* system register.
- the GICC* regions (PERIPHBASE - PERIPHBASE+0x3FFFF) are reserved
and access will be Read as Zero / Write Ignored.
So any writes/reads to this region would be trapped by ARM corepacs.
""
Anyways, Here is my report. I checked across all K3 devices (a72 and
a53)
AM65x: PERIPH_BASE = 0x6f000000 (a53)
j721e: PERIPH_BASE = 0x6f000000 (a72)
J7200: PERIPH_BASE = 0x6f000000 (a72)
j721s2: PERIPH_BASE = 0x6f000000 (a72)
AM64: PERIPH_BASE = 0x100000000 (a53)
AM62: PERIPH_BASE = 0x100000000 (a53)
(side note: am64/62 needed the 0x6f.. address space for PCIe stuff.. but
the address chosen has nothing in SoC fabric)
Tested at u-boot shell prompt (running at EL2):
If I understood the expectation correctly..I should be seeing offsets
off [1]. Taking 'CPU Interface'/GICC as an example, [2] should be the
registers I should be seeing. aka, at offset 0xfc from PERIPHBASE, i
should see 0x0034443B.
Note: on K3 devices (in the 32bit address space), as in the
description above, we have a null endpoint handler in the bus fabric
that responds with 0x0 for read requests for invalid/reserved addresses.
What I see is 0x0 (and not IIDR) in all the address ranges - which matches ARM
sending that region requests straight down to SoC level and SoC
returning "ignore"..
On AM62, I attached Lauterbach. and tried to look at the addresses: [3]
from cpu view and from bus view.
I also checked from kernel side with devmem to make sure to dump while
kernel GICV3 is active.. I see the same thing as well..
Is there something TFA or someone has to do to "enable" this? I tried
re-reading porting-guide.rst yet again to make sure we have'nt missed
anything.
[1] https://developer.arm.com/documentation/ddi0500/j/Generic-Interrupt-Controller-CPU-Interface/GIC-programmers-model/Memory-map?lang=en
[2] https://developer.arm.com/documentation/ddi0500/j/Generic-Interrupt-Controller-CPU-Interface/GIC-programmers-model/CPU-interface-register-summary
[3] https://pasteboard.co/3O44PAwLeAXz.png
--
Regards,
Nishanth Menon
Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5 849D 1736 249D
On Fri, 11 Feb 2022 23:55:13 +0000,
Nishanth Menon <[email protected]> wrote:
>
> On 11:33-20220211, Marc Zyngier wrote:
> > On Thu, 10 Feb 2022 19:34:59 +0000,
> > Nishanth Menon <[email protected]> wrote:
> > >
> > > On 19:10-20220209, Marc Zyngier wrote:
> > > [...]
> > >
> > > > > +&cbass_main {
> > > > > + gic500: interrupt-controller@1800000 {
> > > > > + compatible = "arm,gic-v3";
> > > > > + #address-cells = <2>;
> > > > > + #size-cells = <2>;
> > > > > + ranges;
> > > > > + #interrupt-cells = <3>;
> > > > > + interrupt-controller;
> > > > > + reg = <0x00 0x01800000 0x00 0x10000>, /* GICD */
> > > > > + <0x00 0x01880000 0x00 0xC0000>; /* GICR */
> > > >
> > > > Usual rant: you are missing the GICC, GICH and GICV regions
> > > > that are implemented by the CPU. Cortex-A53 implements them
> > > > (they are not optional), so please describe them.
> > > >
> > >
> > >
> > > -ECONFUSED. TRM for GIC500 refers to just GICD, GICR and ITS range[1].
> >
> > And I'm not talking about the GIC, but of the CPU interface. The fact
> > that we describe both in the GIC binding doesn't mean they are
> > implemented by the same IP block (and the architecture is quite clear
> > about that).
> >
> > > Same thing is indicated by Generic Interrupt Controller Architecture
> > > Specification[2] See table 1-1 (page 23).
> > >
> > > I think you are expecting GICV3's backward compatibility mode (Table 1-2
> > > in page 24), But in K3 architecture, are_option meant for backward
> > > compatibility is set to true (aka no backward compatibility). I think
> > > this did popup sometime back as well (first k3 SoC)[3]. I think the more
> > > clearer description is available in [4].
> >
> > No, this description is for the architecture as a whole. ARE being
> > disabled *int the GIC* doesn't mean it is disabled overall, and the
> > CPU is free to implement the CPU interface by any mean it wants as
> > long as it communicates with the GIC using the Stream Protocol.
> > Cortex-A32, A34, 35, A53, A57, A72 and A73 all implement both the
> > sysreg and MMIO CPU interfaces. Later ARM CPUs don't. Both can work
> > with GIC500.
> >
> > > I believe the argumentation that GICC/H/V is mandatory for A53 if GIC500
> > > is used is not accurate. Please correct me if I am mistaken.
> >
> > GIC500 is not involved at all, and A53 always implements both the
> > system register and MMIO interfaces. See the A53 TRM, chapter 9. The
> > only way to disable this interface is to assert GICCDISABLE, which
> > disables the whole of the CPU interface. Given that you have a (more
> > or less) functional system, it probably isn't the case.
> >
> > See Table 9-1, which tells you where these registers are as an offset
> > from PERIPHBASE. Dumping these registers should show you that they are
> > indeed implemented and not solely a figment of my own imagination.
>
> Thanks for explaining.. I don't see this is working in practise.. Let me
> know if I am making a mistake in my interpretation.
>
> Quote from our internal integration spec (yep it leaves it to ARM cluster's
> use):
> ""
> Note: GIC periphery base tieoff to ARM corepacs for GIC v2 compatibility
> requires a dedicated unallocated space to be passed as input to ARM corepac.
> The CC internal region 0F00_0000-0x0F03_FFFF is assigned as GIC periphery
> base tieoff to the corepac.
> When GIC-500 is in v3 mode, and A72 with GICCDISABLE=0 and PERIPHBASE set:
> - the CPU interface registers are accessed via ICC* system register.
> - the GICC* regions (PERIPHBASE - PERIPHBASE+0x3FFFF) are reserved
> and access will be Read as Zero / Write Ignored.
> So any writes/reads to this region would be trapped by ARM corepacs.
> ""
Not sure what the 'corepacs' are (the CPU cluster?). But what I
understand is that accesses to the GIC regions are kept internal to
the 'corepacs', which is exactly what is expected.
>
> Anyways, Here is my report. I checked across all K3 devices (a72 and
> a53)
> AM65x: PERIPH_BASE = 0x6f000000 (a53)
> j721e: PERIPH_BASE = 0x6f000000 (a72)
> J7200: PERIPH_BASE = 0x6f000000 (a72)
> j721s2: PERIPH_BASE = 0x6f000000 (a72)
> AM64: PERIPH_BASE = 0x100000000 (a53)
> AM62: PERIPH_BASE = 0x100000000 (a53)
>
> (side note: am64/62 needed the 0x6f.. address space for PCIe stuff.. but
> the address chosen has nothing in SoC fabric)
>
> Tested at u-boot shell prompt (running at EL2):
>
> If I understood the expectation correctly..I should be seeing offsets
> off [1]. Taking 'CPU Interface'/GICC as an example, [2] should be the
> registers I should be seeing. aka, at offset 0xfc from PERIPHBASE, i
> should see 0x0034443B.
If ICC_SRE_EL3.SRE is 1, this is more or less expected. You can only
use one or the other at any given time, not both.
The more important thing is that GICV is what we give to a VM running
in compat mode. With HCR_EL2.{AMO,FMO,IMO}={1,1,1} and
ICC_SRE_EL1.SRE==0, the guest can access a MMIO virtual GIC interface,
and the hypervisor does its magic.
>
> Note: on K3 devices (in the 32bit address space), as in the
> description above, we have a null endpoint handler in the bus fabric
> that responds with 0x0 for read requests for invalid/reserved addresses.
>
> What I see is 0x0 (and not IIDR) in all the address ranges - which matches ARM
> sending that region requests straight down to SoC level and SoC
> returning "ignore"..
>
> On AM62, I attached Lauterbach. and tried to look at the addresses: [3]
> from cpu view and from bus view.
>
> I also checked from kernel side with devmem to make sure to dump while
> kernel GICV3 is active.. I see the same thing as well..
>
> Is there something TFA or someone has to do to "enable" this? I tried
> re-reading porting-guide.rst yet again to make sure we have'nt missed
> anything.
I expect the SRE settings to control all of this, most of which are
under NS control. You could easily check this by advertising the 3
missing regions in DT, booting an upstream kernel with KVM and boot a
GICv2 guest. KVM will also warn if the DT regions are advertised but
the HW doesn't actually support the MMIO accesses. Feel free to ping
me offline if you need the runs for this,
M.
--
Without deviation from the norm, progress is not possible.
On 11:40-20220212, Marc Zyngier wrote:
[...]
> I expect the SRE settings to control all of this, most of which are
> under NS control. You could easily check this by advertising the 3
> missing regions in DT, booting an upstream kernel with KVM and boot a
> GICv2 guest. KVM will also warn if the DT regions are advertised but
> the HW doesn't actually support the MMIO accesses. Feel free to ping
> me offline if you need the runs for this,
Thanks for the offline guidance and clarification. fixup patches for
existing K3 devices posted in [1].
[1] https://lore.kernel.org/all/[email protected]/
--
Regards,
Nishanth Menon
Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5 849D 1736 249D
