On Mon, Feb 16, 2015 at 12:54:43PM +0000, Jan Kiszka wrote:
From: Ian Campbell ijc@hellion.org.uk
In this case the secure code lives in RAM, and hence needs to be reserved, but it has been relocated, so the reservation of __secure_start does not apply.
Add support for setting CONFIG_ARMV7_SECURE_RESERVE_SIZE to reserve such a region.
This will be used in a subsequent patch for Jetson-TK1
Using a memreserve and allowing the OS to map the memory but not poke it can be problematic due to the potential of mismatched attributes between the monitor and the OS.
If you're able to carve out the "secure" memory from the memory node(s), then you should be safe from that.
Thanks, Mark.
Signed-off-by: Ian Campbell ijc@hellion.org.uk Signed-off-by: Jan Kiszka jan.kiszka@siemens.com
arch/arm/cpu/armv7/virt-dt.c | 5 +++++ 1 file changed, 5 insertions(+)
diff --git a/arch/arm/cpu/armv7/virt-dt.c b/arch/arm/cpu/armv7/virt-dt.c index ad19e4c..eb95031 100644 --- a/arch/arm/cpu/armv7/virt-dt.c +++ b/arch/arm/cpu/armv7/virt-dt.c @@ -96,6 +96,11 @@ int armv7_update_dt(void *fdt) /* secure code lives in RAM, keep it alive */ fdt_add_mem_rsv(fdt, (unsigned long)__secure_start, __secure_end - __secure_start); +#elif defined(CONFIG_ARMV7_SECURE_RESERVE_SIZE)
- /* secure code has been relocated into RAM carveout, keep it alive */
- fdt_add_mem_rsv(fdt,
CONFIG_ARMV7_SECURE_BASE,CONFIG_ARMV7_SECURE_RESERVE_SIZE);#endif
return fdt_psci(fdt);
2.1.4