f145403c2a
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> |
||
|---|---|---|
| .. | ||
| board/common | ||
| common | ||
| css/common | ||
| soc/common | ||