| Message ID | 1408096156-29772-5-git-send-email-bhupesh.sharma@freescale.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On Fri, Aug 15, 2014 at 10:49:13AM +0100, Bhupesh Sharma wrote: > + cpus { > + #address-cells = <2>; > + #size-cells = <0>; > + > + /* We have 4 clusters having 2 Cortex-A57 cores each */ > + cpu@0 { > + device_type = "cpu"; > + compatible = "arm,cortex-a57"; > + reg = <0x0 0x0>; > + enable-method = "spin-table"; > + cpu-release-addr = <0x0 0x8000fff8>; > + }; Why not PSCI?
Hi, On Fri, Aug 15, 2014 at 10:49:13AM +0100, Bhupesh Sharma wrote: > This patch adds the device tree support for FSL LS2085A SoC > based on ARMv8 architecture. > > Following levels of DTSI/DTS files have been created for the > LS2085A SoC family: > > - fsl-ls2085a.dtsi: > DTS-Include file for FSL LS2085A SoC. > > - fsl-ls2085a-simu.dts: > DTS file for FSL LS2085a software simulator model. > > Signed-off-by: Bhupesh Sharma <bhupesh.sharma@freescale.com> > Signed-off-by: Arnab Basu <arnab.basu@freescale.com> > Signed-off-by: Stuart Yoder <stuart.yoder@freescale.com> > --- > arch/arm64/boot/dts/fsl-ls2085a-simu.dts | 29 ++++++ > arch/arm64/boot/dts/fsl-ls2085a.dtsi | 145 ++++++++++++++++++++++++++++++ > 2 files changed, 174 insertions(+) > create mode 100644 arch/arm64/boot/dts/fsl-ls2085a-simu.dts > create mode 100644 arch/arm64/boot/dts/fsl-ls2085a.dtsi > > diff --git a/arch/arm64/boot/dts/fsl-ls2085a-simu.dts b/arch/arm64/boot/dts/fsl-ls2085a-simu.dts > new file mode 100644 > index 0000000..8a55710 > --- /dev/null > +++ b/arch/arm64/boot/dts/fsl-ls2085a-simu.dts > @@ -0,0 +1,29 @@ > +/* > + * Device Tree file for Freescale LS2085a software Simulator model > + * > + * Copyright (C) 2014, Freescale Semiconductor > + * > + * Bhupesh Sharma <bhupesh.sharma@freescale.com> > + * > + * This file is licensed under the terms of the GNU General Public > + * License version 2. This program is licensed "as is" without any > + * warranty of any kind, whether express or implied. > + */ > + > +/dts-v1/; > + > +/include/ "fsl-ls2085a.dtsi" > + > +/ { > + model = "Freescale Layerscape 2085a software Simulator model"; > + compatible = "fsl,ls2085a-simu", "fsl,ls2085a"; > + > + ethernet@2210000 { > + #address-cells = <2>; > + #size-cells = <2>; As far as I am aware, this cannot have children. So the #address-cells and #size-cells properties look redundant here. > + > + compatible = "smsc,lan91c111"; > + reg = <0x0 0x2210000 0x0 0x100>; > + interrupts = <0 58 0x1>; > + }; > +}; > diff --git a/arch/arm64/boot/dts/fsl-ls2085a.dtsi b/arch/arm64/boot/dts/fsl-ls2085a.dtsi > new file mode 100644 > index 0000000..aca48ac > --- /dev/null > +++ b/arch/arm64/boot/dts/fsl-ls2085a.dtsi > @@ -0,0 +1,145 @@ > +/* > + * Device Tree Include file for Freescale Layerscape-2085A family SoC. > + * > + * Copyright (C) 2014, Freescale Semiconductor > + * > + * Bhupesh Sharma <bhupesh.sharma@freescale.com> > + * > + * This file is licensed under the terms of the GNU General Public > + * License version 2. This program is licensed "as is" without any > + * warranty of any kind, whether express or implied. > + */ > + > +/* Preventing Linux from using the following memory chunk */ > +/memreserve/ 0x80000000 0x00010000; A more useful comment would describe what this is intended to protect. Ideally any bootloader would inject this as required. Inevitably this kind of thing varies over firmware/bootloader revisions. > + > +/ { > + compatible = "fsl,ls2085a"; > + interrupt-parent = <&gic>; > + #address-cells = <2>; > + #size-cells = <2>; > + > + cpus { > + #address-cells = <2>; > + #size-cells = <0>; > + > + /* We have 4 clusters having 2 Cortex-A57 cores each */ > + cpu@0 { > + device_type = "cpu"; > + compatible = "arm,cortex-a57"; > + reg = <0x0 0x0>; > + enable-method = "spin-table"; > + cpu-release-addr = <0x0 0x8000fff8>; > + }; I would strongly recommend having a unique cpu-release-addr for each CPU. [...] > + serial0: serial@21c4500 { > + device_type = "serial"; > + compatible = "fsl,ns16550", "ns16550a"; > + reg = <0x0 0x21c4500 0x0 0x100>; > + clock-frequency = <0>; Do we expect this to be filled in by the bootloader? [...] > > + fsl_mc: fsl-mc@80c000000 { > + compatible = "fsl,qoriq-mc"; > + reg = <0x00000008 0x0c000000 0 0x40 /* MC portal base */ > + 0x00000000 0x08340000 0 0x40000 >; /* MC control reg */ Nit: please bracket these individually as with other reg entries. Thanks, Mark.
On Fri, Aug 15 2014 at 10:49:13 am BST, Bhupesh Sharma <bhupesh.sharma@freescale.com> wrote: > This patch adds the device tree support for FSL LS2085A SoC > based on ARMv8 architecture. > > Following levels of DTSI/DTS files have been created for the > LS2085A SoC family: > > - fsl-ls2085a.dtsi: > DTS-Include file for FSL LS2085A SoC. > > - fsl-ls2085a-simu.dts: > DTS file for FSL LS2085a software simulator model. > > Signed-off-by: Bhupesh Sharma <bhupesh.sharma@freescale.com> > Signed-off-by: Arnab Basu <arnab.basu@freescale.com> > Signed-off-by: Stuart Yoder <stuart.yoder@freescale.com> > --- > arch/arm64/boot/dts/fsl-ls2085a-simu.dts | 29 ++++++ > arch/arm64/boot/dts/fsl-ls2085a.dtsi | 145 ++++++++++++++++++++++++++++++ > 2 files changed, 174 insertions(+) > create mode 100644 arch/arm64/boot/dts/fsl-ls2085a-simu.dts > create mode 100644 arch/arm64/boot/dts/fsl-ls2085a.dtsi [...] > diff --git a/arch/arm64/boot/dts/fsl-ls2085a.dtsi > b/arch/arm64/boot/dts/fsl-ls2085a.dtsi > new file mode 100644 > index 0000000..aca48ac > --- /dev/null > +++ b/arch/arm64/boot/dts/fsl-ls2085a.dtsi [...] > + > + gic: interrupt-controller@6000000 { > + compatible = "arm,gic-v3"; > + reg = <0x0 0x06000000 0 0x10000>, /* GIC Dist */ > + <0x0 0x06100000 0 0x100000>; /* GICR (RD_base + SGI_base) */ > + #interrupt-cells = <3>; > + #address-cells = <2>; > + #size-cells = <2>; > + ranges; > + interrupt-controller; > + interrupts = <1 9 0xf04>; The GICv3 binding doesn't encode anything in the top bits of the 3rd word. this should read 4 instead of 0xf04. > + > + its: gic-its@6020000 { > + compatible = "arm,gic-v3-its"; > + msi-controller; > + reg = <0x0 0x6020000 0 0x20000>; > + }; Adding the ITS at this point is probably a bit premature, as I haven't posted the patches yet, and it needs a public review. > + }; > + > + timer { > + compatible = "arm,armv8-timer"; > + interrupts = <1 13 0x01>, /* Physical Secure PPI, edge triggered */ > + <1 14 0x01>, /* Physical Non-Secure PPI, edge triggered */ > + <1 0 0x01>, /* Virtual PPI, edge triggered */ Are you sure about this interrupt number? Given that you have a bunch of Cortex-A57, I'd expect this to be 11 instead of 0. > + <1 10 0x01>; /* Hypervisor PPI, edge triggered */ > + }; > + > + serial0: serial@21c4500 { > + device_type = "serial"; > + compatible = "fsl,ns16550", "ns16550a"; > + reg = <0x0 0x21c4500 0x0 0x100>; > + clock-frequency = <0>; > + interrupts = <0 32 0x1>; /* edge triggered */ Nitpick: some level of consistency in the way you describe the trigger would be good (0x01 vs 0x1 vs 1...). > + }; > + > + serial1: serial@21c4600 { > + device_type = "serial"; > + compatible = "fsl,ns16550", "ns16550a"; > + reg = <0x0 0x21c4600 0x0 0x100>; > + clock-frequency = <0>; > + interrupts = <0 32 0x1>; /* edge triggered */ > + }; > + > + fsl_mc: fsl-mc@80c000000 { > + compatible = "fsl,qoriq-mc"; > + reg = <0x00000008 0x0c000000 0 0x40 /* MC portal base */ > + 0x00000000 0x08340000 0 0x40000 >; /* MC control reg */ > + }; > + > + memory@80000000 { > + device_type = "memory"; > + reg = <0x00000000 0x80000000 0 0x80000000>; > + /* DRAM space 1 - 2 GB DRAM */ > + }; > +};
> -----Original Message----- > From: Catalin Marinas [mailto:catalin.marinas@arm.com] > Sent: Friday, August 15, 2014 5:13 AM > To: Sharma Bhupesh-B45370 > Cc: devicetree-discuss@lists.ozlabs.org; Will Deacon; arnd@arndb.de; > grant.likely@secretlab.ca; linux-arm-kernel@lists.infradead.org; Yoder Stuart- > B08248; Basu Arnab-B45036 > Subject: Re: [PATCH 4/6] arm64: Add DTS support for FSL's LS2085A SoC > > On Fri, Aug 15, 2014 at 10:49:13AM +0100, Bhupesh Sharma wrote: > > + cpus { > > + #address-cells = <2>; > > + #size-cells = <0>; > > + > > + /* We have 4 clusters having 2 Cortex-A57 cores each */ > > + cpu@0 { > > + device_type = "cpu"; > > + compatible = "arm,cortex-a57"; > > + reg = <0x0 0x0>; > > + enable-method = "spin-table"; > > + cpu-release-addr = <0x0 0x8000fff8>; > > + }; > > Why not PSCI? It simply is where we are today-- we don't have functioning PSCI yet but plan to get there over time. All the existing device trees in arch/arm64 use "spin-table", so it seems that other platforms are in the same situation: apm-storm.dtsi foundation-v8.dts rtsm_ve-aemv8a.dts Thanks, Stuart
On Fri, Aug 15, 2014 at 01:53:13PM +0100, Stuart Yoder wrote: > > On Fri, Aug 15, 2014 at 10:49:13AM +0100, Bhupesh Sharma wrote: > > > + cpus { > > > + #address-cells = <2>; > > > + #size-cells = <0>; > > > + > > > + /* We have 4 clusters having 2 Cortex-A57 cores each */ > > > + cpu@0 { > > > + device_type = "cpu"; > > > + compatible = "arm,cortex-a57"; > > > + reg = <0x0 0x0>; > > > + enable-method = "spin-table"; > > > + cpu-release-addr = <0x0 0x8000fff8>; > > > + }; > > > > Why not PSCI? > > It simply is where we are today-- we don't have functioning PSCI yet > but plan to get there over time. Thanks for clarification. > All the existing device trees > in arch/arm64 use "spin-table", so it seems that other platforms are > in the same situation: > apm-storm.dtsi Not possible because there is no EL3 mode on the CPU implementation. > foundation-v8.dts > rtsm_ve-aemv8a.dts These work with the latest boot wrapper (which overrides the DT nodes and passes the PSCI information).
On Aug 15, 2014, at 4:49 AM, Bhupesh Sharma <bhupesh.sharma@freescale.com> wrote: > This patch adds the device tree support for FSL LS2085A SoC > based on ARMv8 architecture. > > Following levels of DTSI/DTS files have been created for the > LS2085A SoC family: > > - fsl-ls2085a.dtsi: > DTS-Include file for FSL LS2085A SoC. > > - fsl-ls2085a-simu.dts: > DTS file for FSL LS2085a software simulator model. > > Signed-off-by: Bhupesh Sharma <bhupesh.sharma@freescale.com> > Signed-off-by: Arnab Basu <arnab.basu@freescale.com> > Signed-off-by: Stuart Yoder <stuart.yoder@freescale.com> > --- > arch/arm64/boot/dts/fsl-ls2085a-simu.dts | 29 ++++++ Hmm, outside of something like qemu, we don’t normally have simulation model dts/support in the kernel. > arch/arm64/boot/dts/fsl-ls2085a.dtsi | 145 ++++++++++++++++++++++++++++++ > 2 files changed, 174 insertions(+) > create mode 100644 arch/arm64/boot/dts/fsl-ls2085a-simu.dts > create mode 100644 arch/arm64/boot/dts/fsl-ls2085a.dtsi - k
> -----Original Message----- > From: Kumar Gala [mailto:galak@codeaurora.org] > Sent: Friday, August 15, 2014 7:00 PM > To: Sharma Bhupesh-B45370 > Cc: devicetree-discuss@lists.ozlabs.org; Catalin.Marinas@arm.com; > arnd@arndb.de; Will.Deacon@arm.com; Yoder Stuart-B08248; > grant.likely@secretlab.ca; Basu Arnab-B45036; linux-arm- > kernel@lists.infradead.org > Subject: Re: [PATCH 4/6] arm64: Add DTS support for FSL's LS2085A SoC > > > On Aug 15, 2014, at 4:49 AM, Bhupesh Sharma <bhupesh.sharma@freescale.com> > wrote: > > > This patch adds the device tree support for FSL LS2085A SoC based on > > ARMv8 architecture. > > > > Following levels of DTSI/DTS files have been created for the LS2085A > > SoC family: > > > > - fsl-ls2085a.dtsi: > > DTS-Include file for FSL LS2085A SoC. > > > > - fsl-ls2085a-simu.dts: > > DTS file for FSL LS2085a software simulator model. > > > > Signed-off-by: Bhupesh Sharma <bhupesh.sharma@freescale.com> > > Signed-off-by: Arnab Basu <arnab.basu@freescale.com> > > Signed-off-by: Stuart Yoder <stuart.yoder@freescale.com> > > --- > > arch/arm64/boot/dts/fsl-ls2085a-simu.dts | 29 ++++++ > > Hmm, outside of something like qemu, we don't normally have simulation > model dts/support in the kernel. Well for ARMv8 - foundation model is an existing simulation model having DTS support. Regards, Bhupesh > > > arch/arm64/boot/dts/fsl-ls2085a.dtsi | 145 > ++++++++++++++++++++++++++++++ > > 2 files changed, 174 insertions(+) > > create mode 100644 arch/arm64/boot/dts/fsl-ls2085a-simu.dts > > create mode 100644 arch/arm64/boot/dts/fsl-ls2085a.dtsi > > - k > > -- > Employee of Qualcomm Innovation Center, Inc. > Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted > by The Linux Foundation
> -----Original Message----- > From: Catalin Marinas [mailto:catalin.marinas@arm.com] > Sent: Friday, August 15, 2014 6:40 PM > To: Yoder Stuart-B08248 > Cc: Sharma Bhupesh-B45370; devicetree-discuss@lists.ozlabs.org; Will > Deacon; arnd@arndb.de; grant.likely@secretlab.ca; linux-arm- > kernel@lists.infradead.org; Basu Arnab-B45036 > Subject: Re: [PATCH 4/6] arm64: Add DTS support for FSL's LS2085A SoC > > On Fri, Aug 15, 2014 at 01:53:13PM +0100, Stuart Yoder wrote: > > > On Fri, Aug 15, 2014 at 10:49:13AM +0100, Bhupesh Sharma wrote: > > > > + cpus { > > > > + #address-cells = <2>; > > > > + #size-cells = <0>; > > > > + > > > > + /* We have 4 clusters having 2 Cortex-A57 cores each */ > > > > + cpu@0 { > > > > + device_type = "cpu"; > > > > + compatible = "arm,cortex-a57"; > > > > + reg = <0x0 0x0>; > > > > + enable-method = "spin-table"; > > > > + cpu-release-addr = <0x0 0x8000fff8>; > > > > + }; > > > > > > Why not PSCI? > > > > It simply is where we are today-- we don't have functioning PSCI yet > > but plan to get there over time. > > Thanks for clarification. > > > All the existing device trees > > in arch/arm64 use "spin-table", so it seems that other platforms are > > in the same situation: > > apm-storm.dtsi > > Not possible because there is no EL3 mode on the CPU implementation. > > > foundation-v8.dts > > rtsm_ve-aemv8a.dts > > These work with the latest boot wrapper (which overrides the DT nodes and > passes the PSCI information). Right. We are working on our PSCI handler implementation in EL3 and the spin-table approach it something we are currently supporting on the simulator model using u-boot bootloader setting up the spin-tables. Our patches for implementing spin-table approach in armv8 u-boot are already under review and corresponding rework [1]. [1] http://lists.denx.de/pipermail/u-boot/2014-July/183692.html Regards, Bhupesh
On Aug 15, 2014, at 9:26 AM, bhupesh.sharma@freescale.com wrote: >> -----Original Message----- >> From: Kumar Gala [mailto:galak@codeaurora.org] >> Sent: Friday, August 15, 2014 7:00 PM >> To: Sharma Bhupesh-B45370 >> Cc: devicetree-discuss@lists.ozlabs.org; Catalin.Marinas@arm.com; >> arnd@arndb.de; Will.Deacon@arm.com; Yoder Stuart-B08248; >> grant.likely@secretlab.ca; Basu Arnab-B45036; linux-arm- >> kernel@lists.infradead.org >> Subject: Re: [PATCH 4/6] arm64: Add DTS support for FSL's LS2085A SoC >> >> >> On Aug 15, 2014, at 4:49 AM, Bhupesh Sharma <bhupesh.sharma@freescale.com> >> wrote: >> >>> This patch adds the device tree support for FSL LS2085A SoC based on >>> ARMv8 architecture. >>> >>> Following levels of DTSI/DTS files have been created for the LS2085A >>> SoC family: >>> >>> - fsl-ls2085a.dtsi: >>> DTS-Include file for FSL LS2085A SoC. >>> >>> - fsl-ls2085a-simu.dts: >>> DTS file for FSL LS2085a software simulator model. >>> >>> Signed-off-by: Bhupesh Sharma <bhupesh.sharma@freescale.com> >>> Signed-off-by: Arnab Basu <arnab.basu@freescale.com> >>> Signed-off-by: Stuart Yoder <stuart.yoder@freescale.com> >>> --- >>> arch/arm64/boot/dts/fsl-ls2085a-simu.dts | 29 ++++++ >> >> Hmm, outside of something like qemu, we don't normally have simulation >> model dts/support in the kernel. > > Well for ARMv8 - foundation model is an existing simulation model having DTS > support. > > Regards, > Bhupesh True but that model was generally available to the open source community and was to get the base armv8 support going. - k
Hi Mark > -----Original Message----- > From: Mark Rutland [mailto:mark.rutland@arm.com] > Sent: Friday, August 15, 2014 3:54 PM > To: Sharma Bhupesh-B45370 > Cc: devicetree-discuss@lists.ozlabs.org; Catalin Marinas; arnd@arndb.de; > Will Deacon; Yoder Stuart-B08248; grant.likely@secretlab.ca; Basu Arnab- > B45036; linux-arm-kernel@lists.infradead.org > Subject: Re: [PATCH 4/6] arm64: Add DTS support for FSL's LS2085A SoC > > Hi, > > On Fri, Aug 15, 2014 at 10:49:13AM +0100, Bhupesh Sharma wrote: > > This patch adds the device tree support for FSL LS2085A SoC based on > > ARMv8 architecture. > > > > Following levels of DTSI/DTS files have been created for the LS2085A > > SoC family: > > > > - fsl-ls2085a.dtsi: > > DTS-Include file for FSL LS2085A SoC. > > > > - fsl-ls2085a-simu.dts: > > DTS file for FSL LS2085a software simulator model. > > > > Signed-off-by: Bhupesh Sharma <bhupesh.sharma@freescale.com> > > Signed-off-by: Arnab Basu <arnab.basu@freescale.com> > > Signed-off-by: Stuart Yoder <stuart.yoder@freescale.com> > > --- > > arch/arm64/boot/dts/fsl-ls2085a-simu.dts | 29 ++++++ > > arch/arm64/boot/dts/fsl-ls2085a.dtsi | 145 > ++++++++++++++++++++++++++++++ > > 2 files changed, 174 insertions(+) > > create mode 100644 arch/arm64/boot/dts/fsl-ls2085a-simu.dts > > create mode 100644 arch/arm64/boot/dts/fsl-ls2085a.dtsi [...] > > diff --git a/arch/arm64/boot/dts/fsl-ls2085a.dtsi > > b/arch/arm64/boot/dts/fsl-ls2085a.dtsi > > new file mode 100644 > > index 0000000..aca48ac > > --- /dev/null > > +++ b/arch/arm64/boot/dts/fsl-ls2085a.dtsi > > @@ -0,0 +1,145 @@ > > +/* [...] > > + cpus { > > + #address-cells = <2>; > > + #size-cells = <0>; > > + > > + /* We have 4 clusters having 2 Cortex-A57 cores each */ > > + cpu@0 { > > + device_type = "cpu"; > > + compatible = "arm,cortex-a57"; > > + reg = <0x0 0x0>; > > + enable-method = "spin-table"; > > + cpu-release-addr = <0x0 0x8000fff8>; > > + }; > > I would strongly recommend having a unique cpu-release-addr for each CPU. > This is more of a place holder, we intend to patch this address from U-Boot and use individual release addresses for each CPU. Thanks Arnab > [...] > > > + serial0: serial@21c4500 { > > + device_type = "serial"; > > + compatible = "fsl,ns16550", "ns16550a"; > > + reg = <0x0 0x21c4500 0x0 0x100>; > > + clock-frequency = <0>; > > Do we expect this to be filled in by the bootloader? > > [...] > > > > + fsl_mc: fsl-mc@80c000000 { > > + compatible = "fsl,qoriq-mc"; > > + reg = <0x00000008 0x0c000000 0 0x40 /* MC portal base */ > > + 0x00000000 0x08340000 0 0x40000 >; /* MC control reg > */ > > Nit: please bracket these individually as with other reg entries. > > Thanks, > Mark.
On Aug 15, 2014, at 10:21 AM, arnab.basu@freescale.com wrote: >>> >>> + cpus { >>> + #address-cells = <2>; >>> + #size-cells = <0>; >>> + >>> + /* We have 4 clusters having 2 Cortex-A57 cores each */ >>> + cpu@0 { >>> + device_type = "cpu"; >>> + compatible = "arm,cortex-a57"; >>> + reg = <0x0 0x0>; >>> + enable-method = "spin-table"; >>> + cpu-release-addr = <0x0 0x8000fff8>; >>> + }; >> >> I would strongly recommend having a unique cpu-release-addr for each CPU. >> > > This is more of a place holder, we intend to patch this address from U-Boot > and use individual release addresses for each CPU. If you are going to patch it in u-boot, than why not just have u-boot add the property and drop it from here. If you intend to keep it here, than make <0x0 0x0> and add a comment that says u-boot will fill it out - k
On Fri, Aug 15, 2014 at 03:31:48PM +0100, bhupesh.sharma@freescale.com wrote: > > On Fri, Aug 15, 2014 at 01:53:13PM +0100, Stuart Yoder wrote: > > > > On Fri, Aug 15, 2014 at 10:49:13AM +0100, Bhupesh Sharma wrote: > > > > > + cpus { > > > > > + #address-cells = <2>; > > > > > + #size-cells = <0>; > > > > > + > > > > > + /* We have 4 clusters having 2 Cortex-A57 cores each */ > > > > > + cpu@0 { > > > > > + device_type = "cpu"; > > > > > + compatible = "arm,cortex-a57"; > > > > > + reg = <0x0 0x0>; > > > > > + enable-method = "spin-table"; > > > > > + cpu-release-addr = <0x0 0x8000fff8>; > > > > > + }; > > > > > > > > Why not PSCI? > > > > > > It simply is where we are today-- we don't have functioning PSCI yet > > > but plan to get there over time. > > > > Thanks for clarification. > > > > > All the existing device trees > > > in arch/arm64 use "spin-table", so it seems that other platforms are > > > in the same situation: > > > apm-storm.dtsi > > > > Not possible because there is no EL3 mode on the CPU implementation. > > > > > foundation-v8.dts > > > rtsm_ve-aemv8a.dts > > > > These work with the latest boot wrapper (which overrides the DT nodes and > > passes the PSCI information). > > Right. We are working on our PSCI handler implementation in EL3 and the spin-table > approach it something we are currently supporting on the simulator model using > u-boot bootloader setting up the spin-tables. > > Our patches for implementing spin-table approach in armv8 u-boot are already under > review and corresponding rework [1]. It would be better if you helped with this effort to bring PSCI to U-Boot (ARMv7 currently but easy to port to AArch64): https://git.kernel.org/cgit/linux/kernel/git/maz/u-boot.git/log/?h=wip/psci-v4 https://git.kernel.org/cgit/linux/kernel/git/maz/u-boot.git/log/?h=wip/psci-v4-a20
> > +/ { > > + compatible = "fsl,ls2085a"; > > + interrupt-parent = <&gic>; > > + #address-cells = <2>; > > + #size-cells = <2>; > > + > > + cpus { > > + #address-cells = <2>; > > + #size-cells = <0>; > > + > > + /* We have 4 clusters having 2 Cortex-A57 cores each */ > > + cpu@0 { > > + device_type = "cpu"; > > + compatible = "arm,cortex-a57"; > > + reg = <0x0 0x0>; > > + enable-method = "spin-table"; > > + cpu-release-addr = <0x0 0x8000fff8>; > > + }; > > I would strongly recommend having a unique cpu-release-addr for each > CPU. We could do that, but we were just following existing practice in existing arch/arm64 device trees. The 3 existing platforms upstream right now all have have the same cpu-release-addr value: apm-storm.dtsi foundation-v8.dts rtsm_ve-aemv8a.dts Stuart
> -----Original Message----- > From: Kumar Gala [mailto:galak@codeaurora.org] > Sent: Friday, August 15, 2014 10:26 AM > To: Basu Arnab-B45036 > Cc: Mark Rutland; Sharma Bhupesh-B45370; arnd@arndb.de; Catalin Marinas; > devicetree-discuss@lists.ozlabs.org; Will Deacon; Yoder Stuart-B08248; > grant.likely@secretlab.ca; linux-arm-kernel@lists.infradead.org > Subject: Re: [PATCH 4/6] arm64: Add DTS support for FSL's LS2085A SoC > > > On Aug 15, 2014, at 10:21 AM, arnab.basu@freescale.com wrote: > > >>> > >>> + cpus { > >>> + #address-cells = <2>; > >>> + #size-cells = <0>; > >>> + > >>> + /* We have 4 clusters having 2 Cortex-A57 cores each */ > >>> + cpu@0 { > >>> + device_type = "cpu"; > >>> + compatible = "arm,cortex-a57"; > >>> + reg = <0x0 0x0>; > >>> + enable-method = "spin-table"; > >>> + cpu-release-addr = <0x0 0x8000fff8>; > >>> + }; > >> > >> I would strongly recommend having a unique cpu-release-addr for each CPU. > >> > > > > This is more of a place holder, we intend to patch this address from U-Boot > > and use individual release addresses for each CPU. > > If you are going to patch it in u-boot, than why not just have u-boot add the > property and drop it from here. > > If you intend to keep it here, than make <0x0 0x0> and add a comment that says > u-boot will fill it out As I said to Mark re: the comment on having different release addresses per CPU, we are just following existing practice from the existing arch/arm64 device trees: apm-storm.dtsi foundation-v8.dts rtsm_ve-aemv8a.dts I think one of the reasons the cpu-release-addr is not 0x0 is that UEFI had(?)/has(?) limited ability to do device tree fix ups. It's not a problem at all in u-boot, but there is some reason all existing device trees have the same hardcoded address for all CPUs. So we want to do the standard/conventional thing here that will allow are device trees to be used in more than u-boot. Thanks, Stuart
On Aug 15, 2014, at 10:41 AM, Stuart Yoder <stuart.yoder@freescale.com> wrote: > > >> -----Original Message----- >> From: Kumar Gala [mailto:galak@codeaurora.org] >> Sent: Friday, August 15, 2014 10:26 AM >> To: Basu Arnab-B45036 >> Cc: Mark Rutland; Sharma Bhupesh-B45370; arnd@arndb.de; Catalin Marinas; >> devicetree-discuss@lists.ozlabs.org; Will Deacon; Yoder Stuart-B08248; >> grant.likely@secretlab.ca; linux-arm-kernel@lists.infradead.org >> Subject: Re: [PATCH 4/6] arm64: Add DTS support for FSL's LS2085A SoC >> >> >> On Aug 15, 2014, at 10:21 AM, arnab.basu@freescale.com wrote: >> >>>>> >>>>> + cpus { >>>>> + #address-cells = <2>; >>>>> + #size-cells = <0>; >>>>> + >>>>> + /* We have 4 clusters having 2 Cortex-A57 cores each */ >>>>> + cpu@0 { >>>>> + device_type = "cpu"; >>>>> + compatible = "arm,cortex-a57"; >>>>> + reg = <0x0 0x0>; >>>>> + enable-method = "spin-table"; >>>>> + cpu-release-addr = <0x0 0x8000fff8>; >>>>> + }; >>>> >>>> I would strongly recommend having a unique cpu-release-addr for each CPU. >>>> >>> >>> This is more of a place holder, we intend to patch this address from U-Boot >>> and use individual release addresses for each CPU. >> >> If you are going to patch it in u-boot, than why not just have u-boot add the >> property and drop it from here. >> >> If you intend to keep it here, than make <0x0 0x0> and add a comment that says >> u-boot will fill it out > > As I said to Mark re: the comment on having different release addresses > per CPU, we are just following existing practice from the existing > arch/arm64 device trees: > apm-storm.dtsi > foundation-v8.dts > rtsm_ve-aemv8a.dts > > I think one of the reasons the cpu-release-addr is not 0x0 is that > UEFI had(?)/has(?) limited ability to do device tree fix ups. It's > not a problem at all in u-boot, but there is some reason all > existing device trees have the same hardcoded address for all > CPUs. Are you guys planning on supporting UEFI on this platform? > So we want to do the standard/conventional thing here that will > allow are device trees to be used in more than u-boot. Well, I think the guys would say the standard thing is to move to PSCI. - k > > Thanks, > Stuart > > > -- > To unsubscribe from this list: send the line "unsubscribe devicetree" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html
> -----Original Message----- > From: Kumar Gala [mailto:galak@codeaurora.org] > Sent: Friday, August 15, 2014 10:44 AM > To: Yoder Stuart-B08248 > Cc: Basu Arnab-B45036; Mark Rutland; Sharma Bhupesh-B45370; arnd@arndb.de; > Catalin Marinas; Will Deacon; grant.likely@secretlab.ca; linux-arm- > kernel@lists.infradead.org; devicetree@vger.kernel.org > Subject: Re: [PATCH 4/6] arm64: Add DTS support for FSL's LS2085A SoC > > > On Aug 15, 2014, at 10:41 AM, Stuart Yoder <stuart.yoder@freescale.com> wrote: > > > > > > >> -----Original Message----- > >> From: Kumar Gala [mailto:galak@codeaurora.org] > >> Sent: Friday, August 15, 2014 10:26 AM > >> To: Basu Arnab-B45036 > >> Cc: Mark Rutland; Sharma Bhupesh-B45370; arnd@arndb.de; Catalin Marinas; > >> devicetree-discuss@lists.ozlabs.org; Will Deacon; Yoder Stuart-B08248; > >> grant.likely@secretlab.ca; linux-arm-kernel@lists.infradead.org > >> Subject: Re: [PATCH 4/6] arm64: Add DTS support for FSL's LS2085A SoC > >> > >> > >> On Aug 15, 2014, at 10:21 AM, arnab.basu@freescale.com wrote: > >> > >>>>> > >>>>> + cpus { > >>>>> + #address-cells = <2>; > >>>>> + #size-cells = <0>; > >>>>> + > >>>>> + /* We have 4 clusters having 2 Cortex-A57 cores each */ > >>>>> + cpu@0 { > >>>>> + device_type = "cpu"; > >>>>> + compatible = "arm,cortex-a57"; > >>>>> + reg = <0x0 0x0>; > >>>>> + enable-method = "spin-table"; > >>>>> + cpu-release-addr = <0x0 0x8000fff8>; > >>>>> + }; > >>>> > >>>> I would strongly recommend having a unique cpu-release-addr for each CPU. > >>>> > >>> > >>> This is more of a place holder, we intend to patch this address from U-Boot > >>> and use individual release addresses for each CPU. > >> > >> If you are going to patch it in u-boot, than why not just have u-boot add > the > >> property and drop it from here. > >> > >> If you intend to keep it here, than make <0x0 0x0> and add a comment that > says > >> u-boot will fill it out > > > > As I said to Mark re: the comment on having different release addresses > > per CPU, we are just following existing practice from the existing > > arch/arm64 device trees: > > apm-storm.dtsi > > foundation-v8.dts > > rtsm_ve-aemv8a.dts > > > > I think one of the reasons the cpu-release-addr is not 0x0 is that > > UEFI had(?)/has(?) limited ability to do device tree fix ups. It's > > not a problem at all in u-boot, but there is some reason all > > existing device trees have the same hardcoded address for all > > CPUs. > > Are you guys planning on supporting UEFI on this platform? Yes. > > So we want to do the standard/conventional thing here that will > > allow are device trees to be used in more than u-boot. > > Well, I think the guys would say the standard thing is to move to PSCI. Agree. That is our plan. But it looks like at this point in time all the device tree have a common denominator spin table mechanim that gets updated/overriden if PSCI is supported. Stuart
> -----Original Message----- > From: Catalin Marinas [mailto:catalin.marinas@arm.com] > Sent: Friday, August 15, 2014 10:29 AM > To: Sharma Bhupesh-B45370 > Cc: Yoder Stuart-B08248; devicetree-discuss@lists.ozlabs.org; Will Deacon; > arnd@arndb.de; grant.likely@secretlab.ca; linux-arm-kernel@lists.infradead.org; > Basu Arnab-B45036 > Subject: Re: [PATCH 4/6] arm64: Add DTS support for FSL's LS2085A SoC > > On Fri, Aug 15, 2014 at 03:31:48PM +0100, bhupesh.sharma@freescale.com wrote: > > > On Fri, Aug 15, 2014 at 01:53:13PM +0100, Stuart Yoder wrote: > > > > > On Fri, Aug 15, 2014 at 10:49:13AM +0100, Bhupesh Sharma wrote: > > > > > > + cpus { > > > > > > + #address-cells = <2>; > > > > > > + #size-cells = <0>; > > > > > > + > > > > > > + /* We have 4 clusters having 2 Cortex-A57 cores each */ > > > > > > + cpu@0 { > > > > > > + device_type = "cpu"; > > > > > > + compatible = "arm,cortex-a57"; > > > > > > + reg = <0x0 0x0>; > > > > > > + enable-method = "spin-table"; > > > > > > + cpu-release-addr = <0x0 0x8000fff8>; > > > > > > + }; > > > > > > > > > > Why not PSCI? > > > > > > > > It simply is where we are today-- we don't have functioning PSCI yet > > > > but plan to get there over time. > > > > > > Thanks for clarification. > > > > > > > All the existing device trees > > > > in arch/arm64 use "spin-table", so it seems that other platforms are > > > > in the same situation: > > > > apm-storm.dtsi > > > > > > Not possible because there is no EL3 mode on the CPU implementation. > > > > > > > foundation-v8.dts > > > > rtsm_ve-aemv8a.dts > > > > > > These work with the latest boot wrapper (which overrides the DT nodes and > > > passes the PSCI information). > > > > Right. We are working on our PSCI handler implementation in EL3 and the spin- > table > > approach it something we are currently supporting on the simulator model > using > > u-boot bootloader setting up the spin-tables. > > > > Our patches for implementing spin-table approach in armv8 u-boot are already > under > > review and corresponding rework [1]. > > It would be better if you helped with this effort to bring PSCI to > U-Boot (ARMv7 currently but easy to port to AArch64): > > https://git.kernel.org/cgit/linux/kernel/git/maz/u-boot.git/log/?h=wip/psci-v4 > https://git.kernel.org/cgit/linux/kernel/git/maz/u-boot.git/log/?h=wip/psci-v4- > a20 Is the intent to eventually purge the device trees of enable-method/cpu-release-addr and have that set by the boot firmware? Or, keep the spin-table method around as a least common denominator mechanism and override it when necessary? Wondering what the longer term thinking is... Thanks, Stuart
On Fri, Aug 15, 2014 at 04:49:53PM +0100, Stuart Yoder wrote: > > On Aug 15, 2014, at 10:41 AM, Stuart Yoder <stuart.yoder@freescale.com> wrote: > > > So we want to do the standard/conventional thing here that will > > > allow are device trees to be used in more than u-boot. > > > > Well, I think the guys would say the standard thing is to move to PSCI. > > Agree. That is our plan. But it looks like at this point in > time all the device tree have a common denominator spin table > mechanim that gets updated/overriden if PSCI is supported. That's for historical reasons because at the time there was no PSCI and now we have to preserve backwards compatibility with older boot wrappers. The only hardware currently having a DT in the arm64 tree is the APM one which cannot implement PSCI because there is no EL3. (and I think we should really get a proper arm64 PSCI implementation in U-Boot)
Hi Stuart, On Fri, Aug 15, 2014 at 04:37:06PM +0100, Stuart Yoder wrote: > > > +/ { > > > + compatible = "fsl,ls2085a"; > > > + interrupt-parent = <&gic>; > > > + #address-cells = <2>; > > > + #size-cells = <2>; > > > + > > > + cpus { > > > + #address-cells = <2>; > > > + #size-cells = <0>; > > > + > > > + /* We have 4 clusters having 2 Cortex-A57 cores each */ > > > + cpu@0 { > > > + device_type = "cpu"; > > > + compatible = "arm,cortex-a57"; > > > + reg = <0x0 0x0>; > > > + enable-method = "spin-table"; > > > + cpu-release-addr = <0x0 0x8000fff8>; > > > + }; > > > > I would strongly recommend having a unique cpu-release-addr for each > > CPU. > > We could do that, but we were just following existing practice in > existing arch/arm64 device trees. The 3 existing platforms upstream > right now all have have the same cpu-release-addr value: > apm-storm.dtsi > foundation-v8.dts > rtsm_ve-aemv8a.dts In general, following existing examples is a good idea. I'm not faulting you for that. Unfortunately there are plenty of bad examples in DTS in the kernel. W.R.T. unique addresses for spin-table this is something we learnt after those dts files were upstreamed. It's not possible to change those dts files in the kernel without breaking older firmwares/bootwrappers which don't patch the DTB. Cheers, Mark.
> -----Original Message----- > From: Kumar Gala [mailto:galak@codeaurora.org] > Sent: Friday, August 15, 2014 9:41 AM > To: Sharma Bhupesh-B45370 > Cc: arnd@arndb.de; Catalin.Marinas@arm.com; devicetree- > discuss@lists.ozlabs.org; Will.Deacon@arm.com; Yoder Stuart-B08248; > grant.likely@secretlab.ca; Basu Arnab-B45036; linux-arm- > kernel@lists.infradead.org > Subject: Re: [PATCH 4/6] arm64: Add DTS support for FSL's LS2085A SoC > > > On Aug 15, 2014, at 9:26 AM, bhupesh.sharma@freescale.com wrote: > > >> -----Original Message----- > >> From: Kumar Gala [mailto:galak@codeaurora.org] > >> Sent: Friday, August 15, 2014 7:00 PM > >> To: Sharma Bhupesh-B45370 > >> Cc: devicetree-discuss@lists.ozlabs.org; Catalin.Marinas@arm.com; > >> arnd@arndb.de; Will.Deacon@arm.com; Yoder Stuart-B08248; > >> grant.likely@secretlab.ca; Basu Arnab-B45036; linux-arm- > >> kernel@lists.infradead.org > >> Subject: Re: [PATCH 4/6] arm64: Add DTS support for FSL's LS2085A SoC > >> > >> > >> On Aug 15, 2014, at 4:49 AM, Bhupesh Sharma <bhupesh.sharma@freescale.com> > >> wrote: > >> > >>> This patch adds the device tree support for FSL LS2085A SoC based on > >>> ARMv8 architecture. > >>> > >>> Following levels of DTSI/DTS files have been created for the LS2085A > >>> SoC family: > >>> > >>> - fsl-ls2085a.dtsi: > >>> DTS-Include file for FSL LS2085A SoC. > >>> > >>> - fsl-ls2085a-simu.dts: > >>> DTS file for FSL LS2085a software simulator model. > >>> > >>> Signed-off-by: Bhupesh Sharma <bhupesh.sharma@freescale.com> > >>> Signed-off-by: Arnab Basu <arnab.basu@freescale.com> > >>> Signed-off-by: Stuart Yoder <stuart.yoder@freescale.com> > >>> --- > >>> arch/arm64/boot/dts/fsl-ls2085a-simu.dts | 29 ++++++ > >> > >> Hmm, outside of something like qemu, we don't normally have simulation > >> model dts/support in the kernel. > > > > Well for ARMv8 - foundation model is an existing simulation model having DTS > > support. > > > > Regards, > > Bhupesh > > True but that model was generally available to the open source community and > was to get the base armv8 support going. Note, the LS2085A SoC definition itself is in fsl-ls2085a.dtsi. The fsl-ls2085a-simu is simply a simulation machine that uses that, and will generally reflect board-level differences from a physical machine in things like Ethernet PHYs and so on. The simulator is available now to Freescale customers and I expect significant use by them over the next few years. If there is a hard rule that 'simulator-based machines are not allowed' in the kernel, thats fine, but I don't understand why that should be the case. Thanks, Stuart
Hi Stuart > Is the intent to eventually purge the device trees of enable-method/cpu-release-addr > and have that set by the boot firmware? Or, keep the spin-table method > around as a least common denominator mechanism and override it when > necessary? Wondering what the longer term thinking is... Personally I'd like to see anything that's not a fixed HW property be omitted in the DTS and injected by the boot firmware. Certainly anything which is a property of the FW should be injected by that FW. That would cover: - Any enable-method property and related properties and/or nodes. This is heavily dependent on the boot firmware configuration, and can differ substantially between instances of a given board. - Most /memreserve/ uses (as these typically protect firmware or trampoline code). - Any memory nodes where memory can be dynamically populated on the board. - CPU nodes if the presence of said CPUs is dynamically determined. In the long term I'd like to see DTS get fully decoupled from the kernel. Cheers, Mark.
On Fri, Aug 15, 2014 at 04:57:13PM +0100, Stuart Yoder wrote: > > On Fri, Aug 15, 2014 at 03:31:48PM +0100, bhupesh.sharma@freescale.com wrote: > > > > On Fri, Aug 15, 2014 at 01:53:13PM +0100, Stuart Yoder wrote: > > > > > > On Fri, Aug 15, 2014 at 10:49:13AM +0100, Bhupesh Sharma wrote: > > > > > > > + cpus { > > > > > > > + #address-cells = <2>; > > > > > > > + #size-cells = <0>; > > > > > > > + > > > > > > > + /* We have 4 clusters having 2 Cortex-A57 cores each */ > > > > > > > + cpu@0 { > > > > > > > + device_type = "cpu"; > > > > > > > + compatible = "arm,cortex-a57"; > > > > > > > + reg = <0x0 0x0>; > > > > > > > + enable-method = "spin-table"; > > > > > > > + cpu-release-addr = <0x0 0x8000fff8>; > > > > > > > + }; > > > > > > > > > > > > Why not PSCI? > > > > > > > > > > It simply is where we are today-- we don't have functioning PSCI yet > > > > > but plan to get there over time. > > > > > > > > Thanks for clarification. > > > > > > > > > All the existing device trees > > > > > in arch/arm64 use "spin-table", so it seems that other platforms are > > > > > in the same situation: > > > > > apm-storm.dtsi > > > > > > > > Not possible because there is no EL3 mode on the CPU implementation. > > > > > > > > > foundation-v8.dts > > > > > rtsm_ve-aemv8a.dts > > > > > > > > These work with the latest boot wrapper (which overrides the DT nodes and > > > > passes the PSCI information). > > > > > > Right. We are working on our PSCI handler implementation in EL3 and the spin- > > table > > > approach it something we are currently supporting on the simulator model > > using > > > u-boot bootloader setting up the spin-tables. > > > > > > Our patches for implementing spin-table approach in armv8 u-boot are already > > under > > > review and corresponding rework [1]. > > > > It would be better if you helped with this effort to bring PSCI to > > U-Boot (ARMv7 currently but easy to port to AArch64): > > > > https://git.kernel.org/cgit/linux/kernel/git/maz/u-boot.git/log/?h=wip/psci-v4 > > https://git.kernel.org/cgit/linux/kernel/git/maz/u-boot.git/log/?h=wip/psci-v4- > > a20 > > Is the intent to eventually purge the device trees of enable-method/cpu-release-addr > and have that set by the boot firmware? Or, keep the spin-table method > around as a least common denominator mechanism and override it when > necessary? Wondering what the longer term thinking is... There are only two dts files that would support PSCI but because of older boot wrappers, we can't change the default. However, the aim for new platforms is to start with PSCI by default rather than spin-table and looking at changing them later.
> -----Original Message----- > From: Catalin Marinas [mailto:catalin.marinas@arm.com] > Sent: Friday, August 15, 2014 11:25 AM > To: Yoder Stuart-B08248 > Cc: Sharma Bhupesh-B45370; devicetree-discuss@lists.ozlabs.org; Will Deacon; > arnd@arndb.de; grant.likely@secretlab.ca; linux-arm-kernel@lists.infradead.org; > Basu Arnab-B45036 > Subject: Re: [PATCH 4/6] arm64: Add DTS support for FSL's LS2085A SoC > > On Fri, Aug 15, 2014 at 04:57:13PM +0100, Stuart Yoder wrote: > > > On Fri, Aug 15, 2014 at 03:31:48PM +0100, bhupesh.sharma@freescale.com > wrote: > > > > > On Fri, Aug 15, 2014 at 01:53:13PM +0100, Stuart Yoder wrote: > > > > > > > On Fri, Aug 15, 2014 at 10:49:13AM +0100, Bhupesh Sharma wrote: > > > > > > > > + cpus { > > > > > > > > + #address-cells = <2>; > > > > > > > > + #size-cells = <0>; > > > > > > > > + > > > > > > > > + /* We have 4 clusters having 2 Cortex-A57 cores each */ > > > > > > > > + cpu@0 { > > > > > > > > + device_type = "cpu"; > > > > > > > > + compatible = "arm,cortex-a57"; > > > > > > > > + reg = <0x0 0x0>; > > > > > > > > + enable-method = "spin-table"; > > > > > > > > + cpu-release-addr = <0x0 0x8000fff8>; > > > > > > > > + }; > > > > > > > > > > > > > > Why not PSCI? > > > > > > > > > > > > It simply is where we are today-- we don't have functioning PSCI yet > > > > > > but plan to get there over time. > > > > > > > > > > Thanks for clarification. > > > > > > > > > > > All the existing device trees > > > > > > in arch/arm64 use "spin-table", so it seems that other platforms are > > > > > > in the same situation: > > > > > > apm-storm.dtsi > > > > > > > > > > Not possible because there is no EL3 mode on the CPU implementation. > > > > > > > > > > > foundation-v8.dts > > > > > > rtsm_ve-aemv8a.dts > > > > > > > > > > These work with the latest boot wrapper (which overrides the DT nodes > and > > > > > passes the PSCI information). > > > > > > > > Right. We are working on our PSCI handler implementation in EL3 and the > spin- > > > table > > > > approach it something we are currently supporting on the simulator model > > > using > > > > u-boot bootloader setting up the spin-tables. > > > > > > > > Our patches for implementing spin-table approach in armv8 u-boot are > already > > > under > > > > review and corresponding rework [1]. > > > > > > It would be better if you helped with this effort to bring PSCI to > > > U-Boot (ARMv7 currently but easy to port to AArch64): > > > > > > https://git.kernel.org/cgit/linux/kernel/git/maz/u- > boot.git/log/?h=wip/psci-v4 > > > https://git.kernel.org/cgit/linux/kernel/git/maz/u- > boot.git/log/?h=wip/psci-v4- > > > a20 > > > > Is the intent to eventually purge the device trees of enable-method/cpu- > release-addr > > and have that set by the boot firmware? Or, keep the spin-table method > > around as a least common denominator mechanism and override it when > > necessary? Wondering what the longer term thinking is... > > There are only two dts files that would support PSCI but because of > older boot wrappers, we can't change the default. However, the aim for > new platforms is to start with PSCI by default rather than spin-table > and looking at changing them later. Ok. There's no issue removing those properties and then having u-boot do fixups of the release-method...which is "spin-table" for now, and PSCI eventually. I'm not yet familiar with what UEFI limitations exist regarding fixups, but assume they can be solved in a bootwrapper if necessary. Thanks, Stuart
diff --git a/arch/arm64/boot/dts/fsl-ls2085a-simu.dts b/arch/arm64/boot/dts/fsl-ls2085a-simu.dts new file mode 100644 index 0000000..8a55710 --- /dev/null +++ b/arch/arm64/boot/dts/fsl-ls2085a-simu.dts @@ -0,0 +1,29 @@ +/* + * Device Tree file for Freescale LS2085a software Simulator model + * + * Copyright (C) 2014, Freescale Semiconductor + * + * Bhupesh Sharma <bhupesh.sharma@freescale.com> + * + * This file is licensed under the terms of the GNU General Public + * License version 2. This program is licensed "as is" without any + * warranty of any kind, whether express or implied. + */ + +/dts-v1/; + +/include/ "fsl-ls2085a.dtsi" + +/ { + model = "Freescale Layerscape 2085a software Simulator model"; + compatible = "fsl,ls2085a-simu", "fsl,ls2085a"; + + ethernet@2210000 { + #address-cells = <2>; + #size-cells = <2>; + + compatible = "smsc,lan91c111"; + reg = <0x0 0x2210000 0x0 0x100>; + interrupts = <0 58 0x1>; + }; +}; diff --git a/arch/arm64/boot/dts/fsl-ls2085a.dtsi b/arch/arm64/boot/dts/fsl-ls2085a.dtsi new file mode 100644 index 0000000..aca48ac --- /dev/null +++ b/arch/arm64/boot/dts/fsl-ls2085a.dtsi @@ -0,0 +1,145 @@ +/* + * Device Tree Include file for Freescale Layerscape-2085A family SoC. + * + * Copyright (C) 2014, Freescale Semiconductor + * + * Bhupesh Sharma <bhupesh.sharma@freescale.com> + * + * This file is licensed under the terms of the GNU General Public + * License version 2. This program is licensed "as is" without any + * warranty of any kind, whether express or implied. + */ + +/* Preventing Linux from using the following memory chunk */ +/memreserve/ 0x80000000 0x00010000; + +/ { + compatible = "fsl,ls2085a"; + interrupt-parent = <&gic>; + #address-cells = <2>; + #size-cells = <2>; + + cpus { + #address-cells = <2>; + #size-cells = <0>; + + /* We have 4 clusters having 2 Cortex-A57 cores each */ + cpu@0 { + device_type = "cpu"; + compatible = "arm,cortex-a57"; + reg = <0x0 0x0>; + enable-method = "spin-table"; + cpu-release-addr = <0x0 0x8000fff8>; + }; + + cpu@1 { + device_type = "cpu"; + compatible = "arm,cortex-a57"; + reg = <0x0 0x1>; + enable-method = "spin-table"; + cpu-release-addr = <0x0 0x8000fff8>; + }; + + cpu@100 { + device_type = "cpu"; + compatible = "arm,cortex-a57"; + reg = <0x0 0x100>; + enable-method = "spin-table"; + cpu-release-addr = <0x0 0x8000fff8>; + }; + + cpu@101 { + device_type = "cpu"; + compatible = "arm,cortex-a57"; + reg = <0x0 0x101>; + enable-method = "spin-table"; + cpu-release-addr = <0x0 0x8000fff8>; + }; + + cpu@200 { + device_type = "cpu"; + compatible = "arm,cortex-a57"; + reg = <0x0 0x200>; + enable-method = "spin-table"; + cpu-release-addr = <0x0 0x8000fff8>; + }; + + cpu@201 { + device_type = "cpu"; + compatible = "arm,cortex-a57"; + reg = <0x0 0x201>; + enable-method = "spin-table"; + cpu-release-addr = <0x0 0x8000fff8>; + }; + + cpu@300 { + device_type = "cpu"; + compatible = "arm,cortex-a57"; + reg = <0x0 0x300>; + enable-method = "spin-table"; + cpu-release-addr = <0x0 0x8000fff8>; + }; + + cpu@301 { + device_type = "cpu"; + compatible = "arm,cortex-a57"; + reg = <0x0 0x301>; + enable-method = "spin-table"; + cpu-release-addr = <0x0 0x8000fff8>; + }; + }; + + gic: interrupt-controller@6000000 { + compatible = "arm,gic-v3"; + reg = <0x0 0x06000000 0 0x10000>, /* GIC Dist */ + <0x0 0x06100000 0 0x100000>; /* GICR (RD_base + SGI_base) */ + #interrupt-cells = <3>; + #address-cells = <2>; + #size-cells = <2>; + ranges; + interrupt-controller; + interrupts = <1 9 0xf04>; + + its: gic-its@6020000 { + compatible = "arm,gic-v3-its"; + msi-controller; + reg = <0x0 0x6020000 0 0x20000>; + }; + }; + + timer { + compatible = "arm,armv8-timer"; + interrupts = <1 13 0x01>, /* Physical Secure PPI, edge triggered */ + <1 14 0x01>, /* Physical Non-Secure PPI, edge triggered */ + <1 0 0x01>, /* Virtual PPI, edge triggered */ + <1 10 0x01>; /* Hypervisor PPI, edge triggered */ + }; + + serial0: serial@21c4500 { + device_type = "serial"; + compatible = "fsl,ns16550", "ns16550a"; + reg = <0x0 0x21c4500 0x0 0x100>; + clock-frequency = <0>; + interrupts = <0 32 0x1>; /* edge triggered */ + }; + + serial1: serial@21c4600 { + device_type = "serial"; + compatible = "fsl,ns16550", "ns16550a"; + reg = <0x0 0x21c4600 0x0 0x100>; + clock-frequency = <0>; + interrupts = <0 32 0x1>; /* edge triggered */ + }; + + fsl_mc: fsl-mc@80c000000 { + compatible = "fsl,qoriq-mc"; + reg = <0x00000008 0x0c000000 0 0x40 /* MC portal base */ + 0x00000000 0x08340000 0 0x40000 >; /* MC control reg */ + }; + + memory@80000000 { + device_type = "memory"; + reg = <0x00000000 0x80000000 0 0x80000000>; + /* DRAM space 1 - 2 GB DRAM */ + }; +};