From mboxrd@z Thu Jan 1 00:00:00 1970 From: rric@kernel.org (Robert Richter) Date: Fri, 1 Aug 2014 19:04:11 +0200 Subject: [PATCH 2/5] arm64, thunder: Add initial dts for Cavium Thunder SoC In-Reply-To: <20140731113301.GE22994@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> <20140731113301.GE22994@leverpostej> Message-ID: <20140801170411.GG4703@rric.localhost> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org 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