From: mark.rutland@arm.com (Mark Rutland)
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:00:35 +0100 [thread overview]
Message-ID: <20140801180035.GF3264@leverpostej> (raw)
In-Reply-To: <20140801170411.GG4703@rric.localhost>
On Fri, Aug 01, 2014 at 06:04:11PM +0100, Robert Richter wrote:
> Mark,
Hi Robert,
> 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.
I understand that the two are separate physical address spaces, but
Ganapatrao's reply was somewhat ambiguous and it wasn't clear to me that
the memory was actually marked as secure.
> > 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).
Ok, that's what I had hoped for and that makes sense.
The issue was that the memory node contained an address range that was
supposedly secure-only (which Linux could attempt to map), which was
'protected' with a /memreserve/ (which does not stop it from being
mapped).
Given they are unnecessary (unless you want to bypass EFI for some
reason) they can be dropped.
Thanks,
Mark.
next prev parent reply other threads:[~2014-08-01 18:00 UTC|newest]
Thread overview: 33+ 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 ` [PATCH 1/5] arm64, thunder: Add Kconfig option for " 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:46 ` Mark Rutland
2014-07-30 16:37 ` Rob Herring
2014-07-30 17:48 ` Mark Rutland
2014-08-05 8:47 ` Robert Richter
2014-07-31 11:32 ` Robert Richter
2014-07-31 12:34 ` Robert Richter
2014-07-31 15:22 ` Rob Herring
2014-07-31 16:35 ` Robert Richter
[not found] ` <CAFpQJXWKybVUxpHg8MVrVMjLj3swuxLGo_9r1tL+gZ4hxUHTzQ@mail.gmail.com>
2014-07-31 9:53 ` Mark Rutland
[not found] ` <CAFpQJXUtP=v7FSLd3_OU7FG3w=pKYy2ihTQULA_DPEacsSu0Og@mail.gmail.com>
2014-07-31 11:33 ` Mark Rutland
2014-08-01 17:04 ` Robert Richter
2014-08-01 18:00 ` Mark Rutland [this message]
2014-08-01 10:25 ` Robert Richter
2014-07-30 18:12 ` Olof Johansson
2014-07-30 18:35 ` Mark Rutland
2014-07-30 18:14 ` Olof Johansson
2014-08-01 16:18 ` Robert Richter
2014-08-28 16:15 ` Robert Richter
2014-08-28 16:25 ` Mark Rutland
2014-08-28 16:31 ` Olof Johansson
2014-08-28 18:14 ` Robert Richter
2014-08-28 23:01 ` Olof Johansson
2014-08-29 12:10 ` Robert Richter
2014-08-29 13:49 ` [PATCH] arm64, dts: Add dtbs_install make target 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 11:33 ` Robert Richter
2014-07-30 15:06 ` [PATCH 3/5] arm64, thunder: document devicetree bindings " 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 ` [PATCH 5/5] arm64, defconfig: Enable tmpfs mount option 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=20140801180035.GF3264@leverpostej \
--to=mark.rutland@arm.com \
--cc=linux-arm-kernel@lists.infradead.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).