[PATCH 2/5] arm64, thunder: Add initial dts for Cavium Thunder SoC
From: rric@kernel.org (Robert Richter)
Date: 2014-08-01 17:04:18
Also in:
linux-devicetree, lkml
Possibly related (same subject, not in this thread)
- 2014-08-29 · Re: [PATCH 2/5] arm64, thunder: Add initial dts for Cavium Thunder SoC · Robert Richter <hidden>
- 2014-08-28 · Re: [PATCH 2/5] arm64, thunder: Add initial dts for Cavium Thunder SoC · Olof Johansson <hidden>
- 2014-08-28 · Re: [PATCH 2/5] arm64, thunder: Add initial dts for Cavium Thunder SoC · Robert Richter <rric@kernel.org>
- 2014-08-28 · Re: [PATCH 2/5] arm64, thunder: Add initial dts for Cavium Thunder SoC · Olof Johansson <hidden>
- 2014-08-28 · Re: [PATCH 2/5] arm64, thunder: Add initial dts for Cavium Thunder SoC · Mark Rutland <mark.rutland@arm.com>
Mark, On 31.07.14 12:33:01, Mark Rutland wrote:
On Thu, Jul 31, 2014 at 12:12:33PM +0100, Ganapatrao Kulkarni wrote:quoted
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