1. 06 Aug, 2018 1 commit
  2. 02 Aug, 2018 1 commit
  3. 30 Jul, 2018 1 commit
  4. 15 Jul, 2018 2 commits
  5. 13 Jul, 2018 4 commits
    • Antonio Nino Diaz's avatar
      xlat v2: Turn MMU parameters into 64-bit values · 6563c0be
      Antonio Nino Diaz authored
      
      
      Most registers are 64-bit wide, even in AArch32 mode:
      
      - MAIR_ELx is equivalent to MAIR0 and MAIR1.
      - TTBR is 64 bit in both AArch64 and AArch32.
      
      The only difference is the TCR register, which is 32 bit in AArch32 and
      in EL3 in AArch64. For consistency with the rest of ELs in AArch64, it
      makes sense to also have it as a 64-bit value.
      
      Change-Id: I2274d66a28876702e7085df5f8aad0e7ec139da9
      Signed-off-by: default avatarAntonio Nino Diaz <antonio.ninodiaz@arm.com>
      6563c0be
    • Antonio Nino Diaz's avatar
      xlat v2: Remove IMAGE_EL define · aa1d5f60
      Antonio Nino Diaz authored
      
      
      The Exception Level is now detected at runtime. This means that it is not
      needed to hardcode the EL used by each image.
      
      This doesn't result in a substantial increase of the image size because
      the initialization functions that aren't used are garbage-collected by
      the linker.
      
      In AArch32 the current EL has been changed from EL3 to EL1 because the
      the AArch32 PL1&0 translation regime behaves more like the AArch64 EL1&0
      translation regime than the EL3 one.
      
      Change-Id: I941404299ebe7666ca17619207c923b49a55cb73
      Signed-off-by: default avatarAntonio Nino Diaz <antonio.ninodiaz@arm.com>
      aa1d5f60
    • Antonio Nino Diaz's avatar
      xlat v2: Remove unused tlbi helper · 8d164bc6
      Antonio Nino Diaz authored
      
      
      xlat_arch_tlbi_va_regime() isn't used, so it has been renamed to
      xlat_arch_tlbi_va() and the previous implementation has been removed.
      
      Change-Id: Ic118bed3fb68234748d86b2e9e95b25650289276
      Signed-off-by: default avatarAntonio Nino Diaz <antonio.ninodiaz@arm.com>
      8d164bc6
    • Antonio Nino Diaz's avatar
      xlat v2: Remove architectural headers · 468e2382
      Antonio Nino Diaz authored
      
      
      They only contained one function that is easily integrated in the private
      library header and the existing architectural C files.
      
      This also helps making the library more portable, as the Makefile of the
      library now doesn't use the variable INCLUDES, which is specific to this
      codebase and doesn't respect the namespace of the library.
      
      Change-Id: I22228e6a97e9b4f346f5cd8947609263e8df71d8
      Signed-off-by: default avatarAntonio Nino Diaz <antonio.ninodiaz@arm.com>
      468e2382
  6. 03 Jul, 2018 3 commits
    • Antonio Nino Diaz's avatar
      xlat v2: Make get/set attrs functions less verbose · 6a086061
      Antonio Nino Diaz authored
      
      
      It is useful to have LOG_LEVEL_VERBOSE because it prints the memory map
      of each image, but that also means that the change_mem_attributes and
      get_mem_attributes functions have verbose prints, and generate a too
      long text output that hides other useful information.
      
      As they were mostly there for debug purposes, this patch removes them.
      
      Change-Id: I2986537377d1f78be2b79cc8a6cf230c380bdb55
      Signed-off-by: default avatarAntonio Nino Diaz <antonio.ninodiaz@arm.com>
      6a086061
    • Antonio Nino Diaz's avatar
      xlat v2: Clean debug xlat tables descriptor print · f9d58d17
      Antonio Nino Diaz authored
      
      
      The previous debug output for EL1&0 translation regimes was too verbose,
      which makes it hard to read and hides the intent behind the parameters
      assigned to each region. This patch simplifies this output and makes the
      outputs for EL3 and EL1&0 mostly the same. The difference is that in
      EL1&0 it is specified whether the region is exclusively accessible from
      EL1 (PRIV) or both EL0 and EL1 (USER).
      
      For example:
      
          MEM-RW(PRIV)-NOACCESS(USER)-XN(PRIV)-XN(USER)-S
          MEM-RO(PRIV)-NOACCESS(USER)-EXEC(PRIV)-EXEC(USER)-S
      
      After the change, it becomes this:
      
          MEM-RW-XN-PRIV-S
          MEM-RO-EXEC-PRIV-S
      
      Change-Id: I15f4b99058429d42107fbf89e15f4838a9b559a5
      Signed-off-by: default avatarAntonio Nino Diaz <antonio.ninodiaz@arm.com>
      f9d58d17
    • Antonio Nino Diaz's avatar
      xlat v2: Split code into separate files · fd2299e6
      Antonio Nino Diaz authored
      
      
      Instead of having one big file with all the code, it's better to have
      a few smaller files that are more manageable:
      
      - xlat_tables_core.c: Code related to the core functionality of the
        library (map and unmap regions, initialize xlat context).
      - xlat_tables_context.c: Instantiation of the active image context
        as well as APIs to manipulate it.
      - xlat_tables_utils.c: Helper code that isn't part of the core
        functionality (change attributes, debug print messages).
      
      Change-Id: I3ea956fc1afd7473c0bb5e7c6aab3b2e5d88c711
      Signed-off-by: default avatarAntonio Nino Diaz <antonio.ninodiaz@arm.com>
      fd2299e6
  7. 27 Jun, 2018 1 commit
    • Jeenu Viswambharan's avatar
      xlat v2: Split MMU setup and enable · 0cc7aa89
      Jeenu Viswambharan authored
      
      
      At present, the function provided by the translation library to enable
      MMU constructs appropriate values for translation library, and programs
      them to the right registers. The construction of initial values,
      however, is only required once as both the primary and secondaries
      program the same values.
      
      Additionally, the MMU-enabling function is written in C, which means
      there's an active stack at the time of enabling MMU. On some systems,
      like Arm DynamIQ, having active stack while enabling MMU during warm
      boot might lead to coherency problems.
      
      This patch addresses both the above problems by:
      
        - Splitting the MMU-enabling function into two: one that sets up
          values to be programmed into the registers, and another one that
          takes the pre-computed values and writes to the appropriate
          registers. With this, the primary effectively calls both functions
          to have the MMU enabled, but secondaries only need to call the
          latter.
      
        - Rewriting the function that enables MMU in assembly so that it
          doesn't use stack.
      
      This patch fixes a bunch of MISRA issues on the way.
      
      Change-Id: I0faca97263a970ffe765f0e731a1417e43fbfc45
      Signed-off-by: default avatarJeenu Viswambharan <jeenu.viswambharan@arm.com>
      0cc7aa89
  8. 22 Jun, 2018 1 commit
    • Antonio Nino Diaz's avatar
      xlat: Remove mmap_attr_t enum type · 3a1b7b10
      Antonio Nino Diaz authored
      
      
      The values defined in this type are used in logical operations, which
      goes against MISRA Rule 10.1: "Operands shall not be of an inappropriate
      essential type".
      
      Now, `unsigned int` is used instead. This also allows us to move the
      dynamic mapping bit from 30 to 31. It was an undefined behaviour in the
      past because an enum is signed by default, and bit 31 corresponds to the
      sign bit. It is undefined behaviour to modify the sign bit. Now, bit 31
      is free to use as it was originally meant to be.
      
      mmap_attr_t is now defined as an `unsigned int` for backwards
      compatibility.
      
      Change-Id: I6b31218c14b9c7fdabebe432de7fae6e90a97f34
      Signed-off-by: default avatarAntonio Nino Diaz <antonio.ninodiaz@arm.com>
      3a1b7b10
  9. 21 Jun, 2018 1 commit
  10. 14 Jun, 2018 1 commit
    • Yann Gautier's avatar
      xlat_v2: add a check on mm_cursor->size to avoid infinite loop · 75df6269
      Yann Gautier authored
      
      
      The issue can occur if end_va is equal to the max architecture address,
      and when mm_cursor point to the last entry of mmap_region_t table: {0}.
      The first line of the while will then be true, e.g. on AARCH32, we have:
      mm_cursor->base_va (=0) + mm_cursor->size (=0) - 1 == end_va (=0xFFFFFFFF)
      And the mm_cursor->size = 0 will be lesser than mm->size
      
      A check on mm_cursor->size != 0 should be done as in the previous while,
      to avoid such kind of infinite loop.
      
      fixes arm-software/tf-issues#594
      Signed-off-by: default avatarYann Gautier <yann.gautier@st.com>
      75df6269
  11. 13 Jun, 2018 1 commit
    • Antonio Nino Diaz's avatar
      xlat v2: Introduce xlat granule size helpers · a0b9bb79
      Antonio Nino Diaz authored
      
      
      The function xlat_arch_is_granule_size_supported() can be used to check
      if a specific granule size is supported. In Armv8, AArch32 only supports
      4 KiB pages. AArch64 supports 4 KiB, 16 KiB or 64 KiB depending on the
      implementation, which is detected at runtime.
      
      The function xlat_arch_get_max_supported_granule_size() returns the max
      granule size supported by the implementation.
      
      Even though right now they are only used by SPM, they may be useful in
      other places in the future. This patch moves the code currently in SPM
      to the xlat tables lib so that it can be reused.
      
      Change-Id: If54624a5ecf20b9b9b7f38861b56383a03bbc8a4
      Signed-off-by: default avatarAntonio Nino Diaz <antonio.ninodiaz@arm.com>
      a0b9bb79
  12. 11 Jun, 2018 1 commit
    • John Tsichritzis's avatar
      MISRA rule 21.15 fix · bdcd33a8
      John Tsichritzis authored
      
      
          Rule 21.15: The pointer arguments to the Standard Library functions
          memcpy, memmove and memcmp shall be pointers to qualified or unqualified
          versions of compatible types.
      
          Basically that means that both pointer arguments must be of the same
          type. However, even if the pointers passed as arguments to the above
          functions are of the same type, Coverity still thinks it's a violation
          if we do pointer arithmetics directly at the function call. Thus the
          pointer arithmetic operations were moved outside of the function
          argument.
      
          First detected on the following configuration
                  make PLAT=fvp LOG_LEVEL=50
      
          Change-Id: I8b912ec1bfa6f2d60857cb1bd453981fd7001b94
      Signed-off-by: default avatarJohn Tsichritzis <john.tsichritzis@arm.com>
      bdcd33a8
  13. 09 May, 2018 1 commit
  14. 02 May, 2018 1 commit
    • Antonio Nino Diaz's avatar
      xlat: Have all values of PARange for 8.x architectures · d3c4487c
      Antonio Nino Diaz authored
      
      
      In AArch64, the field ID_AA64MMFR0_EL1.PARange has a different set of
      allowed values depending on the architecture version.
      
      Previously, we only compiled the Trusted Firmware with the values that
      were allowed by the architecture. However, given that this field is
      read-only, it is easier to compile the code with all values regardless
      of the target architecture.
      
      Change-Id: I57597ed103dd0189b1fb738a9ec5497391c10dd1
      Signed-off-by: default avatarAntonio Nino Diaz <antonio.ninodiaz@arm.com>
      d3c4487c
  15. 26 Apr, 2018 1 commit
    • Antonio Nino Diaz's avatar
      xlat: Set AP[1] to 1 when it is RES1 · 01c0a38e
      Antonio Nino Diaz authored
      
      
      According to the ARMv8 ARM issue C.a:
      
          AP[1] is valid only for stage 1 of a translation regime that can
          support two VA ranges. It is RES 1 when stage 1 translations can
          support only one VA range.
      
      This means that, even though this bit is ignored, it should be set to 1
      in the EL3 and EL2 translation regimes.
      
      For translation regimes consisting on EL0 and a higher regime this bit
      selects between control at EL0 or at the higher Exception level. The
      regimes that support two VA ranges are EL1&0 and EL2&0 (the later one
      is only available since ARMv8.1).
      
      This fix has to be applied to both versions of the translation tables
      library.
      
      Change-Id: If19aaf588551bac7aeb6e9a686cf0c2068e7c181
      Signed-off-by: default avatarAntonio Nino Diaz <antonio.ninodiaz@arm.com>
      01c0a38e
  16. 17 Apr, 2018 1 commit
  17. 09 Apr, 2018 1 commit
    • Varun Wadekar's avatar
      lib: xlat_tables_v2: reduce time required to add a mmap region · 0ed32232
      Varun Wadekar authored
      
      
      The last entry in the mapping table is not necessarily the same as the
      end of the table. This patch loops through the table to find the last
      entry marker, on every new mmap addition. The memove operation then
      has to only move the memory between current entry and the last entry.
      For platforms that arrange their MMIO map properly, this opearation
      turns out to be a NOP.
      
      The previous implementation added significant overhead per mmap
      addition as the memmove operation always moved the difference between
      the current mmap entry and the end of the table.
      
      Tested on Tegra platforms and this new approach improves the memory
      mapping time by ~75%, thus significantly reducing boot time on some
      platforms.
      
      Change-Id: Ie3478fa5942379282ef58bee2085da799137e2ca
      Signed-off-by: default avatarVarun Wadekar <vwadekar@nvidia.com>
      0ed32232
  18. 28 Feb, 2018 2 commits
  19. 27 Feb, 2018 1 commit
  20. 10 Jan, 2018 1 commit
    • Antonio Nino Diaz's avatar
      xlat v2: Correctly unmap regions on map error · 96abc22b
      Antonio Nino Diaz authored
      
      
      `mm_cursor` doesn't have the needed data because the `memmove()` that
      is called right before it overwrites that information. In order to get
      the information of the region that was being mapped, `mm` has to be used
      instead (like it is done to fill the fields of `unmap_mm`).
      
      If the incorrect information is read, this check isn't reliable and
      `xlat_tables_unmap_region` may be requested to unmap memory that isn't
      mapped at all, triggering assertions.
      
      Change-Id: I602d4ac83095d4e5dac9deb34aa5d00d00e6c289
      Signed-off-by: default avatarAntonio Nino Diaz <antonio.ninodiaz@arm.com>
      96abc22b
  21. 17 Nov, 2017 1 commit
  22. 08 Nov, 2017 2 commits
  23. 17 Oct, 2017 2 commits
  24. 05 Oct, 2017 4 commits
    • Antonio Nino Diaz's avatar
      xlat: Add support for EL0 and EL1 mappings · 609c9191
      Antonio Nino Diaz authored
      
      
      This patch introduces the ability of the xlat tables library to manage
      EL0 and EL1 mappings from a higher exception level.
      
      Attributes MT_USER and MT_PRIVILEGED have been added to allow the user
      specify the target EL in the translation regime EL1&0.
      
      REGISTER_XLAT_CONTEXT2 macro is introduced to allow creating a
      xlat_ctx_t that targets a given translation regime (EL1&0 or EL3).
      
      A new member is added to xlat_ctx_t to represent the translation regime
      the xlat_ctx_t manages. The execute_never mask member is removed as it
      is computed from existing information.
      
      Change-Id: I95e14abc3371d7a6d6a358cc54c688aa9975c110
      Co-authored-by: default avatarDouglas Raillard <douglas.raillard@arm.com>
      Co-authored-by: default avatarSandrine Bailleux <sandrine.bailleux@arm.com>
      Co-authored-by: default avatarAntonio Nino Diaz <antonio.ninodiaz@arm.com>
      Signed-off-by: default avatarAntonio Nino Diaz <antonio.ninodiaz@arm.com>
      609c9191
    • Douglas Raillard's avatar
      xlat: Introduce function xlat_arch_tlbi_va_regime() · b4ae615b
      Douglas Raillard authored
      
      
      Introduce a variant of the TLB invalidation helper function that
      allows the targeted translation regime to be specified, rather than
      defaulting to the current one.
      
      This new function is useful in the context of EL3 software managing
      translation tables for the S-EL1&0 translation regime, as then it
      might need to invalidate S-EL1&0 TLB entries rather than EL3 ones.
      
      Define a new enumeration to be able to represent translation regimes in
      the xlat tables library.
      
      Change-Id: Ibe4438dbea2d7a6e7470bfb68ff805d8bf6b07e5
      Co-authored-by: default avatarSandrine Bailleux <sandrine.bailleux@arm.com>
      Co-authored-by: default avatarDouglas Raillard <douglas.raillard@arm.com>
      Co-authored-by: default avatarAntonio Nino Diaz <antonio.ninodiaz@arm.com>
      Signed-off-by: default avatarAntonio Nino Diaz <antonio.ninodiaz@arm.com>
      b4ae615b
    • Sandrine Bailleux's avatar
      xlat: Always compile TLB invalidation functions · f301da44
      Sandrine Bailleux authored
      
      
      TLB invalidation functions used to be conditionally compiled in.
      They were enabled only when using the dynamic mapping feature.
      because only then would we need to modify page tables on the fly.
      
      Actually there are other use cases where invalidating TLBs is required.
      When changing memory attributes in existing translation descriptors for
      example. These other use cases do not necessarily depend on the dynamic
      mapping feature.
      
      This patch removes this dependency and always compile TLB invalidation
      functions in. If they're not used, they will be removed from the binary
      at link-time anyway so there's no consequence on the memory footprint
      if these functions are not called.
      
      Change-Id: I1c33764ae900eb00073ee23b7d0d53d4efa4dd21
      Signed-off-by: default avatarSandrine Bailleux <sandrine.bailleux@arm.com>
      f301da44
    • Sandrine Bailleux's avatar
      xlat: Introduce MAP_REGION2() macro · fdb1964c
      Sandrine Bailleux authored
      
      
      The current implementation of the memory mapping API favours mapping
      memory regions using the biggest possible block size in order to
      reduce the number of translation tables needed.
      
      In some cases, this behaviour might not be desirable. When translation
      tables are edited at run-time, coarse-grain mappings like that might
      need splitting into finer-grain tables. This operation has a
      performance cost.
      
      The MAP_REGION2() macro allows to specify the granularity of
      translation tables used for the initial mapping of a memory region.
      This might increase performance for memory regions that are likely to
      be edited in the future, at the expense of a potentially increased
      memory footprint.
      
      The Translation Tables Library Design Guide has been updated to
      explain the use case for this macro. Also added a few intermediate
      titles to make the guide easier to digest.
      
      Change-Id: I04de9302e0ee3d326b8877043a9f638766b81b7b
      Co-authored-by: default avatarSandrine Bailleux <sandrine.bailleux@arm.com>
      Co-authored-by: default avatarAntonio Nino Diaz <antonio.ninodiaz@arm.com>
      Signed-off-by: default avatarAntonio Nino Diaz <antonio.ninodiaz@arm.com>
      fdb1964c
  25. 21 Sep, 2017 2 commits
    • 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
  26. 14 Sep, 2017 1 commit
  27. 11 Sep, 2017 1 commit
    • Douglas Raillard's avatar
      xlat: Use MAP_REGION macro as compatibility layer · 769d65da
      Douglas Raillard authored
      
      
      Use the MAP_REGION to build the mmap_region_t argument in wrappers like
      mmap_add_region(). Evolution of the mmap_region_t might require adding
      new members with a non-zero default value. Users of MAP_REGION are
      protected against such evolution. This commit also protects users of
      mmap_add_region() and mmap_add_dynamic_region() functions against these
      evolutions.
      
      Also make the MAP_REGION macro implementation more explicit and make it
      a mmap_region_t compound literal to make it useable as a function
      parameter on its own and to prevent using it in initialization of
      variables of different type.
      
      Change-Id: I7bfc4689f6dd4dd23c895b65f628d8ee991fc161
      Signed-off-by: default avatarDouglas Raillard <douglas.raillard@arm.com>
      769d65da