From: Robert Richter <rric@kernel.org>
To: Mark Rutland <mark.rutland@arm.com>
Cc: Ganapatrao Kulkarni <gpkulkarni@gmail.com>,
"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
Arnd Bergmann <arnd@arndb.de>, Pawel Moll <Pawel.Moll@arm.com>,
Ian Campbell <ijc+devicetree@hellion.org.uk>,
Catalin Marinas <Catalin.Marinas@arm.com>,
Will Deacon <Will.Deacon@arm.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
Robert Richter <rrichter@cavium.com>,
Rob Herring <robh+dt@kernel.org>,
Kumar Gala <galak@codeaurora.org>,
Radha Mohan Chintakuntla <rchintakuntla@cavium.com>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>,
leif.lindholm@linaro.org
Subject: Re: [PATCH 2/5] arm64, thunder: Add initial dts for Cavium Thunder SoC
Date: Fri, 1 Aug 2014 19:04:11 +0200 [thread overview]
Message-ID: <20140801170411.GG4703@rric.localhost> (raw)
In-Reply-To: <20140731113301.GE22994@leverpostej>
Mark,
On 31.07.14 12:33:01, Mark Rutland wrote:
> On Thu, Jul 31, 2014 at 12:12:33PM +0100, Ganapatrao Kulkarni wrote:
> > 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.
>
> What exactly do you mean by "not allowed"?
It actually means "not possible" since secure and non-secure memory is
kept in separate address ranges.
> If Linux maps that memory, what happens?
>
> What if Linux tried to read or write to it?
>
> If Linux should not map that memory, it should not be described in the
> memory map to begin with.
Linux never will see secure-RAM. Firmware must be sure to report the
correct non-secure memory ranges to the OS (e.g. unsecure mem size =
total size - secure mem size).
-Robert
WARNING: multiple messages have this Message-ID (diff)
From: Robert Richter <rric-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
To: Mark Rutland <mark.rutland-5wv7dgnIgG8@public.gmane.org>
Cc: Ganapatrao Kulkarni
<gpkulkarni-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
"devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
<devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
Arnd Bergmann <arnd-r2nGTMty4D4@public.gmane.org>,
Pawel Moll <Pawel.Moll-5wv7dgnIgG8@public.gmane.org>,
Ian Campbell
<ijc+devicetree-KcIKpvwj1kUDXYZnReoRVg@public.gmane.org>,
Catalin Marinas <Catalin.Marinas-5wv7dgnIgG8@public.gmane.org>,
Will Deacon <Will.Deacon-5wv7dgnIgG8@public.gmane.org>,
"linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
<linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
Robert Richter <rrichter-YGCgFSpz5w/QT0dZR+AlfA@public.gmane.org>,
Rob Herring <robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>,
Kumar Gala <galak-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>,
Radha Mohan Chintakuntla
<rchintakuntla-YGCgFSpz5w/QT0dZR+AlfA@public.gmane.org>,
"linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org"
<linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org>,
leif.lindholm-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org
Subject: Re: [PATCH 2/5] arm64, thunder: Add initial dts for Cavium Thunder SoC
Date: Fri, 1 Aug 2014 19:04:11 +0200 [thread overview]
Message-ID: <20140801170411.GG4703@rric.localhost> (raw)
In-Reply-To: <20140731113301.GE22994@leverpostej>
Mark,
On 31.07.14 12:33:01, Mark Rutland wrote:
> On Thu, Jul 31, 2014 at 12:12:33PM +0100, Ganapatrao Kulkarni wrote:
> > 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.
>
> What exactly do you mean by "not allowed"?
It actually means "not possible" since secure and non-secure memory is
kept in separate address ranges.
> If Linux maps that memory, what happens?
>
> What if Linux tried to read or write to it?
>
> If Linux should not map that memory, it should not be described in the
> memory map to begin with.
Linux never will see secure-RAM. Firmware must be sure to report the
correct non-secure memory ranges to the OS (e.g. unsecure mem size =
total size - secure mem size).
-Robert
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
WARNING: multiple messages have this Message-ID (diff)
From: rric@kernel.org (Robert Richter)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 2/5] arm64, thunder: Add initial dts for Cavium Thunder SoC
Date: Fri, 1 Aug 2014 19:04:11 +0200 [thread overview]
Message-ID: <20140801170411.GG4703@rric.localhost> (raw)
In-Reply-To: <20140731113301.GE22994@leverpostej>
Mark,
On 31.07.14 12:33:01, Mark Rutland wrote:
> On Thu, Jul 31, 2014 at 12:12:33PM +0100, Ganapatrao Kulkarni wrote:
> > 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.
>
> What exactly do you mean by "not allowed"?
It actually means "not possible" since secure and non-secure memory is
kept in separate address ranges.
> If Linux maps that memory, what happens?
>
> What if Linux tried to read or write to it?
>
> If Linux should not map that memory, it should not be described in the
> memory map to begin with.
Linux never will see secure-RAM. Firmware must be sure to report the
correct non-secure memory ranges to the OS (e.g. unsecure mem size =
total size - secure mem size).
-Robert
next prev parent reply other threads:[~2014-08-01 17:04 UTC|newest]
Thread overview: 97+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-07-30 15:06 [PATCH 0/5] arm64, thunder: Enable Cavium Thunder SoC Family Robert Richter
2014-07-30 15:06 ` Robert Richter
2014-07-30 15:06 ` [PATCH 1/5] arm64, thunder: Add Kconfig option for " Robert Richter
2014-07-30 15:06 ` Robert Richter
2014-07-30 15:06 ` [PATCH 2/5] arm64, thunder: Add initial dts for Cavium Thunder SoC Robert Richter
2014-07-30 15:06 ` Robert Richter
2014-07-30 15:06 ` Robert Richter
2014-07-30 15:46 ` Mark Rutland
2014-07-30 15:46 ` Mark Rutland
2014-07-30 15:46 ` Mark Rutland
2014-07-30 16:37 ` Rob Herring
2014-07-30 16:37 ` Rob Herring
2014-07-30 16:37 ` Rob Herring
2014-07-30 17:48 ` Mark Rutland
2014-07-30 17:48 ` Mark Rutland
2014-07-30 17:48 ` Mark Rutland
2014-08-05 8:47 ` Robert Richter
2014-08-05 8:47 ` Robert Richter
2014-08-05 8:47 ` Robert Richter
2014-07-31 11:32 ` Robert Richter
2014-07-31 11:32 ` Robert Richter
2014-07-31 11:32 ` Robert Richter
2014-07-31 12:34 ` Robert Richter
2014-07-31 12:34 ` Robert Richter
2014-07-31 12:34 ` Robert Richter
2014-07-31 15:22 ` Rob Herring
2014-07-31 15:22 ` Rob Herring
2014-07-31 15:22 ` Rob Herring
2014-07-31 16:35 ` Robert Richter
2014-07-31 16:35 ` Robert Richter
2014-07-31 16:35 ` Robert Richter
2014-07-31 8:41 ` Ganapatrao Kulkarni
2014-07-31 9:53 ` Mark Rutland
2014-07-31 9:53 ` Mark Rutland
2014-07-31 9:53 ` Mark Rutland
2014-07-31 11:12 ` Ganapatrao Kulkarni
2014-07-31 11:33 ` Mark Rutland
2014-07-31 11:33 ` Mark Rutland
2014-07-31 11:33 ` Mark Rutland
2014-08-01 17:04 ` Robert Richter [this message]
2014-08-01 17:04 ` Robert Richter
2014-08-01 17:04 ` Robert Richter
2014-08-01 18:00 ` Mark Rutland
2014-08-01 18:00 ` Mark Rutland
2014-08-01 18:00 ` Mark Rutland
2014-08-01 10:25 ` Robert Richter
2014-08-01 10:25 ` Robert Richter
2014-08-01 10:25 ` Robert Richter
2014-07-30 18:12 ` Olof Johansson
2014-07-30 18:12 ` Olof Johansson
2014-07-30 18:12 ` Olof Johansson
2014-07-30 18:35 ` Mark Rutland
2014-07-30 18:35 ` Mark Rutland
2014-07-30 18:35 ` Mark Rutland
2014-07-30 18:14 ` Olof Johansson
2014-07-30 18:14 ` Olof Johansson
2014-07-30 18:14 ` Olof Johansson
2014-08-01 16:18 ` Robert Richter
2014-08-01 16:18 ` Robert Richter
2014-08-01 16:18 ` Robert Richter
2014-08-28 16:15 ` Robert Richter
2014-08-28 16:15 ` Robert Richter
2014-08-28 16:15 ` Robert Richter
2014-08-28 16:25 ` Mark Rutland
2014-08-28 16:25 ` Mark Rutland
2014-08-28 16:25 ` Mark Rutland
2014-08-28 16:31 ` Olof Johansson
2014-08-28 16:31 ` Olof Johansson
2014-08-28 16:31 ` Olof Johansson
2014-08-28 18:14 ` Robert Richter
2014-08-28 18:14 ` Robert Richter
2014-08-28 18:14 ` Robert Richter
2014-08-28 23:01 ` Olof Johansson
2014-08-28 23:01 ` Olof Johansson
2014-08-28 23:01 ` Olof Johansson
2014-08-29 12:10 ` Robert Richter
2014-08-29 12:10 ` Robert Richter
2014-08-29 12:10 ` Robert Richter
2014-08-29 13:49 ` [PATCH] arm64, dts: Add dtbs_install make target Robert Richter
2014-08-29 13:49 ` Robert Richter
2014-08-29 13:49 ` Robert Richter
2014-09-05 6:55 ` Robert Richter
2014-09-05 6:55 ` Robert Richter
2014-09-05 6:55 ` Robert Richter
2014-07-31 10:24 ` [PATCH 2/5] arm64, thunder: Add initial dts for Cavium Thunder SoC Arnd Bergmann
2014-07-31 10:24 ` Arnd Bergmann
2014-07-31 10:24 ` Arnd Bergmann
2014-07-31 11:33 ` Robert Richter
2014-07-31 11:33 ` Robert Richter
2014-07-31 11:33 ` Robert Richter
2014-07-30 15:06 ` [PATCH 3/5] arm64, thunder: document devicetree bindings " Robert Richter
2014-07-30 15:06 ` Robert Richter
2014-07-30 15:06 ` Robert Richter
2014-07-30 15:06 ` [PATCH 4/5] arm64, defconfig: Enable Cavium Thunder SoC in defconfig Robert Richter
2014-07-30 15:06 ` Robert Richter
2014-07-30 15:06 ` [PATCH 5/5] arm64, defconfig: Enable tmpfs mount option Robert Richter
2014-07-30 15:06 ` Robert Richter
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20140801170411.GG4703@rric.localhost \
--to=rric@kernel.org \
--cc=Catalin.Marinas@arm.com \
--cc=Pawel.Moll@arm.com \
--cc=Will.Deacon@arm.com \
--cc=arnd@arndb.de \
--cc=devicetree@vger.kernel.org \
--cc=galak@codeaurora.org \
--cc=gpkulkarni@gmail.com \
--cc=ijc+devicetree@hellion.org.uk \
--cc=leif.lindholm@linaro.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mark.rutland@arm.com \
--cc=rchintakuntla@cavium.com \
--cc=robh+dt@kernel.org \
--cc=rrichter@cavium.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.