[PATCH 2/5] arm64, thunder: Add initial dts for Cavium Thunder SoC

Mark Rutland mark.rutland at arm.com
Fri Aug 1 11:00:35 PDT 2014


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.



More information about the linux-arm-kernel mailing list