From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: MIME-Version: 1.0 In-Reply-To: <20140731095336.GB21850@leverpostej> References: <1406732794-20920-1-git-send-email-rric@kernel.org> <1406732794-20920-3-git-send-email-rric@kernel.org> <20140730154626.GD20162@leverpostej> <20140731095336.GB21850@leverpostej> Date: Thu, 31 Jul 2014 16:42:33 +0530 Message-ID: Subject: Re: [PATCH 2/5] arm64, thunder: Add initial dts for Cavium Thunder SoC From: Ganapatrao Kulkarni Content-Type: multipart/alternative; boundary=047d7b10d2216d766604ff7b59c7 To: Mark Rutland Cc: Robert Richter , "devicetree@vger.kernel.org" , Arnd Bergmann , Pawel Moll , Ian Campbell , Catalin Marinas , Will Deacon , "linux-kernel@vger.kernel.org" , Robert Richter , Rob Herring , Kumar Gala , Radha Mohan Chintakuntla , "linux-arm-kernel@lists.infradead.org" List-ID: --047d7b10d2216d766604ff7b59c7 Content-Type: text/plain; charset=UTF-8 On Thu, Jul 31, 2014 at 3:23 PM, Mark Rutland wrote: > On Thu, Jul 31, 2014 at 09:41:10AM +0100, Ganapatrao Kulkarni wrote: > > On Wed, Jul 30, 2014 at 9:16 PM, Mark Rutland <[1] > mark.rutland@arm.com> > > wrote: > > > > Hi, > > On Wed, Jul 30, 2014 at 04:06:31PM +0100, Robert Richter wrote: > > > From: Radha Mohan Chintakuntla <[2]rchintakuntla@cavium.com> > > > > > > Add initial device tree nodes for Cavium Thunder SoCs with > support of > > > 48 cores and gicv3. The dts file requires further changes, esp. > for > > > pci, gicv3-its and smmu. This changes will be added later together > > > with the device drivers. > > > > > > Signed-off-by: Radha Mohan Chintakuntla <[3] > rchintakuntla@cavium.com> > > > Signed-off-by: Robert Richter <[4]rrichter@cavium.com> > > > --- > > > arch/arm64/boot/dts/Makefile | 1 + > > > arch/arm64/boot/dts/thunder-88xx.dts | 387 > > +++++++++++++++++++++++++++++++++++ > > > 2 files changed, 388 insertions(+) > > > create mode 100644 arch/arm64/boot/dts/thunder-88xx.dts > > > > > > diff --git a/arch/arm64/boot/dts/Makefile > > b/arch/arm64/boot/dts/Makefile > > > index c52bdb051f66..f8001a62029c 100644 > > > --- a/arch/arm64/boot/dts/Makefile > > > +++ b/arch/arm64/boot/dts/Makefile > > > @@ -1,3 +1,4 @@ > > > +dtb-$(CONFIG_ARCH_THUNDER) += thunder-88xx.dtb > > > dtb-$(CONFIG_ARCH_VEXPRESS) += rtsm_ve-aemv8a.dtb > foundation-v8.dtb > > > dtb-$(CONFIG_ARCH_XGENE) += apm-mustang.dtb > > > > > > diff --git a/arch/arm64/boot/dts/thunder-88xx.dts > > b/arch/arm64/boot/dts/thunder-88xx.dts > > > new file mode 100644 > > > index 000000000000..4cf20ac9138b > > > --- /dev/null > > > +++ b/arch/arm64/boot/dts/thunder-88xx.dts > > > @@ -0,0 +1,387 @@ > > > +/* > > > + * Cavium Thunder DTS file > > > + * > > > + * Copyright (C) 2013, Cavium Inc. > > > + * > > > + * This program is free software; you can redistribute it and/or > > > + * modify it under the terms of the GNU General Public License as > > > + * published by the Free Software Foundation; either version 2 of > > > + * the License, or (at your option) any later version. > > > + */ > > > +/dts-v1/; > > > + > > > +/* Reserving first 12MB of DDR for firmware */ > > > +/memreserve/ 0x00000000 0x00c00000; > > > > What exactly is this memreserve intended to protect at runtime? > > Yes, this 12 MB is reserved for ATF and UEFI boot and run-time > services. > > If booted as an EFI application Linux will use the UEFI memory map. > Anything UEFI needs to have kept around will be marked as such, so > there's no need to memreserve that. > > We are loading ATF and UEFI from flash(which is not XIP) within 12MB of DDR. I dont see UEFI stub freeing RAM address where UEFI image is loaded. > I was under the impression that the ARM Trusted Firmware didn't need > anything resident on the non-secure side, so I don't see why that needs > a memreserve -- Linux should not be able to address anything it has > resident. > We mark RAM used by ATF as secure-RAM, however we don't support secure/non-secure address aliasing. i.e, a DRAM address that can be referenced from both a secure PA and a non-secure PA is not allowed. > > > The only item of runtime firmware I see in use below is PSCI on the > > secure side. > > > > How is the kernel booted on this platform? UEFI? > > > > Boot sequence tried is ATF->UEFI->Linux and ATF->UEFI->GRUB->Linux > > As I've just had it explained to me, in either of those cases we should > enter Linux via the EFI stub. So we should be using the UEFI memory map > regardless. > > Thanks, > Mark. > --047d7b10d2216d766604ff7b59c7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable



