lkml.org 
[lkml]   [2014]   [Aug]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH 2/5] arm64, thunder: Add initial dts for Cavium Thunder SoC
    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.


    \
     
     \ /
      Last update: 2014-08-01 20:41    [W:2.900 / U:0.064 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site