On 2015-02-16 14:42, Mark Rutland wrote: > On Mon, Feb 16, 2015 at 12:54:43PM +0000, Jan Kiszka wrote: >> From: Ian Campbell <i...@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.
OK, here my knowledge is not yet sufficient to process this remark. What kind of problems can arise from what kind of attribute mismatch? And why should the OS be able to cause problems for the monitor? > > If you're able to carve out the "secure" memory from the memory node(s), > then you should be safe from that. Do you have a pointer to an example how to do it instead? Jan > > Thanks, > Mark. > >> >> Signed-off-by: Ian Campbell <i...@hellion.org.uk> >> Signed-off-by: Jan Kiszka <jan.kis...@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 >> >> -- Siemens AG, Corporate Technology, CT RTC ITP SES-DE Corporate Competence Center Embedded Linux _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