On Thu, Jul 31, 2014 at 3:23 PM, Mark Rutland <= ;mark.rutland@arm= .com> wrote:
On Thu, Jul 31, 2014 at 0= 9:41:10AM +0100, Ganapatrao Kulkarni wrote:
> =C2=A0 =C2=A0On Wed, Jul 30, 2014 at 9:16 PM, Mark Rutland <[1]mark.rutland@arm.com>
> =C2=A0 =C2=A0wrote:
>
> =C2=A0 =C2=A0 =C2=A0Hi,
> =C2=A0 =C2=A0 =C2=A0On Wed, Jul 30, 2014 at 04:06:31PM +0100, Robert R= ichter wrote:
> =C2=A0 =C2=A0 =C2=A0> From: Radha Mohan Chintakuntla <[2]<= a href=3D"mailto:rchintakuntla@cavium.com">rchintakuntla@cavium.com>=
> =C2=A0 =C2=A0 =C2=A0>
> =C2=A0 =C2=A0 =C2=A0> Add initial device tree nodes for Cavium Thun= der SoCs with support of
> =C2=A0 =C2=A0 =C2=A0> 48 cores and gicv3. The dts file requires fur= ther changes, esp. for
> =C2=A0 =C2=A0 =C2=A0> pci, gicv3-its and smmu. This changes will be= added later together
> =C2=A0 =C2=A0 =C2=A0> with the device drivers.
> =C2=A0 =C2=A0 =C2=A0>
> =C2=A0 =C2=A0 =C2=A0> Signed-off-by: Radha Mohan Chintakuntla= <[3]rchintakuntla@cavium.co= m>
> =C2=A0 =C2=A0 =C2=A0> Signed-off-by: Robert Richter <[4]rrichter@cavium.com>
> =C2=A0 =C2=A0 =C2=A0> ---
> =C2=A0 =C2=A0 =C2=A0> =C2=A0arch/arm64/boot/dts/Makefile =C2=A0 =C2= =A0 =C2=A0 =C2=A0 | =C2=A0 1 +
> =C2=A0 =C2=A0 =C2=A0> =C2=A0arch/arm64/boot/dts/thunder-88xx.dts | = 387
> =C2=A0 =C2=A0 =C2=A0+++++++++++++++++++++++++++++++++++
> =C2=A0 =C2=A0 =C2=A0> =C2=A02 files changed, 388 insertions(+)
> =C2=A0 =C2=A0 =C2=A0> =C2=A0create mode 100644 arch/arm64/boot/dts/= thunder-88xx.dts
> =C2=A0 =C2=A0 =C2=A0>
> =C2=A0 =C2=A0 =C2=A0> diff --git a/arch/arm64/boot/dts/Makefile
> =C2=A0 =C2=A0 =C2=A0b/arch/arm64/boot/dts/Makefile
> =C2=A0 =C2=A0 =C2=A0> index c52bdb051f66..f8001a62029c 100644
> =C2=A0 =C2=A0 =C2=A0> --- a/arch/arm64/boot/dts/Makefile
> =C2=A0 =C2=A0 =C2=A0> +++ b/arch/arm64/boot/dts/Makefile
> =C2=A0 =C2=A0 =C2=A0> @@ -1,3 +1,4 @@
> =C2=A0 =C2=A0 =C2=A0> +dtb-$(CONFIG_ARCH_THUNDER) +=3D thunder-88xx= .dtb
> =C2=A0 =C2=A0 =C2=A0> =C2=A0dtb-$(CONFIG_ARCH_VEXPRESS) +=3D rtsm_v= e-aemv8a.dtb foundation-v8.dtb
> =C2=A0 =C2=A0 =C2=A0> =C2=A0dtb-$(CONFIG_ARCH_XGENE) +=3D apm-musta= ng.dtb
> =C2=A0 =C2=A0 =C2=A0>
> =C2=A0 =C2=A0 =C2=A0> diff --git a/arch/arm64/boot/dts/thunder-88xx= .dts
> =C2=A0 =C2=A0 =C2=A0b/arch/arm64/boot/dts/thunder-88xx.dts
> =C2=A0 =C2=A0 =C2=A0> new file mode 100644
> =C2=A0 =C2=A0 =C2=A0> index 000000000000..4cf20ac9138b
> =C2=A0 =C2=A0 =C2=A0> --- /dev/null
> =C2=A0 =C2=A0 =C2=A0> +++ b/arch/arm64/boot/dts/thunder-88xx.dts > =C2=A0 =C2=A0 =C2=A0> @@ -0,0 +1,387 @@
> =C2=A0 =C2=A0 =C2=A0> +/*
> =C2=A0 =C2=A0 =C2=A0> + * Cavium Thunder DTS file
> =C2=A0 =C2=A0 =C2=A0> + *
> =C2=A0 =C2=A0 =C2=A0> + * Copyright (C) 2013, Cavium Inc.
> =C2=A0 =C2=A0 =C2=A0> + *
> =C2=A0 =C2=A0 =C2=A0> + * This program is free software; you can re= distribute it and/or
> =C2=A0 =C2=A0 =C2=A0> + * modify it under the terms of the GNU Gene= ral Public License as
> =C2=A0 =C2=A0 =C2=A0> + * published by the Free Software Foundation= ; either version 2 of
> =C2=A0 =C2=A0 =C2=A0> + * the License, or (at your option) any late= r version.
> =C2=A0 =C2=A0 =C2=A0> + */
> =C2=A0 =C2=A0 =C2=A0> +/dts-v1/;
> =C2=A0 =C2=A0 =C2=A0> +
> =C2=A0 =C2=A0 =C2=A0> +/* Reserving first 12MB of DDR for firmware = */
> =C2=A0 =C2=A0 =C2=A0> +/memreserve/ 0x00000000 0x00c00000;
>
> =C2=A0 =C2=A0 =C2=A0What exactly is this memreserve intended to protec= t at runtime?
> =C2=A0 =C2=A0 =C2=A0Yes, this 12 MB is reserved for ATF and UEFI boot = and run-time services.

