1. 04 Oct, 2017 3 commits
  2. 02 Oct, 2017 2 commits
  3. 29 Sep, 2017 1 commit
  4. 27 Sep, 2017 2 commits
  5. 26 Sep, 2017 2 commits
  6. 25 Sep, 2017 7 commits
    • davidcunado-arm's avatar
      Merge pull request #1108 from sandrine-bailleux-arm/sb/fvp-utils-def · 92d0926a
      davidcunado-arm authored
      FVP: Include utils_def.h instead of utils.h
      92d0926a
    • davidcunado-arm's avatar
      Merge pull request #1105 from antonio-nino-diaz-arm/an/epd1-bit · c2280b37
      davidcunado-arm authored
      Set TCR_EL1.EPD1 bit to 1
      c2280b37
    • davidcunado-arm's avatar
      Merge pull request #1106 from antonio-nino-diaz-arm/an/bit-macro · 36f52843
      davidcunado-arm authored
      Fix type of `unsigned long` constants
      36f52843
    • Roberto Vargas's avatar
      mem_protect: Add DRAM2 to the list of mem protected ranges · b09ba056
      Roberto Vargas authored
      
      
      On ARM platforms, the maximum size of the address space is limited
      to 32-bits as defined in arm_def.h. In order to access DRAM2, which
      is defined beyond the 32-bit address space, the maximum address space
      is increased to 36-bits in AArch64. It is possible to increase the
      virtual space for AArch32, but it is more difficult and not supported
      for now.
      
      NOTE - the actual maximum memory address space is platform dependent
      and is checked at run-time by querying the PARange field in the
      ID_AA64MMFR0_EL1 register.
      
      Change-Id: I6cb05c78a63b1fed96db9a9773faca04a5b93d67
      Signed-off-by: default avatarRoberto Vargas <roberto.vargas@arm.com>
      b09ba056
    • Roberto Vargas's avatar
      mem_protect: Add mem_protect support in Juno and FVP for DRAM1 · f145403c
      Roberto Vargas authored
      
      
      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: default avatarRoberto Vargas <roberto.vargas@arm.com>
      f145403c
    • Roberto Vargas's avatar
      Add mem_region utility functions · 43cbaf06
      Roberto Vargas authored
      
      
      This commit introduces a new type (mem_region_t) used to describe
      memory regions and it adds two utility functions:
      
      	- clear_mem_regions: This function clears (write 0) to a set
      		of regions described with an array of mem_region_t.
      
      	- mem_region_in_array_chk This function checks if a
      		region is covered by some of the regions described
      		with an array of mem_region_t.
      
      Change-Id: I12ce549f5e81dd15ac0981645f6e08ee7c120811
      Signed-off-by: default avatarRoberto Vargas <roberto.vargas@arm.com>
      43cbaf06
    • Roberto Vargas's avatar
      mem_protect: Add mem_protect API · d4c596be
      Roberto Vargas authored
      
      
      This patch adds the generic code that links the psci smc handler
      with the platform function that implements the mem_protect and
      mem_check_range functionalities. These functions are  optional
      APIs added in PSCI v1.1 (ARM DEN022D).
      
      Change-Id: I3bac1307a5ce2c7a196ace76db8317e8d8c8bb3f
      Signed-off-by: default avatarRoberto Vargas <roberto.vargas@arm.com>
      d4c596be
  7. 22 Sep, 2017 3 commits
  8. 21 Sep, 2017 4 commits
    • Sandrine Bailleux's avatar
      FVP: Include utils_def.h instead of utils.h · d08f8c6a
      Sandrine Bailleux authored
      platform_def.h doesn't need all the definitions in utils.h,
      the ones in utils_def.h are enough. This patch is related
      to the changes introduced by commit 53d9c9c8
      
      .
      
      Change-Id: I4b2ff237a2d7fe07a7230e0e49b44b3fc2ca8abe
      Signed-off-by: default avatarSandrine Bailleux <sandrine.bailleux@arm.com>
      d08f8c6a
    • Antonio Nino Diaz's avatar
      Fix type of `unsigned long` constants · e47ac1fd
      Antonio Nino Diaz authored
      
      
      The type `unsigned long` is 32 bit wide in AArch32, but 64 bit wide in
      AArch64. This is inconsistent and that's why we avoid using it as per
      the Coding Guidelines. This patch changes all `UL` occurrences to `U`
      or `ULL` depending on the context so that the size of the constant is
      clear.
      
      This problem affected the macro `BIT(nr)`. As long as this macro is used
      to fill fields of registers, that's not a problem, since all registers
      are 32 bit wide in AArch32 and 64 bit wide in AArch64. However, if the
      macro is used to fill the fields of a 64-bit integer, it won't be able
      to set the upper 32 bits in AArch32.
      
      By changing the type of this macro to `unsigned long long` the behaviour
      is always the same regardless of the architecture, as this type is
      64-bit wide in both cases.
      
      Some Tegra platform files have been modified by this patch.
      
      Change-Id: I918264c03e7d691a931f0d1018df25a2796cc221
      Signed-off-by: default avatarAntonio Nino Diaz <antonio.ninodiaz@arm.com>
      e47ac1fd
    • Antonio Nino Diaz's avatar
      Set TCR_EL1.EPD1 bit to 1 · 3388b38d
      Antonio Nino Diaz authored
      
      
      In the S-EL1&0 translation regime we aren't using the higher VA range,
      whose translation table base address is held in TTBR1_EL1. The bit
      TCR_EL1.EPD1 can be used to disable translations using TTBR1_EL1, but
      the code wasn't setting it to 1. Additionally, other fields in TCR1_EL1
      associated with the higher VA range (TBI1, TG1, SH1, ORGN1, IRGN1 and
      A1) weren't set correctly as they were left as 0. In particular, 0 is a
      reserved value for TG1. Also, TBBR1_EL1 was not explicitly set and its
      reset value is UNKNOWN.
      
      Therefore memory accesses to the higher VA range would result in
      unpredictable behaviour as a translation table walk would be attempted
      using an UNKNOWN value in TTBR1_EL1.
      
      On the FVP and Juno platforms accessing the higher VA range resulted in
      a translation fault, but this may not always be the case on all
      platforms.
      
      This patch sets the bit TCR_EL1.EPD1 to 1 so that any kind of
      unpredictable behaviour is prevented.
      
      This bug only affects the AArch64 version of the code, the AArch32
      version sets this bit to 1 as expected.
      
      Change-Id: I481c000deda5bc33a475631301767b9e0474a303
      Signed-off-by: default avatarAntonio Nino Diaz <antonio.ninodiaz@arm.com>
      3388b38d
    • Douglas Raillard's avatar
      xlat: simplify mmap_add_region_check parameters (#1101) · df312c5a
      Douglas Raillard authored
      
      
      Use a mmap_region_t as parameter instead of getting a parameter for each
      structure member. This reduces the scope of changes when adding members
      to mmap_region_t.
      
      Also align on the convention of using mm_cursor as a variable name for
      the currently inspected region when iterating on the region array.
      
      Change-Id: If40bc4351b56c64b214e60dda27276d11ce9dbb3
      Signed-off-by: default avatarDouglas Raillard <douglas.raillard@arm.com>
      df312c5a
  9. 19 Sep, 2017 2 commits
  10. 18 Sep, 2017 2 commits
  11. 15 Sep, 2017 3 commits
  12. 14 Sep, 2017 3 commits
  13. 13 Sep, 2017 4 commits
  14. 12 Sep, 2017 2 commits