[PATCH 2/3] arm64: dts: ti: Add Support for AM642 SoC
Dave Gerlach
d-gerlach at ti.com
Mon Jan 4 23:02:36 EST 2021
Suman,
On 12/3/20 4:00 PM, Suman Anna wrote:
> On 12/3/20 3:56 PM, Suman Anna wrote:
>> Hi Dave,
>>
>> On 11/24/20 11:20 PM, Dave Gerlach wrote:
>>> The AM642 SoC belongs to the K3 Multicore SoC architecture platform,
>>> providing advanced system integration to enable applications such as
>>> Motor Drives, PLC, Remote IO and IoT Gateways.
>>>
>>> Some highlights of this SoC are:
>>> * Dual Cortex-A53s in a single cluster, two clusters of dual Cortex-R5F
>>> MCUs, and a single Cortex-M4F.
>>> * Two Gigabit Industrial Communication Subsystems (ICSSG).
>>> * Integrated Ethernet switch supporting up to a total of two external
>>> ports.
>>> * PCIe-GEN2x1L, USB3/USB2, 2xCAN-FD, eMMC and SD, UFS, OSPI memory
>>> controller, QSPI, I2C, eCAP/eQEP, ePWM, ADC, among other
>>> peripherals.
>>> * Centralized System Controller for Security, Power, and Resource
>>> Management (DMSC).
>>>
>>> See AM64X Technical Reference Manual (SPRUIM2, Nov 2020)
>>> for further details: https://www.ti.com/lit/pdf/spruim2
>>>
>>> Introduce basic support for the AM642 SoC to enable minimal
>>> ramdisk boot. Introduce a limited set of MAIN domain periperhals
>>> under cbass_main and a placeholder cbass_mcu node for future MCU
>>> domain usage.
>>>
>>> Signed-off-by: Dave Gerlach <d-gerlach at ti.com>
>>> ---
>>> arch/arm64/boot/dts/ti/k3-am64-main.dtsi | 178 +++++++++++++++++++++++
>>> arch/arm64/boot/dts/ti/k3-am64.dtsi | 95 ++++++++++++
>>> arch/arm64/boot/dts/ti/k3-am642.dtsi | 65 +++++++++
>>> 3 files changed, 338 insertions(+)
>>> create mode 100644 arch/arm64/boot/dts/ti/k3-am64-main.dtsi
>>> create mode 100644 arch/arm64/boot/dts/ti/k3-am64.dtsi
>>> create mode 100644 arch/arm64/boot/dts/ti/k3-am642.dtsi
>>>
... snip ...
>>> + main_uart6: serial at 2860000 {
>>> + compatible = "ti,am64-uart", "ti,am654-uart";
>>> + reg = <0x00 0x02860000 0x00 0x100>;
>>> + reg-shift = <2>;
>>> + reg-io-width = <4>;
>>> + interrupts = <GIC_SPI 184 IRQ_TYPE_LEVEL_HIGH>;
>>> + clock-frequency = <48000000>;
>>> + current-speed = <115200>;
>>> + power-domains = <&k3_pds 158 TI_SCI_PD_EXCLUSIVE>;
>>> + clocks = <&k3_clks 158 0>;
>>> + clock-names = "fclk";
>>> + };
>>> +};
>>> diff --git a/arch/arm64/boot/dts/ti/k3-am64.dtsi b/arch/arm64/boot/dts/ti/k3-am64.dtsi
>>> new file mode 100644
>>> index 000000000000..0637cf9ede5f
>>> --- /dev/null
>>> +++ b/arch/arm64/boot/dts/ti/k3-am64.dtsi
>>> @@ -0,0 +1,95 @@
>>> +// SPDX-License-Identifier: GPL-2.0
>>> +/*
>>> + * Device Tree Source for AM642 SoC Family
>>> + *
>>> + * Copyright (C) 2020 Texas Instruments Incorporated - https://www.ti.com/
>>> + */
>>> +
>>> +#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 AM642 SoC";
>>> + compatible = "ti,am642";
>>> + interrupt-parent = <&gic500>;
>>> + #address-cells = <2>;
>>> + #size-cells = <2>;
>>> +
>>> + aliases {
>>> + serial2 = &main_uart0;
>>> + serial3 = &main_uart1;
>>> + serial4 = &main_uart2;
>>> + serial5 = &main_uart3;
>>> + serial6 = &main_uart4;
>>> + serial7 = &main_uart5;
>>> + serial8 = &main_uart6;
>
> Yeah, this looks weird. I understand that serial0 and serial1 are meant for MCU
> UARTs, but any reason why we don't want to add the k3-am64-mcu.dtsi and the MCU
> UARTs along with this patch?
>
> regards
> Suman
Sure, I will add them. Was originally trying to keep this as bare bones
as possible but I will just add them to give us all uarts.
>
>>> + };
>>> +
>>> + 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,armv8-pmuv3";
>>> + interrupts = <GIC_PPI 7 IRQ_TYPE_LEVEL_HIGH>;
>>> + };
>>> +
>>> + cbass_main: bus at f4000 {
>>> + compatible = "simple-bus";
>>> + #address-cells = <2>;
>>> + #size-cells = <2>;
>>> + ranges = <0x00 0x00600000 0x00 0x00600000 0x00 0x00001100>, /* GPIO */
>>> + <0x00 0x00a40000 0x00 0x00a40000 0x00 0x00000800>, /* Timesync router */
>>> + <0x00 0x01000000 0x00 0x01000000 0x00 0x02330400>, /* First peripheral window */
>>> + <0x00 0x08000000 0x00 0x08000000 0x00 0x00200000>, /* Main CPSW */
>>> + <0x00 0x0d000000 0x00 0x0d000000 0x00 0x00800000>, /* PCIE_CORE */
>>> + <0x00 0x0f000000 0x00 0x0f000000 0x00 0x00c44200>, /* Second peripheral window */
>>> + <0x00 0x20000000 0x00 0x20000000 0x00 0x0a008000>, /* Third peripheral window */
>>> + <0x00 0x30000000 0x00 0x30000000 0x00 0x000bc100>, /* ICSSG0/1 */
>>> + <0x00 0x37000000 0x00 0x37000000 0x00 0x00040000>, /* TIMERMGR0 TIMERS */
>>> + <0x00 0x39000000 0x00 0x39000000 0x00 0x00000400>, /* CPTS0 */
>>> + <0x00 0x3b000000 0x00 0x3b000000 0x00 0x00000400>, /* GPMC0_CFG */
>>> + <0x00 0x3cd00000 0x00 0x3cd00000 0x00 0x00000200>, /* TIMERMGR0_CONFIG */
>>> + <0x00 0x3f004000 0x00 0x3f004000 0x00 0x00000400>, /* GICSS0_REGS */
>>> + <0x00 0x43000000 0x00 0x43000000 0x00 0x00020000>, /* CTRL_MMR0 */
>>> + <0x00 0x48000000 0x00 0x48000000 0x00 0x06400000>, /* DMASS */
>>> + <0x00 0x50000000 0x00 0x50000000 0x00 0x08000000>, /* GPMC0 DATA */
>>> + <0x00 0x000f4000 0x00 0x000f4000 0x00 0x000002e4>, /* PINCTRL */
>>
>> Can you move this to the top, so that all these are in increasing memory order?
Yes done.
>>
>>> + <0x00 0x68000000 0x00 0x68000000 0x00 0x08000000>, /* PCIe DAT0 */
>>> + <0x06 0x00000000 0x06 0x00000000 0x01 0x00000000>, /* PCIe DAT1 */
>>> + <0x05 0x00000000 0x05 0x00000000 0x01 0x00000000>, /* FSS0 DAT3 */
>>
>> This is atleast missing the ranges for On-Chip SRAM and the R5FSS, but those can
>> always be added incrementally as well.
Yes, I think they should be added incrementally once a user is present.
>>
>> Also, is there a reason for using these ranges a bit more granular compared to
>> the earlier SoCs?
Any reason we shouldn't be? Memory map has different groupings of
peripherals.
Regards,
Dave
>>
>> regards
>> Suman
>>
>>> +
>>> + /* MCU Domain Range */
>>> + <0x00 0x04000000 0x00 0x04000000 0x00 0x01ff1400>;
>>> +
>>> + cbass_mcu: bus at 4000000 {
>>> + compatible = "simple-bus";
>>> + #address-cells = <2>;
>>> + #size-cells = <2>;
>>> + ranges = <0x00 0x04000000 0x00 0x04000000 0x00 0x01ff1400>; /* Peripheral window */
>>> + };
>>> + };
>>> +};
>>> +
>>> +/* Now include the peripherals for each bus segments */
>>> +#include "k3-am64-main.dtsi"
>>> diff --git a/arch/arm64/boot/dts/ti/k3-am642.dtsi b/arch/arm64/boot/dts/ti/k3-am642.dtsi
>>> new file mode 100644
>>> index 000000000000..b30f239e84f1
>>> --- /dev/null
>>> +++ b/arch/arm64/boot/dts/ti/k3-am642.dtsi
>>> @@ -0,0 +1,65 @@
>>> +// SPDX-License-Identifier: GPL-2.0
>>> +/*
>>> + * Device Tree Source for AM642 SoC family in Dual core configuration
>>> + *
>>> + * Copyright (C) 2020 Texas Instruments Incorporated - https://www.ti.com/
>>> + */
>>> +
>>> +/dts-v1/;
>>> +
>>> +#include "k3-am64.dtsi"
>>> +
>>> +/ {
>>> + cpus {
>>> + #address-cells = <1>;
>>> + #size-cells = <0>;
>>> +
>>> + cpu-map {
>>> + cluster0: cluster0 {
>>> + core0 {
>>> + cpu = <&cpu0>;
>>> + };
>>> +
>>> + core1 {
>>> + cpu = <&cpu1>;
>>> + };
>>> + };
>>> + };
>>> +
>>> + cpu0: cpu at 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 at 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>;
>>> + };
>>> + };
>>> +
>>> + L2_0: l2-cache0 {
>>> + compatible = "cache";
>>> + cache-level = <2>;
>>> + cache-size = <0x40000>;
>>> + cache-line-size = <64>;
>>> + cache-sets = <512>;
>>> + };
>>> +};
>>>
>>
>
More information about the linux-arm-kernel
mailing list