If booted as an EFI application Linux will use the UEFI memory = map.
Anything UEFI needs to have kept around will be marked as such, so
there's no need to memreserve that.

We are loading ATF and UEFI from flash(which is not X= IP) within 12MB of DDR.
=C2=A0I dont see UEFI stub freeing RAM address w= here UEFI=C2=A0 image is loaded.

=C2=A0
<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft:1px solid rgb(204,204,204);padding-left:1ex"> I was under the impression that the ARM Trusted Firmware didn't need anything resident on the non-secure side, so I don't see why that needs=
a memreserve -- Linux should not be able to address anything it has
resident.
We mark RAM used by ATF as secure-RAM, howev= er we don't support secure/non-secure address aliasing.
i.e, a DRAM = address that can be referenced from both a secure PA and a non-secure PA is= not allowed.

=C2=A0

> =C2=A0 =C2=A0 =C2=A0The only item of runtime firmware I see in use bel= ow is PSCI on the
> =C2=A0 =C2=A0 =C2=A0secure side.
>
> =C2=A0 =C2=A0 =C2=A0How is the kernel booted on this platform? UEFI? >
> =C2=A0 =C2=A0Boot sequence tried is ATF->UEFI->Linux=C2=A0 and A= TF->UEFI->GRUB->Linux=C2=A0

As I've just had it explained to me, in either of those cases we = should
enter Linux via the EFI stub. So we should be using the UEFI memory map
regardless.

Thanks,
Mark.

--047d7b10d2216d766604ff7b59c7--