aboutsummaryrefslogtreecommitdiffstats
path: root/lib
diff options
context:
space:
mode:
authorRoberto Vargas <roberto.vargas@arm.com>2017-08-03 09:16:43 +0100
committerRoberto Vargas <roberto.vargas@arm.com>2017-09-25 13:32:20 +0100
commitf145403c2a1a7064cb55670ac0674dc6586398ab (patch)
tree8da5287f959444b451329224dc57ff595fb82b05 /lib
parent43cbaf061587e7e8b3529e4b1d30de3ab1b52d3e (diff)
downloadplatform_external_arm-trusted-firmware-f145403c2a1a7064cb55670ac0674dc6586398ab.tar.gz
platform_external_arm-trusted-firmware-f145403c2a1a7064cb55670ac0674dc6586398ab.tar.bz2
platform_external_arm-trusted-firmware-f145403c2a1a7064cb55670ac0674dc6586398ab.zip
mem_protect: Add mem_protect support in Juno and FVP for DRAM1
mem_protect needs some kind of non-volatile memory because it has to remember its state across reset and power down events. The most suitable electronic part for this feature is a NVRAM which should be only accesible from the secure world. Juno and FVP lack such hardware and for this reason the MEM_PROTECT functionality is implemented with Flash EEPROM memory on both boards, even though this memory is accesible from the non-secure world. This is done only to show a full implementation of these PSCI features, but an actual system shouldn't use a non-secure NVRAM to implement it. The EL3 runtime software will write the mem_protect flag and BL2 will read and clear the memory ranges if enabled. It is done in BL2 because it reduces the time that TF needs access to the full non-secure memory. The memory layout of both boards is defined using macros which take different values in Juno and FVP platforms. Generic platform helpers are added that use the platform specific macros to generate a mem_region_t that is valid for the platform. Change-Id: I2c6818ac091a2966fa07a52c5ddf8f6fde4941e9 Signed-off-by: Roberto Vargas <roberto.vargas@arm.com>
Diffstat (limited to 'lib')
0 files changed, 0 insertions, 0 deletions